Graphics in tile based games (in but not only in Java)

Easy - just draw the background for the entire map, THEN draw the buildings for each tile. My current project has multiple levels. I first draw the terrain, then any rivers, then roads, then cities, then units. You do have to make multiple passes this way, but it is easy and straightforward and I wouldn't bother with more complex methods unless you find that the speed is not acceptable. Alternatively, you could still keep it in a single loop if you drew to an off screen image and then merged the two images, but I haven't really looked into that.

So you draw each layer separated (eg terrain, objects, buildings). Do you split up the complete grafics into one grafics per tile? I guess yes.

Otherwise "larger" objects (than one tile) would still be overdrawn by objects from the next layer?

If you want I can show you the problem directly in the game. I could send you the link per PM (its a browser game).

thanks for the help


Woron

Yeah - no problem. Here are some screenshots of my game

http://mason.gmu.edu/~praphael/game.JPG
http://mason.gmu.edu/~praphael/scenarioeditor2.JPG

Actually, if you look closely in the above screenshot you can see that the game still contains that error (unit names get overwritten if they take up more than one tile). I haven't got quite around to fixing it yet, as I found other area os the game alot more pressing (like range finding :-) And yes, all my info is stored on one tile.

you additionaly could add the x and y positions of your objects to determine which is more in the background.
so you have a loop for every layer (objects, chars, etc) like this:

for i:= 0 to max_tile_x+ max_tile_y do begin
for j:= 0 to length(objects)- 1 do begin
if object[j].tile_x+ object[j].tile_y= i then begin
object[j].draw;
end;
end;
end;

well it would look like this if you programmed delphi :-)
the 'object' is an array of things like e.g. objects or characters.

it's not the fastest way to implement this but you can use one graphic per object and don't have to split it up...

hope this helps a bit!

edit: perhaps the first loop has to be the other way round, depends on your coordinate system!

Or implement your isometric engine using a 3D API, leverage the depth-buffer to do proper object depth, and don't worry about the eccentricities of object drawing and overlap in old-and-busted traditional 2D drawing techniques.

Quote:

Original post by JTippetts Or implement your isometric engine using a 3D API, leverage the depth-buffer to do proper object depth, and don't worry about the eccentricities of object drawing and overlap in old-and-busted traditional 2D drawing techniques.

Why would he want that complexity? Its much simpler just to do multiple passes.

Actually, no. Using a 3D API vastly simplifies the problem. Traditional 2D isometric methods are rife with overlap problems and quirks. I know, I've been programming them for close to 16 years now. It's amazing how they simply disappear merely by making the faces of each cell polygons in 3D space. No complexity that any half-way skilled programmer could not easily handle.

Quote:

Original post by JTippetts Actually, no. Using a 3D API vastly simplifies the problem. Traditional 2D isometric methods are rife with overlap problems and quirks. I know, I've been programming them for close to 16 years now. It's amazing how they simply disappear merely by making the faces of each cell polygons in 3D space. No complexity that any half-way skilled programmer could not easily handle.

If you are doing something where you view the map at angle and do what it to look 3D, then yes. But if you are doing a simple top-down view, 3D is uncessary. I don't know exactly how complex his problem is, but it sounds like multiple passes is a very easy and quick solution.

Going 3D isn't just about the programming. You have to generate the geometry and UV map things correctly - and that can add up to alot of work. If work for a game company and have artists who do this, then great. But if you are just something simple and non-commercial, I don't see how you benefit. There were lots of games before the 3D explosion that looked great without resorting to 3D. Look at Civilization II - they didn't need to use 3D and it looked pretty darn good to me.

Look, I don't want to turn this into a big argument, but just search the endless back posts in this forum for an idea exactly how problematic overlap issues can be. This question crops up in a dozen different variants every couple weeks, going back to the dark ages of the old dictionary/gdnet splash page.

Is it a solved problem? Yes. Are most of the solutions icky? Yup. Is 3D an elegant and extremely simple solution to overcome the ickiness? You betcha. Should people try to program for modern APIs and hardware, instead of stubbornly sticking to old methods that are slowly being rendered obsolete? Most definitely. As someone who has programmed countless engines-- top down, isometric, weird-angle pseudo-isometric, 3D isometric, fully 3D, you name it--I highly recommend dumping the old 2D techniques. The so-called complexity of 3D that you speak of is a myth; with a well designed engine, the switch to 3D is trivial; it took all of about a day and a half to switch my old Golem engine to one that functioned identically, but which mapped the wall graphics to quads existing in 3D space rather than screen-aligned rectangles as a 2D approach does--and that engine was far from well-designed. All sorts of overlap issues caused by drawing isometric rows back to front, overlapping with oddly shaped and large objects, vanished like magic.

Note that just because I recommend using 3D APIs to solve problems doesn't necessarily mean I am advocating full-blown 3D with polygonal characters, etc... You can still use pre-rendered sprites and all the goodies. Just use some 3D tricks to circumvent some rather nasty and limiting problems.

I stand firm in my assertion that most of the old approaches should be abandoned, at least for the PC or any 3D-enabled hardware. I have yet to hear of a valid reason for sticking with the old methods, yet can think of dozens of reasons not to.

OK, I guess I misunderstood your post then. You weren't advocating full 3D but just using it to map the images onto polygons to benefit from the z-buffer. Then thats not too hard. He is programming in Java though, and I've never worked with Java3D but its been around for a while now so should be pretty mature.

Quote:

Original post by SunDog OK, I guess I misunderstood your post then. You weren't advocating full 3D but just using it to map the images onto polygons to benefit from the z-buffer. Then thats not too hard. He is programming in Java though, and I've never worked with Java3D but its been around for a while now so should be pretty mature.

Java3D is not well suited for this kind of work - since it's a scene graph it hides a lot of useful functionality (such as depth buffer setup) and doesn't like you playing with individual polys. And thats before you've even hit the reliability and distribution problems...

Instead you probably want to use OpenGL directly, through something like LWJGL.

Quote:

Original post by JTippetts Note that just because I recommend using 3D APIs to solve problems doesn't necessarily mean I am advocating full-blown 3D with polygonal characters, etc... You can still use pre-rendered sprites and all the goodies. Just use some 3D tricks to circumvent some rather nasty and limiting problems.

But if your sprites are blended, don't you have to sort them anyway? Or do you do a best effort sort and let the z-buffer take care of the awkward edge cases?

Quote:

Original post by OrangyTang Quote: Original post by JTippetts Note that just because I recommend using 3D APIs to solve problems doesn't necessarily mean I am advocating full-blown 3D with polygonal characters, etc... You can still use pre-rendered sprites and all the goodies. Just use some 3D tricks to circumvent some rather nasty and limiting problems. But if your sprites are blended, don't you have to sort them anyway? Or do you do a best effort sort and let the z-buffer take care of the awkward edge cases?

Well I think what he's getting at is that you could define a flat rectangular polygon that you would texture map your image onto. If you are doing the standard diamond shape tiles I imagine the polygon would run along the diagonal of the square, or rather horizontally along the diamond, and would be as tall as you need it to be. In this case I don't think you have to depth sort the polys. They are mostly sorted anyhow if you iterate through the tiles in the correct manner - that is assuming the camera is at a fixed 45 degree angle with respect to the rotational plane of the map that (if you are familiar with airplanes - the 'yaw'). The 3D approach with z-buffering just fixes the odd quirk where you have overlapping regions.

Wow, never thought that isometric is THAT complex :)

Maybe I change the code to 3D. First I will have to check how "handy" it is for the user. Because our game is browser based it would be inconvinient for forcing the player to intall Java3D on his PC first, for example when he wants to play it at an internet cafe where he has no rights.

May this works with LWJGL or JOGL better, we will see in summer :) (not only because we have our introduction to OpenGL course this semester).


Thank you all for your help.
For the next time no one should say that Isometric land changed into isometric dessert :)

yours

Woron

Try this loop order. Note that this only applies for a square grid. Also, I haven't tested it :-)

i=0; j=0;for(n=0; n<2*max; n++) {  drawTile(i,j)   if(j==0) {      i = 0;      j++;   }   else if(i == max) {      i = j;      j = max;     }   else {      i++;      j--;    }}

Also, I see a basic problem in that if you draw buildings that occupy multiple tiles, if you try to draw a big building that is closer to the user, part of the building is actually farther away from the user. So if you loop in the above order, you will might overwrite some building that has already been draw that is close to the building you are drawing. For instance lets say you have a building a which is only 1x1 and a building b which is 5x5:

(furthest away from user's perspective)    b    b b b  b b b b b  <- this is rendered *after* a, overwrting it   b b b a <- a should be visible to the user    b <----  you draw b in its entirety at this time(closest to user's perspective)

Building 'a' may be overwritten, even though it should be totally visible by the user. Since you are drawing all of b at the lowest tile. So what I would suggest, if you don't want to go the 3D route, is to break up the drawing of b into differnt tils. This can be done in code by breaking up the image, and should be transparent to the artiest.

Quote:

Original post by JTippetts Look, I don't want to turn this into a big argument, but just search the endless back posts in this forum for an idea exactly how problematic overlap issues can be. This question crops up in a dozen different variants every couple weeks, going back to the dark ages of the old dictionary/gdnet splash page. Is it a solved problem? Yes. Are most of the solutions icky? Yup. Is 3D an elegant and extremely simple solution to overcome the ickiness? You betcha. Should people try to program for modern APIs and hardware, instead of stubbornly sticking to old methods that are slowly being rendered obsolete? Most definitely. As someone who has programmed countless engines-- top down, isometric, weird-angle pseudo-isometric, 3D isometric, fully 3D, you name it--I highly recommend dumping the old 2D techniques. The so-called complexity of 3D that you speak of is a myth; with a well designed engine, the switch to 3D is trivial; it took all of about a day and a half to switch my old Golem engine to one that functioned identically, but which mapped the wall graphics to quads existing in 3D space rather than screen-aligned rectangles as a 2D approach does--and that engine was far from well-designed. All sorts of overlap issues caused by drawing isometric rows back to front, overlapping with oddly shaped and large objects, vanished like magic. Note that just because I recommend using 3D APIs to solve problems doesn't necessarily mean I am advocating full-blown 3D with polygonal characters, etc... You can still use pre-rendered sprites and all the goodies. Just use some 3D tricks to circumvent some rather nasty and limiting problems. I stand firm in my assertion that most of the old approaches should be abandoned, at least for the PC or any 3D-enabled hardware. I have yet to hear of a valid reason for sticking with the old methods, yet can think of dozens of reasons not to.

JTippetts, a followon question if I may - your suggestion to go to a 3D API to
simplify graphics rendering issues in a tile based game is intriguing. As I am
just getting started with the graphics portion of my TBS game, is there a particular open source (or $100 one seat license) 3D Graphics engine that you
would recommend using to get started? I'm developing in Java. Thanks for your
thoughts.

@SunDog: Thanks for all

We will split up the graphics, not only because we can't/don't want to use 3D, I also think (it is still a fun project allthough we hope we can make it public one time) I should have had all that troubles one time to be able to explain my boss (when I got in professional buissnes) why to use 3D :)

@jlevans: I don't know how good my suggestion is, but you can use Java3D and you can also use OpenGL in combination with Java, free.

WkD: Thanks for the suggestion. I"ve looked into Java3D and jMonkeyEngine. My
concerns are:

Java3D: is this receiving material investment on an ongoing basis by Sun, given
all their cost reduction efforts? As it is not focused on gaming, what is it's
rendering performance like? Are there robust 'import' capabilities from 3D
Modeling Tools like Binder, Maya, et al.?

jME: there is good word around about how quickly this open source scene graph
API is progressing, but I found the documentation to be quite limited. It's
focused on gaming, so that is good, and it has good import cababilities (or at
least they exist) for Binder, but it is built on LWJGL today which doesn't
support Swing.

That's what I'm looking for - some advise on a direction to take that is based
on insight into the above questions/issues.