>>If in a 2d world, i have x,y...x is the east/west of map and y is the north/south of map.
But if i move my 2d map into 3d, the axis' change?!? So, my X is still east/west, but now
Z is north/south AND Y IS NOW the height of the tile. If we are in isometric,
i guess this would be like a tile either being closer to the screeen(mountain) or
further down in the screen(valley)
Is this the correct use of the axis in 3d/isometric ? <<
Correct
![](smile.gif)
Try to imagine your world coordinates as being x,y,z as you pointed out.
Your screen has only two dimensions. It just so happens that Y ends up confusing
issues. But you have transformed into view space and dropped the third coordinate.
I am going to keep this to a bare minimum. No optimisation but only to try and
describe what you may need to grasp.
For simplicity sake let's say your engine consists of a ground tile and it lives in
a possible 64x64x64 cube.
I want this tiles height to be smack bang in the middle of the cube.
So it's local coordinates (Cartesian) are..
top left x1=-32, y1=0, z1=-32
top right x2=32, y2=0, z2=-32
bottom left x3=-32, y3=0, z3=32
bottom right x4=32, y4=0, z4=32
You have described your tile has a polygon. If your tile is masked then simply describe
the bounding area it makes no difference.
When you create a tile you have manually transformed it. If I took the following coordinates
and passed them through a 3D tranformation matrix with the appropriate camera I would
get your tile. So try to imagine that you are actually plotting pre transformed polygons.
But you now want to position it into the world. Because you are not rotating
(Because you have manually rotated the tile) then you simply translate this to the
world coordinates.
tile_world_x=64;
tile_world_y=0;
tile_world_z=64;
for all of your tile vertices simply add the world coordinate. So x1+=tile_world_x ,
y1+=tile_world_y,z1+=tile_world_z and so on.
Later on you can get into zooming and stuff but the most important aspect is that you
have described the geometry of your objects.
Guess what you have done you have supplied 3D info to a 2D object. In a traditional
3D engine you do it the other way round but you have cut out the screen transformation
because you have done it by hand. You have cached the result
![](smile.gif)
So carry on with your drawing method but store full X,Y,Z against the objects.
>>Can you explain what you mean by "one off setup" I've never heard that terminology <<
Sorry what I meant was when you want an object to move you only have to calculate the
potentially expensive operation of the multiply once.
So..
Player decided to fire an arrow
figure out direction and velocity
block player from firing another arrow or use a timer to decide when
they can do that again.
on each frame until hit something or arrow fell out of range
move arrow
>>Also, would you recommend using floats for your movement?
thanks. <<
Difficult question
![](smile.gif)
It all depends on what you want to achieve. I tend
to store everything in integers use floats to calculate movement then convert
back to integers. I suppose one rule could be if most of your calculations
are in integers then demote floating point, otherwise flip the promotion!
Edited by - ancientcoder on March 21, 2001 8:16:39 PM