Graphics in tile based games (in but not only in Java)
Author
Hi,
we are working on a tile based game (a strategy game) using an "asymetric" diamond as tile. Most works fine, but the most eye catching bug is the destruction of the isometric perspective.
The problem is that we used complete graphics for the buildings and if they are larger than one row the drawing does not work longer.
Would anyone have a hint for me how to split the graphics and place them seperatly. Think the Anno series splitted the graphics up into single rows but that is just a guess.
Woron
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.
Author
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
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.
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!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
