Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Quake2 Engine In Java

timothy posted about 10 years ago | from the if-you-long-to-shoot-'em-up dept.

Java 123

An anonymous reader writes "Ok, so the game is old and there was a really poor web version some years back, but some guys at Bytonic Software in Germany have done a full source port of the Quake2 engine from C to Java. It's cross platform, performs just about as fast as C and has room for further improvements according to the developer. Also, there was another game engine that ran Q3 maps that was shown recently at JavaOne. Are first generation Java games that far behind?"

cancel ×

123 comments

Sorry! There are no comments related to the filter you selected.

Java != Slow (5, Insightful)

kannibal_klown (531544) | about 10 years ago | (#10189655)

But I used java once, and it took forever to print Hello World. Java is slow. Java is stupid.


Maybe this will lay waste to claims that java is slow, bloated, and sucks.

I've only recently started doing heaving Java programming, and I have to say that the language is a dream to code with (provided you use a decent IDE). There're so many classes in place already, there's nothing you can't do. I'll take it over C++ any day, and MS's MFC is horrible on comparison.

My only problem with it is the deployment; screwing with class paths and what not.

People need to realize that most of the overhead they experience with their "hello world" experience has to do with loading the classes in the beginning. Once that is done, Java performs nicely.

Sure, straight C is faster, but Java isn't the turtle everyone makes it out to be.

Re:Java != Slow (5, Informative)

blackbuddha (786289) | about 10 years ago | (#10190312)

http://classworlds.codehaus.org/ [codehaus.org] will make your class path issues go right away. No more messing with the environment settings, no more screwing around with file paths, and only 29K of code.

What?! (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10190574)

Have you actually tried it though? I did this morning and it's TERRIBLY slow. Their "just about as fast as C" comparison is WAY off.

This isn't a troll, it's a fact. Check it out for yourself and see.

Re:What?! (1)

GeckoX (259575) | about 10 years ago | (#10191575)

Not to mention the fact that I kinda doubt the port is being played on the same hardware that the original was played on at the time.

It had BETTER perform as good on todays hardware, and that I kinda doubt...though I haven't tried yet.

Re:What?! (1, Informative)

Anonymous Coward | about 10 years ago | (#10192523)

Have you actually tried it though? I did this morning and it's TERRIBLY slow.

I ran it here and there was no noticable speed difference and a little benchmarking only showed it to be marginally slower -- although perhaps there would be a bigger difference on slow hardware. One thing I did notice though was that it was a bit buggy, this ranged from a few small anoyances like mouse2 and mouse3 being mixed up in the preferences so my old config file had to be edited to the fact that it always crashed on exit forcing me to do a 'killall -9 java' which makes you doubt the common assertion that Java code is less buggy than C code (of course this hasn't had the level of testing that Quake 2 had nor has it been developed by the likes of Carmack).

Re:Java != Slow (2, Insightful)

Prior Restraint (179698) | about 10 years ago | (#10190607)

Maybe this will lay waste to claims that java is slow, bloated, and sucks.

I would be more inclined to agree if this story were on the main page.

Java != Slow, but that doesn't mean it's good. (-1, Flamebait)

Paradox (13555) | about 10 years ago | (#10190792)

Maybe this will lay waste to claims that java is slow, bloated, and sucks.
Java was never slow and bloated when compared to members of its own weight class. You may be tired of people saying "Java is slow!" but I'm even more tired of Java Developers parading this around, like they only not just found out about it. We're all happy for you folks. Welcome to the year 2001. Now, can we please start focusing on the real issues?
I've only recently started doing heaving Java programming, and I have to say that the language is a dream to code with (provided you use a decent IDE).
Ahh. Yes. Java, a dream to code with provided you use a decent IDE. Most people can code quite well with a 100 line elisp module to handle formatting, brace/paren matching and complile control. Java people needs the equivalent of a bustling shipyard with hundreds of dockworkers to move code around.

Whizbang IDEs are nifty and all, but here's my feeling on it: if your language is so hard to work with that you require and IDE to develop and refactor in a reasonable amount of time/effort, then you do not have a language that is "a dream to code in." Having worked with Java, I'd say a powerful IDE like Eclipse is a requirement.

It's not that these IDEs are bad! They're great, but they should be the icing on the cake. Your language should allready be usable pre-IDE.

I'll take it over C++ any day, and MS's MFC is horrible on comparison.
Not that I'm a huge C++ lover, but I have to say... you're right. It is a horrible comparison. MFC is the absolute worst environment in C++. Feel free to continue ignoring quality C++ tools for application development, like Qt, TAO, and the outright amazing Boost libraries.

Sorry. Just because you can make a very old and relatively simple hardware-based game engine run in Java doesn't suddenly mean it doesn't suck. It still sucks, it's just that people are finally realizing why it sucks so badly (and it's not speed).

Re:Java != Slow, but that doesn't mean it's good. (1)

L7_ (645377) | about 10 years ago | (#10191182)

Having worked with Java, I'd say a powerful IDE like Eclipse is a requirement.

Lots of people were writing Java code long before Eclipse was released. A random text editor (Textpad) interfacing with Java1.1 was sufficient to write and compile a lot of early java code. I think that the JRE was setup so nicely that its integration into IDE's is/was so easy that everyone writing Java is now using an interactive IDE. Its not that the language requires one, its just that thats how programming is done nowadays.

Re:Java != Slow, but that doesn't mean it's good. (1)

GeckoX (259575) | about 10 years ago | (#10191698)

He wasn't stating required use of an IDE to develop Java in, he was questioning the grandparent posters statement that Java 'is a dream to code with (provided you use a decent IDE)'

Re:Java != Slow, but that doesn't mean it's good. (0)

Anonymous Coward | about 10 years ago | (#10198673)

Congratulations; you just posted the most utterly obvious comment I have ever read on Slashdot.

Please go hang yourself.

Re:Java != Slow (1, Flamebait)

zangdesign (462534) | about 10 years ago | (#10190899)

but Java isn't the turtle everyone makes it out to be.

Until you run it on a 500-mHz iBook, don't make that claim.

Re:Java != Slow (1)

GeckoX (259575) | about 10 years ago | (#10191635)

How's about we try running it on a P 233 with 64MB ram and see how it performs.

That would be a fair comparison.

But yeah, wonderful point I wish would be conceeded before comparisons are made.

Re:Java != Slow (1)

aminorex (141494) | about 10 years ago | (#10195959)

Why not run it on a MITS Altair 8080/24KB?
Can't find one? Neither can I find a P233/64MB
any more.

But yeah, what the world needs is a good 50k VM.

Re:Java != Slow (1)

shufler (262955) | about 10 years ago | (#10197134)

I have a P2 200Mhz, though it has 128 MB of RAM.

I found it in the garbage.

Re:Java != Slow (1)

Short Circuit (52384) | about 10 years ago | (#10200098)

I was wondering where that went. What are you doing sifting through my bedroom, anyway?!

Actually, I've got a K6 200 that first ran Windows 95 OSR2, then ran Linux. Still not sure what to do with it now.

Re:Java != Slow (1)

shufler (262955) | about 10 years ago | (#10201771)

Mine handles most of the services for my LAN. DHCP, DNS, and one of those clients that updates your dynamic host. Ideally it would also be a router and firewall, but I have one of those hardware dealies.

Up until a few weeks ago, when I found the majority of the parts in the trash, the box was a P 100, with 32 MB of RAM.

I'm running Slack 8 on it, and it runs perfectly well. Once upon a time, when it was the P 100, it ran Win95B, and had a security camera attached that was known by those not in the know as a "web cam."

The original box has seen me through tough times, such as the time the 500 MB drive in my P90 died (literally smoked poured out of the case), and I resorted to using my 386 and Slack 3. This turned out to not really be a viable option, since I had to do web development for IE4. This box decided to make itself known to me, so I took it in from the cold.

Re:Java != Slow (2, Insightful)

GeckoX (259575) | about 10 years ago | (#10199557)

I believe you missed my point entirely. Stating that Java is as fast as C because an 8 year old game has been ported to it, and it runs fast on hardware that's 8 years newer than the original game would have been played on is NOT a valid comparison in any way.

I'm not suggesting that Java sucks unless it can run on a P 233, which is how I think you took my comment.

Java + C != Slow (0)

Anonymous Coward | about 10 years ago | (#10191267)

I will admit that I didn't dig into the code, but it seems that jake uses jogl and joal for the graphics and sounds rendering.

Now, just following the links to these 2 libraries teaches me that they are mere bindings to C libraries (or I am mistaken, like I said , I didn't dig into the code).

I guess that the pure java part does more than just delegating everything to some C engine, but claiming that Java gaming has come to age seems a bit premature, given that it relies on C for its meaty parts...

Re:Java + C != Slow (1)

GameNutz (556033) | about 10 years ago | (#10191719)

And so Java accesses the hardware in the same manner that C or C++ accesses the hardware. So what? C relies on assembly :) The fact is that a Java coding solution, coupled with open source bindings that run on several platforms, makes a more compelling argument than a single platform C++ implementation of a game.

Re:Java + C != Slow (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10192016)

You're an idiot. J2SE doesn't come with APIs that access graphics and audio hardware. That's what the jogl and joal libraries are for. Are you going to claim that because the JRE is written in C, you have to include the "+ C" when you say that Java isn't slow?

Re:Java + C != Slow (1)

GameNutz (556033) | about 10 years ago | (#10192172)

Where did I state that J2SE came with these APIs? The JOAL/JOGL APIs are additional packages that are required to make the Java application work on the various platforms. Just like a C++ requires a OGL or DX binding. Furthermore, why is it so difficult to believe that Java may be a perfectly acceptable language for high performance game development? In fact, depending on the application, Java applications can be FASTER than compiled C++ apps. Just one of the many benefits of compiling at runtime on the actual client hardware vs. compiling on development systems and hoping for the best.

Re:Java != Slow (4, Interesting)

FedeTXF (456407) | about 10 years ago | (#10191341)

Moreover. Im running Java 5.0 RC and the client VM has this nice feature called Class Data Sharing [sun.com] and I can see how much faster the startup times are. I'd say 2 to 3 times faster.

Re:Java != Slow (-1, Troll)

Anonymous Coward | about 10 years ago | (#10191954)

Obviously, you aren't a very good programmer, if Java is such a dream to code with. For me, it's more of a nightmare. Sure, it's not as much of a bloated wreck as JIT compilation has improved, but it still doesn't hold a candle to a "real" language like C++ or Lisp or Python or Ruby that gives you the ability to reach under the hood and do stuff.

Re:Java != Slow (4, Funny)

macrom (537566) | about 10 years ago | (#10192111)

I've only recently started doing heaving Java programming

I hear ya, man. I did Java programming once and it made me heave.

:^)

Turtle language (5, Funny)

John Harrison (223649) | about 10 years ago | (#10192908)

Sure, straight C is faster, but Java isn't the turtle everyone makes it out to be.

No, that is Logo.

Re:Java != Slow (0, Redundant)

Bill Dog (726542) | about 10 years ago | (#10194250)

Maybe this will lay waste to claims that java is slow, bloated, and sucks.

Java is slow, bloated, and sucks. But it sucks only compared to the power and freedom you get with C++. As a language it's superior to VB, I feel. And slow and bloated is okay on the server, where it won't be noticed. Nowadays better than risking security problems with a coding mistake in C++. In general, C++ is best suited for the client, and Java for the server.

I'll take it over C++ any day, and MS's MFC is horrible on comparison.

MFC is wonderful compared to 6502 assembly on the Atari 800 I had in high screwl. So what? MFC was created a long time ago, during the 16-bit era. It made some compromises for speed (e.g. message map macros instead of gazillions of virtual functions). It was created before C++ was standardized, and frankly, before the OO community had learned some lessons (some of which Java directly benefitted from). But it provided a nice MVC framework, and handles all your menu and toolbar and other GUI stuff for you. I started with C and the Win32 API, so MFC was "a dream to code with" in comparison. I wish we would evolve from saying something sucks or is horrible, and just accept that they "are", and pick the best one for each task.

VB a language? (1)

jjga (612356) | about 10 years ago | (#10196766)

As a language it's superior to VB

VB is not a programming language, but a development tool that includes some sort of Basic language, in a similar way that Delphi includes Pascal.

Re:Java != Slow (4, Insightful)

angel'o'sphere (80593) | about 10 years ago | (#10199666)

MFC is wonderful compared to 6502 assembly on the Atari 800 I dare to challange that.
MFC was created a long time ago, during the 16-bit era. Thats no excuse for creating bull shit.
It made some compromises for speed (e.g. message map macros instead of gazillions of virtual functions). A virtual function is in most circumstances faster than a message map macro.
It was created before C++ was standardized, and frankly, true!
before the OO community had learned some lessons (some of which Java directly benefitted from). wrong!
When the MFC was crafted there existed plenty of better alternatives.
a) MacApp, Apples C++ Application FrameWork
b) TCL, Think Class Library, later Symantec, a simplyfied clone of MacApp
c) Borlands Application Framework
e) ET++, a cross platform C++ GUI and Application FrameWork
f) Taligent research Frameworks, off springing from ET++
g) BedRock a Borland + Apple + others attempt to make a Mac/PC cross platform Application FrameWork

Every SmallTalk environment was allready far better than MFC in the early 70ties. CLOS and other lisp derivates allready had pretty well working GUI and Application FrameWorks.

Bottom line: M$ was unable to craft a good C++ compiler. So they made a shitty incompatible slow monster with M$ specific extensions. Crafted a library relying on that extensions and sold that as "development environment".

But it provided a nice MVC framework, and handles all your menu and toolbar and other GUI stuff for you. I started with C and the Win32 API, so MFC was "a dream to code with" in comparison. I wish we would evolve from saying something sucks or is horrible, and just accept that they "are", and pick the best one for each task.

Your luck was that you did ot know better, I allways went out for one hour to hack lumber to get my agressions off, when I needed to work on a PC in 1993 till 1998 in "Windows" C++ and "Windows" libraries. Using Symnatec C++ (Walther Bright, anyone?) softened that pain a bit. The pain was further softend by using the zApp GUI libraries and not MFC. After searching 6 weeks for a good GUI Framework, the GUI of my app was made in 2 days, not with MFC, but with a true framework.

I really don't blame M$ and gates for making money and trying to dominate the market.

I blame them for throwing the whole computer age back by 30 years at least. They did so by killing so many good ideas and good companies. It took until 2000 to get again new ideas established in using and programming computers.

Now hey are copying all good ideas from unix/linux/mac os x from KDE and GNOME. If they can dominate again, by killing Sun and bying SCO, or whatever, a lot of progress will be "removed from the market" again.

Compare AppleScript versus Visual Basic. The first one is ingenious easy and the second one is ruling front end programming, but is utter crap.

angel'o'sphere

Re:Java != Slow (1)

phoenix_rizzen (256998) | about 10 years ago | (#10209112)

[quote] And slow and bloated is okay on the server, where it won't be noticed. [/quote]

Oh, it's definitely noticable, even on the server. For our use, anyway. Unfortunately.

We're trying to run IBM's WebSphere Portal and Lotus Workplace Manager, both of which are written in Java. The web server is a dual Xeon 2.4 GHz with 4 GB RAM and SATA drivers. The database server is also a dual Xeon 2.4 GHz with 2 GB RAM. Both are running RedHat Enterprise Linux 2.1 AS. Get three people signed into Workplace, and you can literally watch the screen draw itself line by line as the load on the server climbs into the mid-double-digits. Even the Lotus and IBM techs can't figure this one out. We're in conference calls with them three times a week trying to get this working.

Java on my Celeron 1 GHz laptop with 256 MB RAM running FreeBSD 5.3-BETA3 and KDE 3.3 is a lot smoother running WebSphere Development Studio or Eclipse.

Re:Java != Slow (0, Flamebait)

An El Haqq (83446) | about 10 years ago | (#10198393)

Maybe this will lay waste to claims that java is slow, bloated, and sucks.

Well, it may lay waste to claims that Java is slow, but I think it's hard to argue that it's not bloated. And, of course, Java does suck for rapid prototyping. However, it doesn't suck so much in other contexts.

Mostly, I just wanted to type the word suck.

Re:Java != Slow (1)

angel'o'sphere (80593) | about 10 years ago | (#10199682)


And, of course, Java does suck for rapid prototyping.

then look for a better IDE or better RAD tool. There are plenty.
angel'o'sphere

Re:Java != Slow (0)

Anonymous Coward | about 10 years ago | (#10198626)

Java is still slow and bloated. No way around that.

Quake 2 was supposed to run on 200 MHz, 32 MB machines. The java runtime wouldn't even fit in it! If Carmack knew the hardware it is being tested with Java, he would do some optimizations (even I could do that!) that a much more limited hardware does not allow you to. Thus the comparisons and benchmarks are simply not fair.

Further, the program itself runs only single player. Just adding multiplayer support would surely slow their results

0.9.2 version released (4, Informative)

tod_miller (792541) | about 10 years ago | (#10189656)

First released notice [javalobby.org] in May.

This is a good demo of the power of Java, it handles the game, then passes this smoothly to the native opengl rendering. Jogl is great, I hope I can find time to work with it some more.

Those crazy Germans do deserve some awesome credit for this! (having lived in Germany I can say I love Germans, and they are crazy! :-)

Sourceforge page [sourceforge.net]

Re:0.9.2 version released (4, Funny)

FFFish (7567) | about 10 years ago | (#10190819)

German effort, eh?

I guess that's why they didn't port Wolfenstein.

[FFFish waves good bye to his karma...]

Re:0.9.2 version released (1)

plj (673710) | about 10 years ago | (#10192377)

Hey, the only time I've even seen Wolf 3D was when my family was visiting our family friends near München, probably at the same time that game was rather new -- and at that time I knew next to nothing about computers yet. But I still remember those Nazis in the game...

Well, it is of course possible that the game was an illegal copy anyway. I don't really know. At that time I didn't really understand any copyright stuff as I do now, and I couldn't discuss with the boy who played it, as I was only something like 12-13 years old at that time, he was a year younger, and we didn't really have any common language, except what few words of English we both spoke.

Re:0.9.2 version released (1)

Electrum (94638) | about 10 years ago | (#10193484)

Wolf 3D ... Well, it is of course possible that the game was an illegal copy anyway.

Or the shareware version.

Quake II .NET (0, Offtopic)

News for nerds (448130) | about 10 years ago | (#10189871)

Re:Quake II .NET (1)

GameNutz (556033) | about 10 years ago | (#10190233)

Does it run on a Mac? Does it run on Linux? So why bother if it already runs on Win32 anyway? The Java version runs on 3 platforms with no further modifications.

Not cross platform, so why java? (0)

Anonymous Coward | about 10 years ago | (#10191732)

No, it doesn't run on a Mac. Their site claims only win2k/XP and linux compatibility, so it won't even run on win9x like the original.

Why did they write this in java if not to make it cross platform?

Why write anything in java, if not to make it cross platform?

Re:Not cross platform, so why java? (1)

GameNutz (556033) | about 10 years ago | (#10191825)

Re:Not cross platform, so why java? (0)

Anonymous Coward | about 10 years ago | (#10192195)

I stand corrected, and informed.

Still, given the bug list on that page I suspect the .net version is a bit more playable :p

(sticking with the original, myself)

Re:Quake II .NET (1)

kryptoknight (638324) | about 10 years ago | (#10193344)

In addition the Managed C++ Quake II .NET also has an extended feature for Quake Radar.

Re:Quake II .NET (2, Insightful)

bay43270 (267213) | about 10 years ago | (#10193888)

By "ported to Managed C++" you really mean "compiled to IL to run on the CLR". There's a big difference. This code is not managed, its just unsafe code running in a VM (there was more information on this on Channel 9 last week). The radar program they created was written in managed code.

Re:Quake II .NET (-1, Troll)

Anonymous Coward | about 10 years ago | (#10203438)

How the hell is this post a troll? Fuck you moderators.

Hooray (4, Funny)

Shinglor (714132) | about 10 years ago | (#10190582)

Now you can have the eye candy of Quake 2 with the speed of Doom 3!

But do we care? (5, Insightful)

Turn-X Alphonse (789240) | about 10 years ago | (#10190666)

I don't care if it's running in Java C D E or bloody Z, as long as the game runs well and looks playable (AKA not shooting green blocks to make red blocks appear with a black block and various brownish walls. ).

No gamers is going to go "Doom 3 running on Java!? I'm so not buying that!" or "Doom 3 is running only on C++ I'm not playing that!". No one but the coders themselvs and the modders will truely care what it's written in as long as it runs okay and looks good.

So gonna get modded Troll..

Re:But do we care? (1)

GameNutz (556033) | about 10 years ago | (#10190834)

But a developer looking to deploy to more than one platform without having to port the app. will sure as hell care. Look what happened to the NWN launch. If they had used Java for the game vs C++ then you would have been able to play on your Linux box instead of waiting for 1+ years for it to be ported to Linux. I agree that a game player could care less, so long as it looks good (and more importantly plays well), but if more developers moved to a true cross platform technology wouldn't the Mac/Linux platforms be even more attractive to consumers? (Less bugs/crashes/virus but a bigger selection of entertainment titles to chose from)

Re:But do we care? (4, Insightful)

iwadasn (742362) | about 10 years ago | (#10190886)


I'm a Mac user, I care. Too often Mac games come out years late and with dozens of bugs added in just for the fun of it. If the development houses would either do as blizzard does, and develop quality software, or at least write in java so I get the same bugs as everyone else, I'll be happy.

This is after all the bottom line. I don't want to wait 4 years for a buggy Mac port to come out, and I don't want to use windows at home just so I can run the latest games. If more people went this route then it's likely that there would be more high quality games for everyone. Just write it once, release the java for OS X, Linux, BSD, Windows, whatever, and then use something like GCJ to turn your java code into a good executable for XBox or PS2. Of course I'll hear the C coders say "But C can be portable." and it can, but only if you know what you're doing and actually put in the effort. History has shown that very few people fall into this category, so we need java.

Everybody wins, especially me. :-)

Re:But do we care? (1)

TomorrowPlusX (571956) | about 10 years ago | (#10192012)

Ironically, the webstart crashes ( OS X.3, java 1.4.2_05 ).

I'm no java expert ( I'm a rabid portable C/C++ guy... ) but it looked like the opengl bindings loaded by webstart weren't compatible. Could be a packaging error (x86 native JNI binary?), or it could be any number of things.

Anyway, I still think it's incredibly cool.

Re:But do we care? (4, Insightful)

kaffiene (38781) | about 10 years ago | (#10195280)

No, users shouldn't care at all. But I can tell that there has been huge developer resistence to the idea that Java can do games at all.

That's relevant because games need good quality game libraries and noone will write them for a target they think can't cope with the task.

Re:But do we care? (1)

mattgreen (701203) | about 10 years ago | (#10197405)

Well put. When you care about technology for its own sake -- rather than how it can solve problems for you -- you're taking it too seriously. This applies for operating systems, programming languages, text editors, etc.

The performance is alright now... (3, Insightful)

jmhewitt (811760) | about 10 years ago | (#10192087)

but what about when Quake2 came out? The code runs at about 60% performance on today's machines. So when Quake2 was released, Quake2 Java would have broken my machine, as it barely ran the orignal Quake2 version. Java can offer portability over platforms but games often push hardware to its limits and so may raise the bar on minimum system specs.

Re:The performance is alright now... (1)

GameNutz (556033) | about 10 years ago | (#10192282)

Sort of....10% of released games really stress modern systems that a real gamer has (D3/HL2/FarCry/Halo/etc.) And when did a game ever run with the "mininum requirements" that you were happy with? ;) Hey, you can play Q3 on a GeForce 3, so don't buy that new graphics card. Could Sims have been done in Java? Could WarCraft 3? :)

Re:The performance is alright now... (1)

Profound (50789) | about 10 years ago | (#10199502)

Q2 used to run fine with 64 megs of ram while these guys are probably using 256 or 512mb when performing these benchmarks (they don't say). Fine on a PC where RAM is cheap, but remember that current generation consoles still have 24-64mb.

Also, Q2 was written for a time with significantly different CPU:GPU performance ratios (eg before Hardware transform & lighting) so the benchmarks don't mean much.

I have seen JOGL and I am quite impressed with it, I wouldn't be suprised to see multithreaded Java being used in the next generation of consoles. Assuming they can do something to guarantee near-realtime performance.

Re:The performance is alright now... (1)

dbIII (701233) | about 10 years ago | (#10208584)

Java can offer portability over platforms but games often push hardware to its limits and so may raise the bar on minimum system specs.
One interesting thing would be whether it can all be trimmed down enough to run on a telephone - and porting it to java makes that possible. Slow processor, not much memory, but 128x128 pixels means you can get away with a lot of hacks and still get a good image.

Why Java ? (0)

Anonymous Coward | about 10 years ago | (#10192280)

Currently supported operating systems are Linux and Windows2000/XP.

Doesnt the fact that only windows and linux are supported sort of defeat the object of doing it in Java?

Re:Why Java ? (1)

GameNutz (556033) | about 10 years ago | (#10192321)

See above.

The language does not always matter (5, Interesting)

Alban (86010) | about 10 years ago | (#10192558)

The important thing to know is that the majority of your performance gains are obtained by scheduling the hardware intelligently, keeping the CPU and GPU well balanced, i.e. busy at all times. And of course, that your tight loops are really optimized, that you do not fragment memory, etc. That, for the most part, has nothing to do with the language your using, but simply with your programming skills.

By the way, what hardware have they tested on to claim that performance is similar? If it's modern hardware, then of course it will run at 60+ fps no matter what.

What's more, I would guess the bulk of the work on the CPU for quake2 consisted in traversing the BSP tree, building the scene (with transforms still being performed on the CPU at that time) and collision detection. The rest is taken care by the graphics hardware so that's totally independant of the language you've used.

There is one thing that bothers me with Java though. You never know when the garbage collection will be performed. Sure, recent virtual machines make it possible to perform garbage collection in smaller but more frequent iterations so you don't halt the system for a few seconds like early virtual machines would do. But still, if you're in a tight loop with your data and instruction cache perfectly populated, and all of a sudden the garbage collection kicks in, then your cache is toast and data will have to be refetched to it when execution resumes. That would result in a horrible performance loss provided you are already really close to the machine's limit. Also, what I'm saying is only pertinent on a console with no (or almost no) OS, because on any PC operating system, your process can be interrupted at any time by the various system tasks that are running, so the garbage collection interrupting your tight loop would only be one of many possible interruptions.

I don't believe java can be as fast as native code, although probably extremely close. And sure, a good java compiler will generate faster code then a crappy C++ compiler.

Another thing I don't like about java is that you have no control over memory (not that i know of, maybe some recent VM extensions allow you to have some control over that?). I really like to be able to give different sets of alloc/dealloc routines to the different subsystems in a game. A subsystem that is known to perform very small allocations/deallocations very often could be passed alloc/free routines that are customized to its use so that memory fragmentation is kept to a minimum. If such a component was allowed to get memory from the same pool then your other subsystems, it would wreck havoc on your memory.

Anyway, it's not such a good idea to compare java and C++ (or whatever other languages) on a system where resources are abundant (PCs).

By the way, Jak & Daxter for the ps2 is written in a lisp derived language (GOAL), yet that game outperforms and looks better then almost everything else on the ps2. Yet lisp is not perceived as a high performance language. But the people at Naughty Dog have developed their very own compiler that is extremely specific to their needs (see their gamasutra post-mortem, very cool read) So, it goes to show that the notion of performance shouldn't be tied with a language, but rather with that language's runtime & compilers.

Ok enough ranting!

Re:The language does not always matter (1)

michaelggreer (612022) | about 10 years ago | (#10193350)

Your garbage collection point is good, but I don't quite understand what you mean by "I don't believe java can be as fast as native code". Java has for some time compiled byte code to native.

Re:The language does not always matter (1)

Alban (86010) | about 10 years ago | (#10194277)

Sorry, my use of the word native was misplaced. I meant couldn't be as fast as a language that's closer to machine code.

When you write code in C, it translates pretty naturally into machine code.

With C++, some unexpected stuff can happen. Implicit conversions, temporary objects, late binding when resolving virtual methods, etc. But if you know what you're doing, you can still pretty much avoid the C++ gotchas.

In Java, there is even more unexpected stuff that happens behind the scenes, and that's sorta of what I meant. But I'm not really explaining it well, forget it. ;)

Re:The language does not always matter (3, Insightful)

Anonymous Coward | about 10 years ago | (#10193635)

I don't believe java can be as fast as native code, although probably extremely close. And sure, a good java compiler will generate faster code then a crappy C++ compiler.

The usual 'support' for this argument goes: "Java programs have to be interpreted from bytecode and then run, but native code only has to be run. Bytecode interpretation slows you down.".

That seems to ignore HP Labs' Dynamo [arstechnica.com] project, which showed that an HP-PA 8000 emulator running on an HP-PA 8000 could run code faster than native HP-PA 8000 code.

If interpreted HP-PA 8000 code is faster than native HP-PA 8000 code, I imagine a bytecode would have to be pretty poorly designed to perform worse. In fact, since JVM was built to be interpreted, I hope it's a lot better.

Java probably isn't the best example of this, but I see no reason why a high-level, byte-compiled language couldn't run as fast or faster than native code, assuming a standard operating system with libraries and so forth.

Re:The language does not always matter (1)

FedeTXF (456407) | about 10 years ago | (#10194091)

The whole point of games in java is abstracting. The CPU power and memory size has arrived to a point where you can afford to write high level multiplatform code based on a VM and run smoothly. This may not be for the latest eye candy 120 FPS 3d live action game, but it can be. As the JVM gives better support to access 3d native engines there's a huge incentive to code games in java. I think SUN is putting lots of money on this and they seem successful. Imagine the huge amount of code you don't have write or maintain.

Re:The language does not always matter (4, Informative)

the eric conspiracy (20178) | about 10 years ago | (#10195523)

if you're in a tight loop with your data and instruction cache perfectly populated, and all of a sudden the garbage collection kicks in, then your cache is toast and data will have to be refetched to it when execution resumes.

Actually, in the more recent JVMs garbage collection improves cache coherency through memory locality - newly allocated memory is likely to be close to already allocated memory, and thus in the cache.

The same techniques can be exploited to cause stack allocation instead of heap allocation, another speed win.

As far as compilation goes, Java compilers don't extensively optimize. Java optimizations typically occur at run time, which gives you a far greater range of possible strategies than the static compile time optimizations that are possible with C. Some people now think that run time optimization will eventually lead Java to be a higher performance language tham C.

I don't believe java can be as fast as native code, although probably extremely close.

It will be interesting to see how this works out, I'm betting that for a significant class of problems, large general purpose software, Java's runtime optimization will make it a clear winner.

For small programs that can fit in a CPU cache though, I think Java will be slower to overtake C, if ever.

Re:The language does not always matter (1)

Jordy (440) | about 10 years ago | (#10197291)

There is one thing that bothers me with Java though. You never know when the garbage collection will be performed. Sure, recent virtual machines make it possible to perform garbage collection in smaller but more frequent iterations so you don't halt the system for a few seconds like early virtual machines would do. But still, if you're in a tight loop with your data and instruction cache perfectly populated, and all of a sudden the garbage collection kicks in, then your cache is toast and data will have to be refetched to it when execution resumes.

What really bothers me is how rarely (if ever) a Java or C# program will release memory back to the system. It seems that they just take more and more resources away from the system and never release it back. This combined with a lazy garbage collection and programmers that don't worry about memory makes many Java programs horribly bad neighbors to other processes running on a dekstop.

I can't imagine what would happen when we have a shared VM that never exits. I suppose you'd have a long running app that uses the VM and then start a game that uses 3/4 of the memory then quit and your shared VM now has 3/4 of your memory. Now you can't start Photoshop because the VM refuses to release memory to the system.

I see a lot of benchmarks comparing C++ and Java and how the memory allocaton/deallocation in C++ is so much higher. I imagine if they never released memory back to the system and allocated large chunks of memory at once, performance of allocations would increase significantly. Sure it still has to do a best fit, but then so does Java.

Re:The language does not always matter (1)

angel'o'sphere (80593) | about 10 years ago | (#10199884)


What really bothers me is how rarely (if ever) a Java or C# program will release memory back to the system. It seems that they just take more and more resources away from the system and never release it back. This combined with a lazy garbage collection and programmers that don't worry about memory makes many Java programs horribly bad neighbors to other processes running on a dekstop.

And how exactly does a C/C++ program release memory to the system?
By calling strunbrk() or what?
Future operation systems, cough cough, or Solaris e.g. offer or will offer options for VMs to tell teh OS how their status is.
Also, shared VMs do not necessaryly mean that they have only one process space. When a process terminates its resources get available again. Regardless if it is running in its own VM or in a shared one.
Finally: current OSes have probably a limited amount of swap. And swap space is the only resource which is occupied, besides file handles and such. If you swap is big enough you never have the situation you describe. Future swap strategies might be optimzed for VMs.

angel'o'sphere

Re:The language does not always matter (1)

BenjyD (316700) | about 10 years ago | (#10202427)

>And how exactly does a C/C++ program release memory to the system?

With delete/free maybe? Freeing the memory explicitly allows the OS to decide when it will reallocate that memory to something else, rather than the VM, which has no knowledge of other processes.

Even if you have enough swap, wasting available physical memory will kill performance as the OS swaps data in and out.

Re:The language does not always matter (2, Insightful)

angel'o'sphere (80593) | about 10 years ago | (#10207600)

With delete/free maybe?
maybe? ... maybe not?
To which OS exactly do you refer?

Neither: Mac OS X, Mac OS 4 to Mac OS 8, DOS, Windows (3.1, NT, 95, 2000, XP) , Unix, Linux, or Mainframe OS does that.

You simply have a misconception what freeing of memory (using free() etc.) means.

angel'o'sphere

Re:The language does not always matter (1)

BenjyD (316700) | about 10 years ago | (#10211171)

AFAIK, freeing the memory marks it as available for the OS to reuse elsewhere.

The fact that many OS's will not *actually* release the memory straight away if there isn't much pressure on memory in order to reduce memory fragmentation and speed up allocations for the program doesn't alter the fact that it is at least available - you don't have a second operating system running inside the main OS.

Re:The language does not always matter (2, Interesting)

FyRE666 (263011) | about 10 years ago | (#10205126)

There is one thing that bothers me with Java though. You never know when the garbage collection will be performed...
Actually on mobile phones, where you're working with extremely limited hardware and very little RAM, it's common practice to force the garbage collector to run regularly. I usually call the gc in the central game loop to prevent "hitches" during play as a large(ish) block is freed up randomly.

Since just about every game I've written is under 30k in size (including graphics and sound), and most run in phones with as little as 100k of usable RAM, no hardware sprites etc, I'd say that Java can be pretty efficient!

garbage collection? (2, Interesting)

dayeight (21335) | about 10 years ago | (#10192834)

Now I haven't used java since 2000, but have they fixed the seemingly random garbage collection? I remember seeing a raytraced wolfy3d java demo years back, and garbage collection would make it go to a stand still at random intervals.

Re:garbage collection? (1)

Stevyn (691306) | about 10 years ago | (#10197215)

I think the point many people are trying to make is that while java used to be slow, it's better. With linux becoming more popular, I think java could get more popular. If a developer can compile a program and have it "just work" on mac, windows and linux, then he can focus on making the program better, not more compatible. I've worked with java and it's pretty easy to use. Version 1.5 (or now 5.0) is supposed to have some nice features to make it easier.

High performance Q3/D3 graphics engine (4, Informative)

GameNutz (556033) | about 10 years ago | (#10193285)

For those of you who need to see what is happening with a high performance Java game engine running more modern games, check out the Aurgia 3D game engine http://www.auriga3d.org/pictures/picture.cgi?pict= q3dm1-1 [auriga3d.org]

A brief snippit from the developer site:

Auriga3D is an advanced real time game engine built on an extensible plugin framework. Presently, the engine is geared towards BSP style rendering popular in FPS games such as Quake3 & Doom3. In the future there may be additional plugins created that allows other rendering techniques such as height maps to be accessible. A goal of Auriga3D is to allow independent developers the ability to develop new games with existing content creation technology.


Feature Glimpse:
# OpenGL Binding Agnostic; supports JOGL & LWJGL
# Quake3 Map Support
# Texture Mipmapping
# Multitexturing
# Trilinear Filtering
# Multiple Vertex Array Rendering or VBO Rendering
# Lightmap Rendering
# Potential Visibility Set
# Frustum Culling System
# JPEG, TGA, PNG texture support

Re:High performance Q3/D3 graphics engine (0, Troll)

superpulpsicle (533373) | about 10 years ago | (#10193744)

High performance java... that's like saying fast Geo metro.

Re:High performance Q3/D3 graphics engine (1)

Hassman (320786) | about 10 years ago | (#10194779)

If you tweak your Geo enough it can be more than fast...

Havn't you seen Fast and Furious? :)

Re:High performance Q3/D3 graphics engine (0)

Anonymous Coward | about 10 years ago | (#10195427)

Go faster Neddy! I CANT ITS A GEO!!!!

Simpsons 1 - That Guy 0

Re:High performance Q3/D3 graphics engine (1)

Hassman (320786) | about 10 years ago | (#10200267)

I never saw the movie actually...is that a line from it?

I just assumed they were ricing up shitty cars...

Native Libraries? (1)

rbeattie (43187) | about 10 years ago | (#10195396)

Ummm. What are all those Windows .dlls and Linux .so's doing in the distrib? I'm assuming they're for the graphics stuff... It seems you could probably get JavaScript to manage the game play if you offloaded all the heavy graphics lifting to compiled native libraries like this seems to do.

-Russ

Re:Native Libraries? (2, Informative)

OmniVector (569062) | about 10 years ago | (#10196580)

those are the native implementations of jogl and joal (java opengl and java openal). you have to have native c interfaces with the system libraries to achieve these sorts of things.

Wow, what a crock (4, Informative)

Anonymous Coward | about 10 years ago | (#10195525)

The summary says "Runs almost as fast as the original code!"

The article says "Runs somewhere between 60 and 85% of the speed of the original", and this is on modern hardware.

Let's see how it performs on hardware that was actually used to play Quake 2 before we start lying about how fast java is compared to the native code. When the hardware in question is capable of pulling 300 frames per second, it's pretty damn likely it's not even being used to its full potential. Even the K6-2 machine was getting near 60fps. The only people who got 60fps in Quake 2 when it came out were the people with monster machines.

Re:Wow, what a crock (1)

gatkinso (15975) | about 10 years ago | (#10205637)

Well, they were rounding up. ;-)

Yes, sorta (2, Informative)

daVinci1980 (73174) | about 10 years ago | (#10195884)

Are first generation Java games that far behind?


Sorta. There are numerous games out already that are based on Java. Pretty much all of Popcap [popcap.com] uses Java. Java is also used as a scripting language for several games (sorry, no links), as an alternative to Python, Lisp, C++, Lua or any other interpretive language (or home-brewed language).

However, it will be a very long time (if ever) before developers switch over to Java as their language of choice. Why? Because it is only the last generation or two of games that have started to use C++.

Game developers are constantly trying to push the edges of what can be done within current hardware limitations. The problem with languages that do a lot for us is that... They do a lot for us. Which is nice a lot of times. But always seems to happen at the most inconvenient time (like when we're doing matrix operations, or animating units).

Re:Yes, sorta (1, Interesting)

Anonymous Coward | about 10 years ago | (#10198580)

There are numerous games out already that are based on Java. Pretty much all of Popcap uses Java.

There are games and then there are games :) One should make difference between traditional rich games (sold in boxes at store shelves) and small games (browser games and mobile J2ME games). Popcap seem to be designing the latter. The amount of work for browser games is not comparable to rich games. Browser games are simple, taking maximum few months to develop. Rich games cost average 5 million dollars [dfcint.com] , have hunders of people working on them and development time is counted in years [3drealms.com] . As far as I know, no rich games use Java for their core, but Java has been used for scripting purposes in rich games.

Due to Java's nature to maximize portability, Java's means for native interface fine control (i.e. display drivers) is crippled. You need to make an extra complex DLL layer (JNI) between Java and an operating system. This is hinderous for core engine performance. The engine in the article used jogl as a layer and the engine page mentioned that they have reduced the number of native calls because of performance penalty. Also, Java's safe memory management model prevents making any "dirty tricks" to tweak performance. C# comes around this by having ability to have inline "unmanaged" C code directly in C# source.

Maybe in some point CPU speeds are so fast and systems are so mature that there is no more requirement for "low level work" in game programming. But not yet.

I'd rather have Starbucks (-1, Troll)

Anonymous Coward | about 10 years ago | (#10196262)

With two dozen Java programmers at my company, all working to port apps to Java over the last four years, our environment has become a hogdepodge of different JREs and JDKs from Sun and IBM, and it ain't the utopia that Sun has claimed. We need the different JRE/JDKs because required third-party code works, or works better, with specific versions.

I love the idea of Java, but dislike the execution. Keep the language but get rid of bytecode, inefficient zipping of JAR files, the CLASSPATH fiasco, and the silly idea of any cross-platform operation. Get a grip on JREs so I don't have to load two from Sun and one from IBM on a system to support four Java apps.

Maybe Microfsck had the right idea with their J++ product? Get the JRE to more tightly fit the OS instead of making a one-size-might-fit-you implementation.

Your equity is in the reusability of the code, not compatibility across platforms.

Vampire: the Masquerade (3, Interesting)

clamatius (78862) | about 10 years ago | (#10196372)

I happen to know of at least one AAA game which used Java - it used it as a scripting engine.

Nihilistic [nihilistic.com] 's Vampire: the Masquerade - Redemption [nihilistic.com] , back in 2000. As I recall, in the Gamasutra postmortem [gamasutra.com] , they commented on how well it worked out for them.

Sadly, I don't know what JVM they were using - but they did say in the postmortem that they didn't write it themselves.

Re:Vampire: the Masquerade (1)

GameNutz (556033) | about 10 years ago | (#10196433)

They used Sun's VM. The box actually carried the Java Powered logo :)

Re:Vampire: the Masquerade (1)

clamatius (78862) | about 10 years ago | (#10196478)

Interesting. Don't suppose you know what version it was, just out of curiosity?

Re:Vampire: the Masquerade (1)

GameNutz (556033) | about 10 years ago | (#10196581)

1.3. Full JRE shipped with the game. As well, games like IL2 Stormivik (sp) use Java for the same purpose.

Re:Vampire: the Masquerade (0)

Anonymous Coward | about 10 years ago | (#10199126)

Hmm, for some reason I thought they bundled a 1.1JVM in there, did some work on it a few years back while helping on a Mage Ascension conversion and I'm pretty sure it was 1.1

If Java is so portable... (0)

justin_saunders (99661) | about 10 years ago | (#10198202)

Why doesn't Jake2.0 support Mac OS?

The original c/c++ source compiles and runs on several platforms. THAT SOUNDS PRETTY PORTABLE TO ME.

So why are we using Java to write games?
Its not more portable as I've just pointed out.
Its slower.
And I'm a grown up, so I can *decide* if I want to use pointers, gotos, or multiple inhieritance.
If you don't like these features in C++ THEN DONT USE THEM.

A language is *not* better or easier if it leaves useful features out!

Re:If Java is so portable... (2, Insightful)

Decaff (42676) | about 10 years ago | (#10198995)

And I'm a grown up, so I can *decide* if I want to use pointers, gotos, or multiple inhieritance. If you don't like these features in C++ THEN DONT USE THEM.

We may be all grown-ups, but its a sad fact of IT development that we all make mistakes, and pointers aren't an optional extra in C++, they are fundamental to the way data is stored. The use of C/C++ has been a disaster in many areas of IT, leading to buffer overruns, buggy software and virus susceptibility. (I remember spending days trying to trace a buffer overrun in a C++ program on DOS).

Unless you are writing OS kernels, device drivers or hardware controllers its hard to see why anyone would feel the need to use raw memory pointers in an application.

Re:If Java is so portable... (1)

justin_saunders (99661) | about 10 years ago | (#10209645)

>Unless you are writing OS kernels, device drivers
>or hardware controllers its hard to see why
>anyone would feel the need to use raw memory
>pointers in an application.

Lets see, what have I done in the last few months programming games:
*Needed to get a raw memory pointer to PS2 framebuffer.
*Needed to align 16byte structures in memory from a non-aligned binary file.
*Optmised a matrix-math function to use GameCube paired singles FP instruction.

Games need to be optimised. No matter what all the Java-Fanboys in the world think - cutting edge games will always use pointers. We're programming at a level were we have to consider the cost of a *virtual* function call versus a regular one.

And guess what, our source code (C++) compiles and runs on XBOX/PC and PS2. And the browser I'm using to post this (Firefox) was written in C++, and runs on even more platforms...

Its a bad example anyway, rendering Quake2 on todays graphics hardware is virtually free. If you wanna impress me with how fast Java is, show me the Quake2 software renderer in Java, and compare *that* to the c++ version.

Re:If Java is so portable... (1)

Decaff (42676) | about 10 years ago | (#10210959)

If you wanna impress me with how fast Java is, show me the Quake2 software renderer in Java, and compare *that* to the c++ version

You mentioned doing direct access to a framebuffer. I would say that counts as 'hardware', so fits with my original post.

I can see how in your specialised area, C++ has real advantages. I was definitely not saying Java should be used everywhere. What I feel was disastrous was to use C++ for general application coding.

If you don't like Java, there are other languages which can provide safety and range-checking - Pascal for example - just as fast as C++, and the range checking can be turned off at runtime to improve speed.

As for portability, I think you are missing the point. The firefox browser does indeed run on lots of platforms, but its up to the firefox coders to ensure that, and also up to the coders to supply binaries for each of those platforms. That is a lot of work, especially for small IT companies (I know, been there, done that - had to support C++ code on different platforms with different graphics drivers). With Java (and other JIT systems) you supply one binary, and let the VM writers do the work. Your single shipped binary runs on platforms you haven't even heard about, providing there is a sun-certified JVM for that platform. I know this is not perfect in all cases, but it is still an important time saver. It certainly saves me time.

This may be irrelevant to you, but for 90% of all developers, its revolutionary.

Re:If Java is so portable... (1, Insightful)

Anonymous Coward | about 10 years ago | (#10199112)

Why doesn't Jake2.0 support Mac OS?
Why do you care what platforms they support . Once all the bugs are out of jogl/joal it will run fine on Mac OS

The original c/c++ source compiles and runs on several platforms. THAT SOUNDS PRETTY PORTABLE TO ME.
How many layers of dust covered the average q2 cd before the source was released?

So why are we using Java to write games?
We're writing games now?

Its not more portable as I've just pointed out.
Err sure. Btw: How well do win32 binaries run on MacOS these days?

Its slower.
Because the difference between 296 fps and 312 fps is essential to the proper enjoyment of any game.

And I'm a grown up, so I can *decide* if I want to use pointers, gotos, or multiple inhieritance.
Of course you are. And one day, when you've had a real job you'll discover what a pain in the arse those things are when your code doesn't do what you think it should.

If you don't like these features in C++ THEN DONT USE THEM.
Quite so. On the other hand c++ without pointers would be like a dog with no legs

A language is *not* better or easier if it leaves useful features out!
Absolutly true, but I thought you were arguing for c++.

Re:If Java is so portable... (1)

GameNutz (556033) | about 10 years ago | (#10200651)

It does. Please re-read these threads before posting.

Nothing new (2, Interesting)

mirabilos (219607) | about 10 years ago | (#10198881)

Tr3B (Robert Beckebans IIRC) has written a Q2 clone
in Python some time ago, and currently hacks on
qrazor-fx aka http://xreal.sf.net/ which is a Q2
with graphics quality in the range of Q3 or even
Doom 3.

First Generation Java Games (4, Informative)

jvsquare (757164) | about 10 years ago | (#10200105)

> Are first generation Java games that far behind?

The first commercial Java game was Tom Clancy's Politika, published in 1997. This was followed by Tom Clancy's Ruthless.com in 1998, and Shadow Watch in 1999. I'm not exactly sure what the comment above means, but personally I consider those games first generation. They were burnt onto CD and sold in stores like many a C or C++ title.

Whereas some C/C++ games have used Java as a scripting language, the approach of these games was to use Java for the core game loop and game logic, and to write new native libraries for the performance heavy stuff like graphics and sound. For Politika, we wrote our own movie and sound code (for both PC and Mac) because Java didn't have very good support at that point. We almost got some faster and leaner 2D graphics support in there too, but ran out of time. This approach was written up for a paper (Writing Java Games: How We Did It), which was presented at CGDC 1998.

In Ruthless.com, the native libraries were improved and the 2D graphics support was added. Basically a wrapper was created around DirectX using JNI. In addition, the whole game was compiled to native code instead of using the Java VM. This whole system hit its peak with Shadow Watch, which is an awesome little turn-based strategy game; think Rainbow Six Tactics.

So this has been possible for many years -- it's just that nobody's carried it on. The big accomplishment here is that they may be using only Sun libraries, which only means that Sun has finally gotten their act together and put out well-optimized code.

Benchmarks (0)

Anonymous Coward | about 10 years ago | (#10206927)

the benchmarks show, that the performance on Linux is not as good as on Windows. I wonder if this comes from the worser nvidia driver or because java performs not as good (is less optimized?) (compiler???) on linux.

Compiled code in the distribution (1)

cortana (588495) | about 10 years ago | (#10206967)

Can anyone explain what the shared libraries and dlls in the compiled distribution are for? Is the Quake 2 part of the code 100% java, and are the shared libs just wrappers around the OpenGL libraries, or what?

If so, why does there have to be a wrapper shared library created to interface with the opengl libraries?

Not all native Java code (1)

sl4shd0rk (755837) | about 10 years ago | (#10208801)

>Jake2 uses jogl for OpenGL graphics and joal for 3D
>sound. Currently supported operating systems are Linux
>and Windows2000/XP.

This isn't native swing and double buffered Jpanels ...erm...more like sticking a 302 in a Ford Pinto and still calling it a Pinto. Nonetheless, still an impressive port...props-n-hos to the Jake2 crew.

Chrome is a example. (0)

Anonymous Coward | about 10 years ago | (#10208890)

Chrome is a DirectX FPS (first person shooter) based game. The Graphical engine is written in C++, but all the game logic, networking, etc... has been coded in Java, with the objetive in mind to be recoded by mod makers (the code is also included in source form). The result, starting a level takes about 1:30 minutes in a 512 MB and 1,2Ghz machine (from the byte-code).

Everyone who uses NetBeans or even Eclipse can tell you how much slower are these IDEs than KDevelop or Visual Studio: a lot. I havent seen a large desktop java app running close to a native C/C++ app. And you?. It can be shown empirically.

About languages speed, the differences between two languages are only marked by the features they implement. C++ will be ever slower than C (under same conditions) and Java will be ever slower than C++ (again under same conditions). Can Java run faster under a JVM than C++?. Possibly. Can C++ run faster than java under a C++VM?. Sure.

Then, the question is: Can interpreted code run faster than native code?.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>