I'm in the "thinking" process on one of my new game concepts: http://create-games.com/project.asp?view=main&id=1176 I need a GOOD isometric engine preferably in tgf or something I can port to tgf (I own TGF2) for this game... I want something that will be easy to work with but still very powerful... I've seen pseudo-3d "isometric" engines that were just eight direction movements or bad collision detectors. I also might need a bit of help with isometric graphics if my artist can't do them... (No clue whether she's good at them, she's never tried.)
On the left we have the traditional 1-up, 2-over style of isometric stuff. Looks nice and straight. On the right is 1-up, 2 over with corners being 1x1 instead of 2x1. This second method makes for better z-axis stuff, but it looks rounded.
For both of them, you'd be able to use a simple y=1/2x slope for NE and SW movement, while a y=-1/2x will work for SE and NW movements. To change the z-value, just use an alterable value. In MMF2 (because I don't know about TGF2) you can just match the z-value to the layer; A higher z-value would mean being on a higher layer, which means you don't have to do a bunch of conditional stuff and use active objects for the background and stuff.
To make an apparent change in z, just use the formula y=8z. The 8 just means, according to the sample image I supplied, the number of pixels between the center of northern-most, raised tile and the tiles SW and SE of it.
I'm kind of scatter-brained right now, so sorry if parts (or all) of this doesn't make sense. I just spent 6.5 hours or so coding and recoding my own engine.
Ive often though about how an isometric engine would work, it never occured to me that the Z axis would basically use the Y axis, only with some kind of internal value to let it know how high the player is.
I haven't been able to test it yet, but could you clarify the Z axis just a bit? The center of the northernmost to the center of the one SW of it, the top one? It was a little confusing...
The northern-most tile is the raised one. In my magic land of absolutes, it is raised by a z-value of 1.
The green pixels indicate the number of pixels between centers. With this tileset, it is 12 pixels between centers (as indicated by the thin red lines).
If this doesn't tell you what's what, then I may just have to demonstrate with actual code. Or a bit of an engine!
the trick is to get things to display in the proper layer. in tgf this is a bitch. not sure how much easier it is in tgf2 with the layer object.
in tgf i just run from the top of the screen and run down the y values in a fast loop and just bring things forwards or backwards based on how close they are to the top or bottom of the screen.
@adam phant. the right one is actually more proper even though things look more rounded. the 2 over 1 up method has maths problems when rendering and scaling. i found that out the hard way.
well actually they both do. but the right method is better imo.
That clears it up a bit, thanks. But you don't think there's a chance you could show some handy code anyway, is there? I'm having trouble thinking how use this information-- I'm sure I could figure it out if I sat down and thought about it, but why do that when you've got refined coding techniques from people with experience in the matter? (And I'm lazy ) I tried a little isometric game once ages ago, and it used detectors for layering, worked crappy like. I've tried that thing about fast loop Y comparison, but it quits after awhile. (It was in my little 3D demo, Cow Tippin')