I'm gonna write an isometric tile engine, and I decided to make it a public project so anyone can help, learn from it , use it.
Good idea's are most welcome.
starting code:
HEADER
CPP
]]>
It might be a good idea to abstract drawing and maybe the underlying API so the engine can be used with SDL, SFML, etc
]]>The flat map (horizontal tiles) is a no-brainer, challenge is when you introduce vertical shapes and need to make them cover one another with the right priority.
]]>The flat map (horizontal tiles) is a no-brainer, challenge is when you introduce vertical shapes and need to make them cover one another with the right priority.
It seems to me that if you had a Z (depth) component, it wouldn't be effectively changed if you simply tilted the scene at 45 degrees and used the painters algorithm.
]]>Perhaps use some const correctness and initialisation lists.
You'll probably be wanting some kind of utility class to do conversions, e.g. pixel to tile, etc.
]]>
It seems to me that if you had a Z (depth) component, it wouldn't be effectively
changed if you simply tilted the scene at 45 degrees and used the painters algorithm.
The painters algorithm has the advantage that even transparent shapes will (mostly) work. If you have no transparency you don't even need painters algorithm, draw them in any order and the z-buffer takes care of it all.
]]>Good luck with a painters/basic ordering algorithm getting this to show:
Tried to include it, but the site still fails miserably with FF or IE to upload files for me.
]]>Good luck with a painters/basic ordering algorithm getting this to show:
Compare that bizarre case with the broken visibility determination in Tomb Raider 1, 2 and 3 (at least) and you'll realize it's not that big of a problem.
]]>Well, that specific image just doesn't makes sense, but it's true that painter algorithm is not perfect, but is usually good enough (look at games like Roller Coaster Tycoon 1/2, there are minor glitches but overall it looks good). Painters algorithm will render the map without glitches, the problem comes when you have objects that lie between 2 or more tiles (moving objects usually).
But if using Allegro 5, using Z depth is virtually free, so... that makes things simpler and the render doesn't have glitches (you just need to take care of translucent objects).
]]>Of course it makes sense, in a typical isometric game you have moving platform tiles or tiles that do not fit exactly onto the grid, e.g. the player.
In fact, it wasn't drawn, it was a screen capture from an isometric engine that accounted for this by using ordering and masks
]]>It doesn't seem to make sense if you assume they're cubes, but if you were to assume the blue box was shorter than the red box, it'd render like that.
]]>With a z-buffer the red/green/blue cubes will render correctly. Just if they were all half-transparent they wouldn't.
It doesn't even matter in which order you draw them - the z-buffer will store a depth value for each pixel. So if you draw red first and then green the obscured parts of green are skipped because they have more depth than the red in front. When now drawing blue it will overwrite red (because blue has less depth) but skip the pixels behind green as they again have more depth.
[edit:] This reminds me of a picture from an isometric engine I attempted a long time ago but which I gave up on back then after encountering this issue
]]>Aah, now I see how that image makes sense, but then those cubes are not spaced in a grid. I was assuming that.
]]>We have stacked tiles....
{"name":"605090","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/3\/b376d2ae2f35b1627fed21ef08a6f571.png","w":800,"h":619,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/3\/b376d2ae2f35b1627fed21ef08a6f571"}
Will you be hosting the code anywhere?
]]>As I said, the project ( and code) will be public
I hope it will evolve into something usefull
]]>