How is game development done in Java?

General Discussions
#1

Hi,
I’m not new to programming or game development, but I’ve never wrote a game in Java. So I was wondering how much are some of the techniques different from those in C++.

For example, let’s say I have a chessboard. When I click on a figure, something needs to know that figure is selected. In C++ I would have had a list of all the figures sorted by Y, and when the mouseclick occurs I iterate through the list and see if there is a figure underneith the mouse cursor.
In Java, I could just inherit a Component class and make itself draw on the screen, and when the mouseClick() event occurs the component will handle that event by itself. No need to iterate through a list.
Is this how this is done? Or is it more common to have a list?

Second question: GUI. In C++ I would take one of the GUI libraries or draw the buttons myself. I would have to implement what happens when the mouse is above a button, when the mouse is down, when it’s up, when it’s double-clicked etc. First I would check which button was selected by iterating through a list containing the buttons of course.
In Java I have Swing components that again handle the events for themselves. Is it better (faster in performance) to use Swing GUI classes than to draw my own sprites on the screen?

Third question: how are animations done? Do I need a separate thread for animations, or perhaps I can have an ImageManager that will contain all the images in itself, and during each frame it will iterate through all the images and check if it’s time for them to move to the next sprite?

Fourth question: I know Java is slower than C++, I can see that by just starting up the Java2D demos that came with the SDK. I also don’t intend to use OpenGL which I understand can be reached through Java classes. What I’d like to know is how significantly is it slower? Will a game that runs at 100 fps and is written in C++ run at 50 fps? I’m mostly concerned about the game being sluggish, like I move a tank to coordinate (x,y) and the tank will move, then stop, then move, then stop again… or will it go smooth? The same goes for screen scrolling.

And the final question: how significantly will the scripts reduce my game speed. I chose to use Pnuts cause I like its syntax and I’ve seen from a benchmark that it’s the 2nd fastest Java scripting language. However when I ran a test that wrote out random numbers, and then the 100th number would be queried from invoking a script, the program halted for a (very short) moment there. And this was just a script that calculated 2+2. When during gameplay I have to invoke massive scripts that control the AI all the time, will this degrade the gameplay to becoming unplayable?

Just to mention for the end this is not a provocation. I intend to make a game in Java and I need to know what I will be dealing with.

Waiting for your reply :wink:

#2

Disclaimer: all of the following is just my personal view…

Far far too many people fall into the common trap of trying to force java GUI classes into doing things that they shouldn’t be doing. Don’t even touch the Swing/AWT classes except for your initial window to draw in. Get yourself a nice blank Canvas (or Window) and do all the painting manually. Same goes for mouse events and buttons (even more so because the standard Swing look-and-feel sucks for a game).

[quote]Third question: how are animations done? Do I need a separate thread for animations, or perhaps I can have an ImageManager that will contain all the images in itself, and during each frame it will iterate through all the images and check if it’s time for them to move to the next sprite?
[/quote]
You’ll kill your performance with a single thread per animation, and thats before you’ve even hit all the multithreading bugs you’ve just introduced. Just stick to the single-threaded game loop with an update(), which can advance any animations as needed.

[quote]Fourth question: I know Java is slower than C++, I can see that by just starting up the Java2D demos that came with the SDK. I also don’t intend to use OpenGL which I understand can be reached through Java classes. What I’d like to know is how significantly is it slower?
[/quote]
For code speed you’re unlikely to notice a difference. The bit where Java falls down is drawing speed (which is one of the reasons for all those laggy Swing apps). Hence why lots of people are switching to OpenGL for extra speed and flexibility.

If you really want to stick with Java2D, check out the BufferStrategy class. Makes writing a standard game loop easy.

#3
  1. In a chess like game you can just calculate the cell. Say the board is 400x400 pixel and each cell is 40x40 pixel… all you need to do then is subtract the boad offset and divide it by the cell size… and voila… you have the cell.

Eg 400x400 board… offset is 100, 50… mousecoords are 372/429.

(372-100)/40=6.8 stored as int it’s 6
(429-50)/40=9.4… stored as int it’s 9

So… the user clicked on the field [6][9].

  1. You can use swing or draw your own buttons. Speedwise it should be pretty much the same (but your own buttons can be more convenient).

  2. You don’t need a sperate thread. Just store the frames and cycle through em. Which frame should be displayed could be determined by the object itself (eg sprite.tick() cares about that and sprite.draw() draws it).

  3. The speed depends on the version of the vm. Eg 1.0/1.1 is very slow. 1.2 and up has JIT. 1.4 and up has 2d acceleration. So, with a 1.4+ vm you can (if you do it right) get pretty much the same speed. Once you hit the fillrate limit it doesn’t matter anymore if the used language is some percent slower (because the cpu has to wait for the graphics card anyways).

  4. Microbenchmarks are dangerous. Heh. You wanted to get an idea how fast scripting would be… but what you have seen is that printing to the console is very slow. Talk about the news flash. :slight_smile:

Well, gernerally scripting should be used for high level things and not for inner loops. Eg the script can make decisions (eg some fuzzy logic for picking the behaviour to use), but things like path finding should be done on the java side (or C/C++ side… whatever). You can however prototype those “core” things with a scripting language. Doing so (usually) saves some time.

edit: One thing to note… if you use java2d you have to live with some restricitons if you want speed. Only bitmask transparency, only some (unfiltered) rotations, no antialiasing and images with <=2^16 pixels. The only way to get rid of those is using opengl.

#4

Thanks for the replies. So basically I should do everything like it’s done in C++, and shouldn’t relly on the GUI things. That’s kind of shame cause I really looked forward to such game programming, of course with the thought it would be faster (in game speed) :-/

oNyx: what do you mean images with <= 2^16 pixels? I can only use 16-bit bitmaps? Does that mean I cannot use an alpha channel? ???

#5

[quote]Thanks for the replies. So basically I should do everything like it’s done in C++, and shouldn’t relly on the GUI things. That’s kind of shame cause I really looked forward to such game programming, of course with the thought it would be faster (in game speed) :-/
[/quote]
No. If you want to write advanced games, and want fancy features that will need hardware acceleration, you should use OpenGL.

Otherwise, you should use Swing and J2D and you will be absolutely fine. Especially if you aren’t keen on using OGL. However, many people here are cautious about using OGL and think they mustnn’t use it in 2D, so we have to be very pro-OGL to build enough pressure that peopel use it where it would genuinely suit them better than doing it in a 2D library, and then belatedly re-writing all their code to use OGL in a few years time because they realise they should have done that in the first place :).

For you chess examples, there is no way you want to use OGL unless you enjoy wasting time or intend to use OGL for all the graphics anyway.

Eventually, probably 12 months from now, it will be fine to mix OGL and Swing widgets. For now, it’s sufficiently unstable, tricky, and painful (almost entirely due to bugs and issues in the libs that are known but no-one has quite got around to fixing or addressing, except in proof-of-concept demos) that you don’t want to do it. Unless you’re trying to show off. But again, you’ll be wasting time.

IMHO

#6

If you’re using Java2D and want a decent FPS, you’re going to have to limit yourself to single bit alpha and images less than 256x256 in dimension. (Quick, join the OpenGLites and throw off your chains of oppresion!).

#7

[quote]you’re going to have to limit yourself to single bit alpha
[/quote]
That’s the single most common “advanced” feature that you might want in j2d and lack ;D. But there are plenty of games where you don’t want more than bit alpha (not for OT, I know he knows this).

Personally, I usually want > 8bit alpha, but I know many others who get away fine without it.

#8

[quote][…]
oNyx: what do you mean images with <= 2^16 pixels? I can only use 16-bit bitmaps? Does that mean I cannot use an alpha channel? ???
[/quote]
“<=” mean less or equal and ‘^’ is usually used as “power”.

So less or equal to 65536 pixels. A square texture with that many pixels would be 256x256. A rectangular texture could be 512x128.

The image should be “compatible”, which means that it needs to be converted to whatever the current bid-depth is. Usually that’s 24bit.

And alpha… as I said… bitmasked, which is a 1bit alpha “channel” (usually 8bit indexed [true color palette] where one of the colors is flagged as transparent - it’s basically color key transparency). Using a full (8bit) alpha channel is slow unless you use the transaccel flag, but that only works on windows and even there you can’t really rely on it.

#9

That’s interesting, cause just a few seconds ago I managed to display this 512x384 image in a Java application without any problems. The picture is 24 BPP, and 512x384 = 196.608 > 65.536 :stuck_out_tongue:

http://upl.silentwhisper.net/uplfolders/upload3/pic_bigger_than_said.gif

#10

You can display large images, but they will not be accellerated.

#11

Oh… now that I’ve read through the thread again I understood… :frowning:
Is learning the 2D part of OpenGL hard? Or let me put it this way: my game will have graphics quality somewhat above Civ2. I will have hex tiles, while the units will be rendered in 3D Studio max and they’ll be converted to some image format that Java understands. There will be sounds, and the animations will be “nice” but not too extravagant. Do I really need acceleration then?

Though the tiles will be somewhat bigger than 50x50 so it still falls into the required limit. I’m just sorry about the splash screen and perhaps a couple of larger images that won’t be shown much in any case…

So, if I have a map that is made out of many small tiles, acceleration will be on. If I open a window above that map which displays “Something has happened” and a 300x300 picture is shown next to it, then the game won’t be accelerated while that image is showing. As soon as the window is closed 2D acceleration will get back on. Is this correct?

Cause if yes then I can handle it, as it will be a TBS and the only things moving around without the players consent will be the animations ;D

#12

That image alone won’t be accelerated. I don’t know how java2d does that switching around exactly…

Well, you can still just break that image up into two images and the problem is gone, but you can’t use BufferedImage’s subimage() method, because it still refs the same pixel data… you need to do a “copy” by creating a new image and drawing that part into it.

Is learning the 2D part of OpenGL hard?

Not really. The basic stuff is pretty simple, but somewhat long winded. Once you abstracted those bits it’s pretty much like… say… java2d.

#13

OpenGL is 3D language. You could look at 3D scene in a way it would look like 3D scene. Of course you must set the view point to the right distance and projection to parallel. And then you’d encounter that nasty but ugly problem that OpenGL doesn’t have point 0.0 at upper left corner of the screen, as is tradition, but much more math like in the middle of screen and b axis should be rotated on top of that. After you would do all rotation and matrix configuration, you could do all work with comfort of common blitting. Of course don’t forget on rendering hints and glitches.

BTW one of my testing programs used 800x600 and larger pixel images, and worked at nice xx FPS on NVIDIA TNT2. I had just problem with sending 10 images into just 32 MB of RAM, so this why just 800x600, but it worked cleanly and fast. I might look if I’d find this program somewhere so you’d be able to look at.

Other of my programs used on that NVIDIA TNT2 somewhat around 700 subimages, again without problem until I did alpha blending (full quality of course. That card had some problem with this even when used OpenGL not to mention Java 4.2)

I very doubt that Civilization 3 like game would have significant problem with that. Of course you can do dirty rectangles and slap everything else in accelerated mode.