Why Java?

Sorry Captain, I won’t start name calling and insulting people - look elsewhere for a flame war. I’m very happy with Java and see a great future for it. If you don’t, then that’s merely a difference of opinion, not something to verbally abuse people over.

Just for the record, I don’t believe I’m in denial, I’m not oblivious to the problems that Java has, I’m not stupid or retarded and I’m not a fanboy. If you want to ruffle my feathers then you’ll have to try a lot harder than that. :stuck_out_tongue:

While we are spewing crap…

C++ can be exactly the same speed as C… depending on what features you use and how you use them C++ simply makes it easier to get a feature that you would have to write more code for in C. (E.g. jump tables in C vs. virtual functions in C++)

Assembly and machine code are exactly the same speed, because Assembly is simply a way to write machine code that is easier to read than a bunch of hex.

I can show you examples of Java programs that run faster than C++. It all depends on what you are trying to do. There are trade-offs to every alternative. In general VMs run a bit slower than native compiled code… but as should be evident to anyone paying attention, that is changing… VM technology is getting more advanced, raw computing speed in a VM is approaching that of natively compiled code. The small trade-off in speed that remains can be thought of as the cost of the benefits that a VM gives you (better error checking, and the productivvity that arrises from it… easy dynamic code loading, platform independance…)

There are several valid answers to both “Why?” and “Why not?”

Is Java a viable alternative for real commercial games… no need to ask it has already been used in successful commercial games, so obviously the answer to that one is “yes”… Is it the right choice for you and your game? That depends…

[quote]While we are spewing crap…
[/quote]
:wink:

[quote]C++ can be exactly the same speed as C… depending on what features you use and how you use them C++ simply makes it easier to get a feature that you would have to write more code for in C. (E.g. jump tables in C vs. virtual functions in C++)
[/quote]
Well, yeah, but that’s not really “using” C++ is it? I mean, it’s a superset of C so you could just not use any C++ features… ;D But yes, okay.

[quote]Assembly and machine code are exactly the same speed, because Assembly is simply a way to write machine code that is easier to read than a bunch of hex.
[/quote]
Well, if you know how to exploit machine code you can (“theoretically”) do things that assembly won’t let you do. Usually not good to rely on though…

[quote]Is Java a viable alternative for real commercial games… no need to ask it has already been used in successful commercial games, so obviously the answer to that one is “yes”… Is it the right choice for you and your game? That depends…
[/quote]
How very true! And I think that really sums up the whole argument doesn’t it?

As the Queen Mother once said: “Respec’!”

[quote]Well, if you know how to exploit machine code you can (“theoretically”) do things that assembly won’t let you do. Usually not good to rely on though…
[/quote]
Hmmm… I wouldn’t know one thing that would speed up your code.
The 2 things I can come up with is:

  • using unsupported opcodes (you better get a better assembler if it doesn’t support those instead of getting rid of your assembler)
  • crashing your computer (oh, right… you can do that with an assembler too ;D)

I think I skipped that theory lesson :stuck_out_tongue:

::slight_smile:

In pure rendering speed there is not much difference using openGL through lwjgl, and native c++. You should be able to pump as many triangles per frame in java. :slight_smile:

It just depends on the type of game your making. As to how much perfomace hit you’ll take using java. In alot of situations, the hit will be very low.

C++ is the fastest language around for making games.
Its complexity makes it a pain to use, but pros know how to get every last bit of performace out of it. Like the ability to go into asm blocks for those tight loops.

LWJGL is a blessing to the java community. It is perfect for alot of groups and individuals, that will benifit from using java. But pros have the tools and experience using c++, and can’t afford any performace hit.

As a java lover im really hoping sun can pull of the theoretical advantages of a runtime evnironment, to leave c++ behind with runtime optimizations.
But it hasn’t happend yet, and i doubt it will in the next few years if ever.

[quote]Hmmm… I wouldn’t know one thing that would speed up your code.
[/quote]
…And thus it began to worry me. I’ve never bothered playing with machine code myself, but I’m sure I read an article somewhere by someone who was hand-tuning assembly-generated binaries for speed. I don’t think the gain was much, but it was there.

However, I’ve had a quick search, and can’t find it. In fact I can find nothing to support the theory at all! With the lack of any scap of evidence, I withdraw my comment. ;D

I think I’m getting old… Apologies for any confusion/anguish caused. :wink:

[quote]But it hasn’t happend yet, and i doubt it will in the next few years if ever.
[/quote]
I think platform indepence is a problem here as we saw in the huge performance drop in 1.4 related to number crunching.
For that alone I’m not holding my breath for a faster than C++ VM.
That said, this doesn’t make java particulary slow and I think it’s easily fast enough for many sorts of games.
Just don’t create software renderers or other number crunching tasks and expect it to perform really well.

[quote]C++ is the fastest language around for making games.
[/quote]
No it’s not.
It’s features just can make it easier for creating games while accepting a performance drop here and there compared to straight C or assembly.

Erik

Right now, I can say with 100% certainty that if I had a mind to I could create a FPS game the equal of Quake 3 Arena in all respects in pure Java plus LWJGL. Fortunately for the world I’m not clever enough to render curves yet :slight_smile:

Now I’ve written Alien Flux and the infamous terrain demo I am intimately aware of what Java is capable of - and proved it. Something that ought to be taken into account is that I’ve got this stuff together in record time too considering I work largely on my own or in a tiny team. So there’s an advert for the technology.

As to why not use Java - well, it can be pain in the arse because we don’t have Structs, which is slower than it could be and more fiddly. But that’s my only major gripe apart from the JRE size & licensing terms.

Cas :slight_smile:

But they’re not really curves are they? (At least I though it was faked by using a bit larger number of polys in the ‘curves’ and smoothing them out by lighting).

For what it’s worth, I think Q3A would be easily possible too, but I suspect you would loose a few fps though, be it an acceptalble number.
Being able to create Q3A in much less time would’ve made it worthwhile still to do it in Java I suppose, because that’s probably a better argument for the business people than 100fps instead of 90.
And platform independance is a nice bonus thrown in with no extra charge (well, almost none).

Precisely. Who cares about 10fps? (Well, you would if you were running at 20fps in the first place :P)

I expect the Q3A development time could have been cut in half approximately, and released simultaneously on Mac, Win32, and Linux - as it is, those two ports took months of extra development time. The whole mod/dll scripty thing took a good long time to develop too and has to be different for all three O/Ss

Imagine the mod community! Dynamically downloaded mods from the server no matter what O/S you’re on! Woo! It just all makes sense. So let’s just hope they fix the issues with the current Java soon. (You listening, Chris?)

Cas :slight_smile:

Hi erikd, i don’t see how you can argue that c++ isn’t the fastest game proggraming language. Check out http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html

Talks about the improvements in compilers that have now let c++ bet fotran at its own game, in linear algebra and others. The improvements also mean that c to c++ difference is only in style.

Theres also more info in a ddj tech net cast from Mr Stroustrup.

Princec has has shown how much we can get out of lwjgl and java, to make real games that are close to their c++ counterparts. It will be interesting to see if any commercial game companies will start using java, with its huge productivity improvments.
There was a recent game that used python to control the whole game, using c++ for rendering functions and math.
Don’t have a link, but i think it was on orielynet.
There is a strong possibility of java being used similarly, as the control language, with platform specifc stuff were performace is critical.

[quote]Hi erikd, i don’t see how you can argue that c++ isn’t the fastest game proggraming language. Check out
[/quote]
As an aside, I love the first line from the conclusion:

“After nearly a decade of being dismissed as too slow for scientific computing, C++ has caught up with Fortran and is giving it stiff competition”

Considering Java2 was first released in 1999, if we beat C++ performance by 2009 we’re going to be improving faster that C++ did. Nice!

[quote]It will be interesting to see if any commercial game companies will start using java, with its huge productivity improvments.
[/quote]
But they already are! There already exist commercial games using Java in some way, all the way from using it as a scripting language (as in your Python example) to writing the whole game in it!

Like, ME, for example :slight_smile:

C++ and Fortan and C all have the potential to be more or less the same speed at doing anything because of their design - they can all, one way or another, get straight to the metal, and at the end of the day they all compile down to remarkably similar sets of machine code.

Java doesn’t, because it’s got some holes that need filling to do with memory access, and it’s got some deliberate safety nets which are entirely welcome; but even with those holes, I think I can squeeze the same performance out of my Java code as anyone can from their C++ code, and where necessary I can cheat and do little bits of JNI.

Cas :slight_smile:

[quote][…]
Imagine the mod community! Dynamically downloaded mods from the server no matter what O/S you’re on! Woo! It just all makes sense.[…]
[/quote]
q3 uses vms for mods. they are platform independed. one mod for all plattforms :slight_smile:

well there are dll based mods too but noone uses em anymore.

even pure q3 (aka vanilla) consists out of 3 vms (game, cgame(client) and ui) and q3 is the interpreter :slight_smile:

and curves (aka patches)… yes they r just a bunch of polys, build around some control points. u can change the amount of polys with r_subdivisions. “4” is the default value and pretty round “80” is somewhat blocky. btw the curves itself use LOD too (like player-models and items).

i worked (and i’m currently workin) on different q3 mods - i know alot bout this subject :slight_smile:

[quote]q3 uses vms for mods
[/quote]
Cool. So they took the same way as Unreal I? (which is heavily inspired by java).
What language do you use then for Q3 mods?

[quote]Hi erikd, i don’t see how you can argue that c++ isn’t the fastest game proggraming language
[/quote]
Because:

[quote]Like the ability to go into asm blocks for those tight loops
[/quote]
Doesn’t that make ASM the fastest language?
But I would agree that for games, you would be pretty insane to do it 100% assembly.
People went from ASM to C and C++ for the productivity gain, not for C++'s speed.
An argument which now also applies for using Java instead of C++.

That Fortran - C++ benchmark is interesting, but there’s lots of other benchmarks showing Fortran to be faster than C++ and Java to be faster than C++ even and then VB.net being faster than Java :P.
I’m not sure what to believe anymore except that benchmarks do not provide the rules except showing an example of 1 application alone, which is the benchmark code.

C. and a free available version of lcc produces *.qvm files out of it :slight_smile: