How would that work? I mean, when and does it authenticate files to service?
What's with files already inside player or played by another program, how would they know if they are expired by service cancellation?
Visual studio is used under windows to program for windows. So they are doomed to success with it.
But visual studio can't do anything outside this area, really.
This is a very very big problem.
Plugin problems, binary compatibility problems, DSO problems, vtable format problems, and all other things we hate in C++ and that absent in java/c++
Is it really hardcore FPS? Then OK, i was wrong.
Is it multiplayer, by the way? Multiplayer FPS's make hugely different sense.
Consoles will soon have starcraft:ghost which is FPS too, but it's not like PC FPS...
Because, show me game console equivalents of:
Civilization
Warcraft III
ADOM:)
Games of these genres does not exist on consoles, afaik.
And i really need them, not something else.
(I have never heard there are good FPS for consoles, while i don't know - not interested in)
Consoles have their game-to-kill-weekend games market, but serious gamers will always like more intellegent devices.
Yes. And that was even more fun since you was first to try it, and because each new patch changed a lot of things (remember when tanks was able to take riflemen in?)
Yes, blizzard sucks for that. And now they use challenge-responce like auth (heh, In Soviet Russia, client authenticates server) - no chances for bnetd anyway, 'cause it will require to patch client.
~ 2 years ago, they released Warcraft III beta..iso was widely avaliable, but only cd-key owners could play (it was battle.net-only version).
But there was bnetd, free (GPLd) battle.net daemon, that made play possible. So, all the network played warcraft iii beta all the way.
Blizzard had even to enable up to 5 playters on 1 cd-key. Anyway, after game was out, #1 of official battle-net and #1 of unoficial servers was equal in skills, in first encounter bnetd player even won.
I wonder if there will be something like for this beta. BNETD god sued by blizzard, btw.
Well, i guess, that's only your sight a problem.
Who is a bigger asshole, Miguel or Rhys, is a big question to everyone but zealots. I will even guess, that noone of is.
System.Windows.Forms are portable, not native X.
There is already GDI+ baseed version and there might be SDL-based.
Again, pnet+pnetlib is 7MB in.tar.gz, and mono+mcs+icu+wine is well ~50MB. dare to compare.
If Mono SWF implementation will success, IT will be "great enabler to proprietary software companies", since fully compatible with winapi, not just SWF.
About extrreme slowness (mono i386 8000 points, ilrun 4000, mint 300(sic!)) is a plain BS.
I do not want to set flame up, but i expected less emotions and BS from EFF oficial.
sure; they both have compiler, bytecode interpreter/jit and class library which are different implementation of one thing.
You're right about drawing yourself/relying on other libs. and i guess, they made crazy on specifications because free software still does not have java-alternative, and this was a good chance of getting one.
In fact, there are a lot of differences.
Mono works fast on i386 and slow on * else - pnet works ~equal (but slower than mono in i386) on all platforms.
Mono's c# compiler is written in c# and P.Net one is written in C.
Mono is going to have python compiler, P.Net have C compiler.
Mono uses GTK# bindings for gui and going to use wine for System.Windows.Forms - will be very compatible with MS but not portable or reliable.
P.Net use portable (now windows and X) System.Windows.Forms, but it may be not that compatible with windows, using-native-code apps.
There are a lot more of differences.
And imagine, if you want to contrigute such project, you are going to be familliar with those things and even small differences may make huge difference to you.
gtk# build scripts are not pnet compiler-friendly, but compiled gkt# libs work with DotGNU just fine.
And DotGNU portable System.Windows.Forms works fine with mono - there might be package soon.
I beleive DotGNU project is better.
While Mono is faster on i386, here and now, Portable.Net is really portable to anywhere, does not rely on non-standard things, have working System.Windows.Forms and so on and so on. And is GNU project.
Surprised why ou never headr of it? Because mono is actively PRed by articles like this.
Slashdot Mirror
How would that work? I mean, when and does it authenticate files to service? What's with files already inside player or played by another program, how would they know if they are expired by service cancellation?
Visual studio is used under windows to program for windows. So they are doomed to success with it. But visual studio can't do anything outside this area, really.
How aboud DVI. Yes, i know noone use it to distribute documents, but it is there :)
There is a jabber server out there, being widely user in corporate networks.
What will be with ICQ (or it's included into AIM)? :)
What will happen to jabber now, i wonder?
This is a very very big problem. Plugin problems, binary compatibility problems, DSO problems, vtable format problems, and all other things we hate in C++ and that absent in java/c++
Is it really hardcore FPS? Then OK, i was wrong. Is it multiplayer, by the way? Multiplayer FPS's make hugely different sense. Consoles will soon have starcraft:ghost which is FPS too, but it's not like PC FPS...
Because, show me game console equivalents of: Civilization Warcraft III ADOM :)
Games of these genres does not exist on consoles, afaik.
And i really need them, not something else.
(I have never heard there are good FPS for consoles, while i don't know - not interested in)
Consoles have their game-to-kill-weekend games market, but serious gamers will always like more intellegent devices.
Yes. But diablo, diablo ii and starcraft are able to connect without any client patching...
Yes. And that was even more fun since you was first to try it, and because each new patch changed a lot of things (remember when tanks was able to take riflemen in?) Yes, blizzard sucks for that. And now they use challenge-responce like auth (heh, In Soviet Russia, client authenticates server) - no chances for bnetd anyway, 'cause it will require to patch client.
FLTK license is LGPL with *strict* allowance of static linking to proprierary apps.
~ 2 years ago, they released Warcraft III beta. .iso was widely avaliable, but only cd-key owners could play (it was battle.net-only version).
But there was bnetd, free (GPLd) battle.net daemon, that made play possible. So, all the network played warcraft iii beta all the way.
Blizzard had even to enable up to 5 playters on 1 cd-key. Anyway, after game was out, #1 of official battle-net and #1 of unoficial servers was equal in skills, in first encounter bnetd player even won.
I wonder if there will be something like for this beta. BNETD god sued by blizzard, btw.
Even if i use P.Net on QNX NC?
Well, i guess, that's only your sight a problem. Who is a bigger asshole, Miguel or Rhys, is a big question to everyone but zealots. I will even guess, that noone of is. System.Windows.Forms are portable, not native X. There is already GDI+ baseed version and there might be SDL-based. Again, pnet+pnetlib is 7MB in .tar.gz, and mono+mcs+icu+wine is well ~50MB. dare to compare.
If Mono SWF implementation will success, IT will be "great enabler to proprietary software companies", since fully compatible with winapi, not just SWF.
About extrreme slowness (mono i386 8000 points, ilrun 4000, mint 300(sic!)) is a plain BS.
I do not want to set flame up, but i expected less emotions and BS from EFF oficial.
sure; they both have compiler, bytecode interpreter/jit and class library which are different implementation of one thing. You're right about drawing yourself/relying on other libs. and i guess, they made crazy on specifications because free software still does not have java-alternative, and this was a good chance of getting one.
In fact, there are a lot of differences. Mono works fast on i386 and slow on * else - pnet works ~equal (but slower than mono in i386) on all platforms. Mono's c# compiler is written in c# and P.Net one is written in C. Mono is going to have python compiler, P.Net have C compiler. Mono uses GTK# bindings for gui and going to use wine for System.Windows.Forms - will be very compatible with MS but not portable or reliable. P.Net use portable (now windows and X) System.Windows.Forms, but it may be not that compatible with windows, using-native-code apps. There are a lot more of differences. And imagine, if you want to contrigute such project, you are going to be familliar with those things and even small differences may make huge difference to you.
gtk# build scripts are not pnet compiler-friendly, but compiled gkt# libs work with DotGNU just fine. And DotGNU portable System.Windows.Forms works fine with mono - there might be package soon.
I beleive DotGNU project is better. While Mono is faster on i386, here and now, Portable.Net is really portable to anywhere, does not rely on non-standard things, have working System.Windows.Forms and so on and so on. And is GNU project. Surprised why ou never headr of it? Because mono is actively PRed by articles like this.
In Soviet Russia, your TV-set controls MPAA!
Where's the link to leaked cover image?