Isometric Engine

Java 2D
#1

Sorry if this has been asked before, but searching around I can’t find anything…

I’m thinking about writing an isometric tile engine, but during a few experiements I’m having trouble grasping how I’m going get the performance out of Java.

To cope with object occluding players as they walk around the map I think I need to re-render the viewable tiles every frame? Is this the wrong approach?

Has anyone got something of this nature working and could give me a few pointers (or links to web sites)?

Any help much appreciated,

Kev

#2

I’m not really a graphics guru but here’s a suggestion to prevent refreshing all visible tiles for occlusion. If you attribute each tile with a height value (could be as simple as 1 or 0) then you check the surrounding tiles of the player (i.e. the ones lower then them on screen) and if they have the height set then you redraw otherwise you know the player isn’t occluded.

I don’t know if this would be useful or not but it seems like you trade redrawing everything for about 3 ifs (and of course some memory accesses :))

#3

Depending on your game, a standard method of dirty rects and keeping a prebuilt background from your tiles on which you place sprites would probably work fine.

A note on performance: last year with CatAttack, we had an entire screenfull of 32x32 tiles (so approx 20x15), each which was built of multiple actual tile images (base + detail + shadow, often more than one detail for worst case). Add on top of this about 50 sprites and another ten or so for the HUD. All running without problems at 75fps on my machine. On a rather crappy uni lab machine (some obscure graphics card, must have had 8mb ram at most) we got an acceptable ~30fps.

The screen was rebuilt from scratch every frame. The two most important things to remember would be to use ‘automatic images’ and to get some accurate view clipping.

#4

Guys, thanks alot to start, great to get useful responses!!!

Just using the 1 or 0 (present or not) case for tiles isn’t quite as expandable as I need. What if a tile only occludes part of the player, I need to redraw that tile, but that in turn might draw over another tile… and so on, and so on down the map… Maybe I didn’t give enough detail, but tiles might have tall objects on them, which means a tile that is 2 steps away would occlude player.

I’m using 64x64 tiles, and trying to fill a screen of 800x600. I’m not actually drawing any players yet and only one level of sprite for each tile. At the moment, I get around 4fps :-/ (while drawing all the tiles everytime, well with the addition of clipping)

The dirty rect thing might work for me, could you elaborate on how it works… If I just redraw the rectangle the isometric player is standing on, won’t I redraw over the player with the floor?

Finally, , I understand about the view clipping, but could you let me know what “automatic images” are?

Thanks against for the useful responses, its got me thinking again :slight_smile:

Kev

#5

[quote]What if a tile only occludes part of the player, I need to redraw that tile, but that in turn might draw over another tile… and so on, and so on down the map…
[/quote]
The usual method is to use a clip rectangle when updating your region.

After a quick search, i found that this site still has all its content still hanging around, even if its not actually directly linked. Enjoy: http://www.java-gaming.org/Documents/Understanding_AWT_Image_Types/understanding_awt_image_types.html :smiley: I found the numerous articles on gameDev.net were useful as well http://www.gamedev.net/reference/list.asp?categoryid=44

#6

I always wondered about those clip areas.

  • If you try to draw an image that does not intersect the area does Java do an intersect calc for you then drop it. So it doesnt take much time.

  • When you draw an image that partially intersects does java spend the same amount of time with it as if the entire image intersected. ( If 1/10 th of the image intersected would it be 10 times faster)

#7

ok, ok, Orangy Tang, you are now officially my god!

Automatic Images, give me ridiculus speed :slight_smile: Shame being I’ve worked out for my particular game I don’t need it. Still, awesome!

Kev

#8

For anyone who needs a comparison in the future…

I’m now filling a 800x600 screen with 64x64 tiles. Which works out to quite a lot of tiles :slight_smile:

I use a back buffer and only update every 50 ms (at this point, its just scrolling across a repeating map)

On my 2.6Ghz laptop, ATI 64Mb graphics, 512 MB I get around 250 fps.

On my 1Ghz desktop machine, with 4Mb Intel onboard graphics and 256 MB I get around 14 fps.

As it happens, I’m never going to display this sort of number of tiles… but I’m still impressed at the speed you can get out of Java (with the proper advised tailoring)

Kev

#9

On my 1Ghz desktop machine, with 4Mb Intel onboard
graphics and 256 MB I get around 14 fps.

I assume that’s supposed to read “256 MB I get around 140 fps”?

BTW, has anyone noticed that 1.4.2 is significantly faster than 1.4.1? Under the later, my Shooter example for GAGE was just barely able to make 60 FPS with all the graphics being drawn. Now it runs within barely a few milliseconds per frame!

#10

Nope, on the 4MB graphics card it runs at 14fps.

Kev

#11

Most likely your getting only 14fps because your exceeding the 4mb with your tiles and therefore not all of your images can be accelerated.

This is the one limitation I’ve found in java. I can get tremendous speed using accelerated images but on systems with limited video card memory you will take a huge hit in performace.

Its my understanding that the only way to shrink up your images is to direct3d’s texture mapping algorithms (turning on a java vm setting) and a color model that imports your images as 16bits. Only problem is that these images are not accelerated and though Sun engineers claim they have enhanced rendering efficiencies with these textured mapped images they are still horribly slow.

Find a fix for this and I have no problems with using Java for any 2d Game application.