quote: Original post by qurob
There was this editor...for this game, they wrote it in Visual Basic....what game was it....oh yeah....Unreal!

VB can't be THAT bad if they used it to make UnrealEd. Granted, it might not be the best it could be, but when's the last time you seen a level editor for a highly rated 3D fps written in Java?

Enough about that. In my original post I was talking more about VB's blazing compiled speed compared to Java's speed. (oxymoron?)

Such an editor could be made in any language you like. Even assembler. But would I do that? No.

COBOL and FORTRAN was used to build large financial systems that control a lot of bank even to this day. Does that prove that they are good languages? No.

And as I said, Java has compilers to that make machine code, just like VB. So again, these can produce just as fast code as VB can. Don't compare the speed of an applet or interpreted Java with the speed of compiled VB code - if you do, then yes Java is slower than VB. But then again, no serious games are made using interpreted code (well actually Vampire used interpreted code in scripts) so that comparison would be stupid. That like comparing the speed of a car with its engines shut off and a person walking. Just because the person go faster than the car it this case doen't make the man faster in all cases (the car engine might be turned on).

Finally, Editors don't require much speed. For instance, Quark (the Quake series editor) is written mainly in interpreted Python which is very slow, but serves it purpose here.

Jacob Marner

Edited by - felonius on November 20, 2000 6:01:42 PM

I have to say most of you have not done large scale java applications. I have worked with java since 1.0 and am currently employed doing server side java applications.

I am not an expert, but from my knowledge of java, c, c++, perl, python, asm, lisp, and pascal most programs could be written in ANY language. I''m using java because it works, the development tools are free and it does what I need it to do.

bI''ve been mostly developing java on the server-side also, and think that''s where it should be used AFAIK servlets for example, are pretty much faster than CGI since they don''t need to spawn a new process each time a request is being made.

Applets then again i personally don''t like at all - except for graphics processing. They''re buggy and the browser support for applets is what it is. Just started looking into c++ a few days ago, seemed pretty hard at the first point, but it begins to slowly make sense already..

Dunno if this was totally off-topic, just wanted to express my point of view.

By the way, Felonius, if JNI should be used at game programming, what kind of tasks did you think to use a lower-level language for? Surely some computations, but did you plan to use it for the gfx presentations etc? If yes, then in which way? I didn''t quite get that, should i have after reading your article etc?



''''2+2=5 for extremely large values of 2.''''

Are you stupid? Compiling Java to an EXE or what not still doesn''t make it very fast. Another thing it does it takes away the whole point of using Java-Platform Independence. If you plan on writing games in java and just letting the windows users have > 5 fps, you may as well do it in C/C++ or Visual Basic.


---------------------------------------------------------
And as I said, Java has compilers to that make machine code, just like VB. So again, these can produce just as fast code as VB can. Don''t compare the speed of an applet or interpreted Java with the speed of compiled VB code - if you do, then yes Java is slower than VB. But then again, no serious games are made using interpreted code (well actually Vampire used interpreted code in scripts) so that comparison would be stupid. That like comparing the speed of a car with its engines shut off and a person walking. Just because the person go faster than the car it this case doen''t make the man faster in all cases (the car engine might be turned on).

Finally, Editors don''t require much speed. For instance, Quark (the Quake series editor) is written mainly in interpreted Python which is very slow, but serves it purpose here.

Jacob Marner
----------------------------------------------------------

Qurob, you don't seem to be getting the point of the native stuff at all do you? Go read the felonius' article again
The point is the simplicity of java compared to c/c++, if i got it right. Besides using JNI for critical parts of the game, it does get a _little_ more speed.



Edited by - fovster on November 21, 2000 11:22:01 AM

I am sorry, you other people on this forum, but I am getting quite angry. Please forgive me.

quote: Original post by qurob
Are you stupid? Compiling Java to an EXE or what not still doesn't make it very fast. Another thing it does it takes away the whole point of using Java-Platform Independence. If you plan on writing games in java and just letting the windows users have > 5 fps, you may as well do it in C/C++ or Visual Basic.

No, I am not stupid, but you are ignorant. You don't win a discussion by calling people names. Arguments win.

qurob, are you thinking that am I talking about packing Java in a an EXE like Microsoft J++ does. Yes that is slow, but that is the way with many Microsoft tools.
But the native compilers for: GJC, Visual Cafe 4, IBM Visual Age are actual producing pure machine code. Have you ever tried one of these? If not, then shut up.

GJC is just a different front end to gcc and the code it produces uses the same code as for gcc - the compiler used to produce all the utilities in Unix - including Linux. And gcc has a better optimizer than VB has (the VB optimizer is actually quite inefficient).

Oh, and by the way; Using the scheme in described in my article where I combine C++ and Java (because 100% pure Java does has its limitations for high performance applications) I am using a Quake II styke engine running with more that 35 frames per sec - within my Java code. Admittedly this isn't pure Java code, but try reading that other thread that snowmoon has posted with framerate - and then go home a weep.

Oh and you compare platform independant Java with platform dependant VB and see it slower. Of course - platform independance is slower that platform dependance. That is why I am making sure that they are compared on equal terms by using compiled code in both cases.

Anyway, speed isn't everything. Is it was everybody would still use assembler. Productivity is a major issue - and for large scale products Java is more productive that VB.

And for speed in games you are probably referring to the DirectX support in VB. DirectX is itself written C and by calling it from VB is no different than calling C/C++ from Java. Very comparable, actually.

Jacob Marner

Edited by - felonius on November 21, 2000 11:51:32 AM