Reasons why Java is not a good language for game development

General Discussions
#41

I want it that much but no longer have the time to altruistically devote to helping others :frowning: I could easily increase my sales a hefty amount if I got a DX version of my sprite engine working.

  • Applets I would say are crap now but in about 2-3 years, provided update 10 fixes the problems and Apple get it released pronto, it should have sorted this issue. I have to say I have noticed since Flash 10 got released all my browsers crash or freeze at 100% CPU nowadays so Adobe looks to have screwed it up. Er, yay!

  • JRE size: well, should be fixed by kernel thing yes?

  • Native libraries: problematic because of security dialog, also because they’re OpenGL only and we really need a DX binding for people writing proper middleware

  • NO CONSOLE SUPPORT. AT ALL.

Cas :slight_smile:

#42

Also under the populair ubuntu distro flash seems to die randomly after a while, producing just a grey rectangle.

#43

No one cares about Linux desktops :slight_smile:

TBH I wonder why Sun don’t shift all those Linux desktop Java engineers on to the Apple side and make a proper Sun Mac OS JVM.

Cas :slight_smile:

#44

Oem’s ship more and more linux boxes, think eee laptops for example. While in the corporate space things remain the same, I see stuff picking up in the home/consumer space. Among students, youngsters and mom’s that only do e-mail and some browsing I see it picking up. though I don’t foresee an actual market within a year. After that it depends on if matter keep moving towards that direction. At this time there is some momentum.

I care about linux desktops but that isn’t really gaming related. :-*

#45

They’re probably all beardy linux hippies who would leave as soon as Sun tried that. :wink:

#46

Preemptive to gouessej:

It’s ok, they’re just joking.

#47

Okay, my two cents :

  • Timing. Neither sleep() or nanoTime() work well, mainly because of hardware/OS issues. (already mentioned)
  • Java Sound. This is the buggiest library I have ever used, ever.

I don’t think JRE size matters anymore. Most folks have Java 6 at this point. The kernel helps, plus it’s got auto-update and patch-in-place. Even without the kernel, 15MB isn’t as big a deal today as it was 10 years ago.

That said, I wouldn’t recommend to anyone to make game Applets from scratch. Use an existing library or framework that has dealt with stuff like timing problems.

#48

He says as his signature links to PulpCore… :stuck_out_tongue:

#49

So in summary, is it fair to say that Java is bad choice for game development if you do not include native libs?

I think the answer to the question is fairly obvious really. I don’t mind using native libraries from within Java, but using them increases the likelihod that my game will fail to start up on another machine. For example, neither LWJGL nor JOGL will work on this Windows Vista laptop that I’m using despite the fact that it is a reasonably well specc’d machine. LWJGL complains about an unsupported pixel format (video card trouble) and JOGL regularly crashes the JRE, though software emulation works just fine but is far too slow for games work. I can’t play Puppy Games’ games because they won’t start up on my machine. The failure to start problem is just eating away at your profits Cas. A DirectX version in C++ would have run just fine. A shame really 'cos I really like playing shoot-em up games --they help me to concentrate.

As for writing games in pure Java, I’ve given up! There are timing problems and screen update problems that I just don’t get if I use C and a really simple hardware layer interface library like SDL. Additionally, there is something deeply suspicious about the inner-workings of System.nanotime() and the lag and stutter in the main game loop is causing me so many headaches. Again, as Kev suggested, it is probably a hardware problem but I no longer care about Java’s hardware interface problems. My lack of care in this respect is prompted in part by the suspiciously low coupling of Java to hardware.

Anyway, back to the point. If I can’t do something really, really basic like time the appearance of game objects and move them smoothly around on screen (even at low frame rates on really bad hardware) then I don’t really want to know what else Java can do. Hell, even Blitz Basic and Dark Basic will give me a smooth, consistent main loop on a crappy 500Mhz Pentium, why won’t Java? Christ, even Flash will give me a steady frame rate and Flash is the suckiest of the suckiest arse-over-tit, extra-ecma-anal game programming environments. On this machine, I only get a stable frame rate for my test code in Java if I drop the frame rate to ten frames per seconds, which is unusable except for the simplest of puzzle games.

It is not enough to say, well there’s something wrong with the way you’re doing your screen updates in the test code (as Dzzd said) and you need code to stabalize the frame rate. That’s just a load of bollocks Dzzd. There’s nothing wrong with the code: time the game objects update & drawing operations and then sleep for a period of time to sync the loop at sixty frames per second, or whatever frame rate you can get away with. It doesn’t get much simpler than that. Coding a game loop is trivial, yet Java just doesn’t seem to be able to handle the timing and synchronisation requirements and produces inexplicable stutters and lags in the main loop. Let’s face it, stutter and lag are just anathema to a games writer. Its the kind of thing that furrows your brow when you’re falling off to sleep and it is annoying because the problem subtracts thinking time from designing and implementing the game play and game mechanic. Incidentally, when I ported the test code across to C and SDL, I got a rock steady frame rate. As expected, with none of the stupid bollocky timing artifacts that Java seems to throw in to the mix.

The other thing that is bothering me, which cas has touched upon, is that there is no console support in Java. If I write a game for the PC and it does reasonably well then the obvious thing to do would be to use the profits generated from the PC version to purchase a console development kit and port the game across. If I’ve already written the game in C then porting becomes trivial, if it is written in Java with native lib dependencies then porting is not so easy and straight-forward. In fact, it is probably near enough a complete rewrite.

IMO Java fails as a choice for game writing at the most basic level: the game’s update/render loop. This is unpardonable for a runtime that wants to make it in the game writing arena. If the timing in your game is off then the players will notice and stop playing the game and they certainly won’t buy a game that stutters and lags. I’m a little annoyed not to mention peeved at the amount of time (wasted in my opinion) I have spent writing and debugging code on a platform that just doesn’t perform well enough and no amount of tinkering will coax the JRE, or the graphics libraries or the timer or whatever the Hell the problem is with Java’s jerky screen updates into giving me a stable main loop on top of which I can build a playable game.

I’ll continue to hang around the forum to see if things improve, but TBH I think that Java’s games writing problems are fundamental and located within the JRE and the native interface code. Aargh, all those bloody layers just to get at the hardware! I’m sorry, but I think you are completely wrong to spend your time writing games in Java. C/C++ is a much better choice. Using Java for games writing just brings to mind a modern curse: may your games stutter and lag for all eternity.

I’ll stick around the forum to view the games showcase releases (I do like seeing those) and just generally monitor the Java performance related posts but as for using Java to write a commercial game, I think I’d rather eat a pooh sandwhich and wash it down with an extra large cup of vommit. ;D Heh, not that I’m in the habit of consuming such eye wateringly disgusting repasts. My experiences with Java game programming have given me a bloody twitch. Right, where the Hell’s my C compiler? Sanity extends an elegant, manicured finger and beckons with a sultry call “this way young Jedi, this way…”.

Jesus, you know what? I’m actually beginning to believe that I’ll need a theraputic course in advanced cognitive neronal repair after my experiences with that JRE and class library. I feel that my experience of writing games in Java has just caused the window of opportunity to slam down on my fingernails, throwing me breathless to the floor. And there I lied, helpless, as I watched the Sun Necrosystems vultures descend from the sky to pick at my loathsome bones…

–Mario

#50

So… let me get this straight. If you would have gotten the animation part smooth, it’d be all fine?

I mean… if you can play PulpCore games (for instance) without hickups (can you?), then that means there is a solution.

It is certainly very bad that it doesn’t work out of the box for you, but if a quick copy/paste from PulpCore fixes it, it will be well worth staying with Java IMHO, due to the superiour API, IDEs and other tools.

#51

OOI, what exactly have you been doing with Java to give you such a bad impression? Even the most closed minded of Java haters can normally see the benefits even if in many cases they seem out weighed by the problems.

Kev

#52

@Riven: Yeah, you’ve hit the nail on the head. My only raison d’etre for using Java is the gorgeous IDEs and other build tools (like Ant) that are available. Plus the Javadoc popup thing in the editor makes coding to libraries a breeze. But, if I can’t get a stable frame rate because the platform timer sucks then no way am I going to use Java.

BTW Pulpcore is excellent David, but the applets are jerky. It is such a shame 'cos Pulpcore has got a beautiful timing and animation framework. I wrote a quick 2D shooter using Pulpcore and it was just dead easy to do, but I stopped writing when I noticed the jerky screen updates becase I thought that nobody will play a game for more than ten seconds if it is lagging and jerking around on screen. In fact, I think players will actually start to hate you for publishing a jerky game. Jerky games are my number one biggest turn off.

I have no idea whether the problem is due to the Java system’s timer, or the graphics libraries. I just know that I can’t use it to write games 'cos the stutter & lag offends my sensibilities as a programmer first and as an avid games player second.

–Mario

#53

@Kev: I’m not a Java hater. It is impossible to hate a language which is obviously so beautifully engineered. At heart I’m a C programmer and I use Java because I think it has a great class library, blindingly good tools and a knockout windowing kit all built-in to one package. Also, server-side Java goes like sh*t off a shovel. The speed of Java isn’t an issue for me, it is the reliability of the programming APIs. I don’t know about you, but for me timing bugs are a source of major headaches and Java’s timing (I’m basing this upon what David Brackeen and Dzzd has said) isn’t up to the job for games writing.

I would like to be able to write games in Java because it gives me one-click deployment off a web page but I’m forced back into C simply because Java has got the fundamentals wrong. In gaming, timing is everything.

–Mario

#54

[quote]It is not enough to say, well there’s something wrong with the way you’re doing your screen updates in the test code (as Dzzd said) and you need code to stabalize the frame rate. That’s just a load of bollocks Dzzd. There’s nothing wrong with the code: time the game objects update & drawing operations and then sleep for a period of time to sync the loop at sixty frames per second, or whatever frame rate you can get away with. It doesn’t get much simpler than that. Coding a game loop is trivial, yet Java just doesn’t seem to be
[/quote]
yup, this is trivial… that’s the problem

I dont look very close to your code but I saw a cupple of things that make me think some things was wrong :

  • the " while…; " that lock cpu and that should never exist even in C/C++ or even Basic …
  • there is too much call to system.nanotime , something is wrong : lot of call to a timer are unecessary, usually only one call is enough
  • I think IMHO, that even if it is not completly crappy, computing the delay to wait the way you do it, is a wrong way and you have to found why yourself Luke “May the Force be with you”

on another hand I agree with the fact that farcry3 will not use Java… arf too bad…, but you can produce severals other kind of games using Java, but Java requiere to think Java… trying to program Java while thinking C/C++ can make you become crazy… hum…or vice versa

EDIT: how can you see all that jirky I have an old computer an pulpcore works great ?

#55

@Dzzd: Okay, there’s a strong possibility that I have hardware that Java just doesn’t like very much. But, the problem is that I can write a rock-solid game using C & SDL and the timing will be 100% accurate. This code works just great on my machine so I don’t think my hardware can be all that bad, I’m more inclined to think that the problem lies with Java not me. True, I should not have locked up the CPU in the while loop but I fixed that and it made no difference.

I’m just totally bemused by the way the Java code behaves, it seems to have a mind of its own and that makes me feel nervous and unsafe when I’m writing code on top of code that makes things move around unpredictably over time. All I can think about is that if the Java code is doing this to me then chances are it is going to do the same to a lot of other people too. What it boils down to is that if I use C I get no timing problems, but if I use Java I get timing problems.

–Mario

#56

@mgianota

I got the render loop thing licked years ago. LWJGL provides a proper timer that works pretty flawlessly on any hardware (it’s the same one Windows Media Player uses, the Windows Multimedia timer) and half of the time I get vsync anyway. In fact pretty much LWJGL is the only way to go if you want to write games in Java :smiley: That’s why it exists.

You could try updating your video drivers to try out my games - that’s usually the only problem with Vista* - the OEM drivers are often broken. But having said that I’d really love someone to get cracking on the DirectX wrapper for LWJGL then at least we’d be able to use it.

Cas :slight_smile:

  • or you might have just been unlucky and tried to grab 'em the other day when I broke them and had to upload them about 4 times.
#57

FYI this is the game loop I’ve been using for the last 5 years or so: (it’s of the fixed-at-60hz-variety, no time deltas or anything clever)


	/**
	 * Run the game.
	 */
	private void run() {
		while (!finished) {
			// Always call Window.update(), all the time
			Display.update();
			if (Display.isCloseRequested()) {
				// Check for O/S close requests
				exit();
			} else if (Display.isActive() || alwaysRun) {
				// The window is in the foreground, so we should play the game
				try {
					Resources.manage();
				} catch (Exception e) {
					e.printStackTrace(System.err);
				}
				tick();
				render();
				Display.sync(getFrameRate());
			} else {
				// The window is not in the foreground, so we can allow other stuff to run and
				// infrequently update
				try {
					Thread.sleep(100);
				} catch (InterruptedException e) {
				}
				try {
					Resources.manage();
				} catch (Exception e) {
					e.printStackTrace(System.err);
				}
				if (Display.isVisible() || Display.isDirty()) {
					// Only bother rendering if the window is visible or dirty
					render();
				}
				Display.sync(getFrameRate());
			}
		}
	}

Cas :slight_smile:

#58

yes, also with 1000 iterations… ???

#59

mgianota, I think you’re just victim of some bad combination of PC components, OS version, driver versions, etc. Your observations are really unusual and not normal for most of people. I understand your anger… but please calm down a little and try some constructive approach. As I mentioned, PC are assembled from many different components, and there are many versions of OSs and drivers, etc. so it sometimes happens that things go very wrong. And this is general, nothing Java specific. It’s also normal that it affect specific programs such as JRE. For example, many users blamed KDE4 for slowness, when in fact some version of nVidia drivers caused that… it’s not easy to distinguish the root of problem. Or some users have problem with specific antivirus programs making some apps totally unusable… and the app and it’s author is unrightly blamed… and so on.

So… we should analyze what is wrong step by step and fix that. LWJGL and others projects are open source and welcome bug reports of such bad behaviour, like wrong pixel formats. Try to gather more information, stack traces, what apps works and what not, etc. and cooperate with LWJGL folks. BTW, in typical LWJGL applications there is most of calls done just by LWJGL to native layer without any JRE interfering. GC is not generally problem, I’ve found it’s very rarely the problem, GC can do very good actually. Most of time GC is unrightly blamed first, most likely the problem is somewhere else. Also remember that nanoTime is bad on Windows platform, because QPC timer is really that bad (and native programs have different sort of workarounds for it). Try using LWJGL’s Timer it should be better I think.

EDIT: better wording about GC

#60

Weirdly enough running his draw-a-block-and-move it is jerky here too.

If I implement a old school simplistic self coded double buffered approach, it’s smooth. (image still jerks a bit, what double buffing was suppose to fix.) Then again under linux I have quite some paint issues progress bars don’t draw too well either out of the box.

Back in de day when 1.4 was new and crisp I remember writing horrible code - I mean freaky horrible - and we still had smooth crisp images bouncing on our screen making up a fancy game menu in an applet. (Which seemed to work everywhere)