quote:Original post by B-Bop
Instead of using Rects, why not use Triangles?
go to www.mikeward.uk.com to see what i am on about.
That way each "point" of a triangle is exactly in the centre of a hex and the centre of the triangle is exactly on a hex point...

So, items (inside a hex) are stored on the "points" of the triangle and movement is from the centre of 1 triangle to the centre of another...
(i hope that makes sense...?)
What do you hardened veterans think???????????

using triangles is essentially equivalent to using a rectangular grid and storing three pointers to the hex tiles. in addition, rectangles are much easier to work with mathematically than triangles, rhombusses, parallelograms, trapezoids, hexagons, irregular pentagons, or any other geometric shape provided you are using a cartesian coordinate system (which you are).

quote:Original post by B-Bop
I have decided to go for a 3D environment with a 2D hex map floating in space... If i fix the viewing camera at 42degrees then it should "simulate" an Iso-Hex view due to the fact that DX8 will auto scale items using distance and LOD rules. (please feel free to correct me if i am wrong...)
Then i will use sprites for the stuff that is moving about, and 3D object for planets and other immoveable objects.

D3D does NOT auto scale items. The D3D functions for helping create matrices create matrices that do so, yes. so don''t use them. construct your own matrices.

since you seem to be having a struggle with D3D, I''m going to provide here a brief refresher on what matrices in D3D ACTUALLY do for you (which is not exactly the same as what they are INTENDED to do for you)

in a typical vertex transformation pipeline, each vertex goes through three matrices, world->view->projection. what a matrix really is happens to be a set of four linear equations helpful in transforming points. the equations look like this:

x2=a*x1+b*y1+c*z1+d*w1
y2=e*x1+f*y1+g*z1+h*w1
z2=i*x1+j*y1+k*z1+l*w1
w2=m*x1+n*y1+o*z1+p*w1

as far as the matrix is concerned, it looks like this(at least in d3d):

a e i m
b f j n
c g k o
d h l p

in an orthographic (non-perspective corrected) projection, which is what i believe you want, w always should stay 1 unless you want to use it for zooming, and that case only affects the projection matrix. so, most of the time, m,n,and o are 0(zero), and p is 1.

since at the end of the pipeline you are in cube space (with -1<=x<=1, -1<=y<=1, and 0<=z<=1 being the only items that will be shown), your task is simply to come up with equations that will give you those sorts of numbers for that which you want to view. typically I do this by setting up a projection matrix that transforms coordinates as though they were being projected onto a 640x480 screen, with (0,0) still in the middle but with greater y values towards the bottom of the screen(just like in standard 2d).

I also determine an arbitrary range for my z values, also in "pixels". if you don''t have really high peaks or really low valleys(or extremely tall items to place on the map), a -128 to +128 should be sufficient. if you don''t have anything lower than the map itself, you can chop it off at 0.0 for the lower end. the lower the z value, the farther away (i.e. the higher the value place onto the z buffer).

so, with this sort of scheme, you might say that your projection matrix takes coordinates from (-SCREEN_WIDTH/2,-SCREEN_HEIGHT/2)(the upper left corner) to (+SCREEN_WIDTH/2,+SCREEN_HEIGHT/2)(the lower right corner), with z values anywhere from -128 to +128.

setting up equations for this is not difficult. you start with the x equation, then do the y equation, then the z.

for the x equation, -SCREEN_WIDTH/2 maps to -1, and +SCREEN_WIDTH/2 maps to 1, so the x equation is simply:

x2=(2/SCREEN_WIDTH)*x1+0*y1+0*z1+0*w1

for the y equation, this is much the same, except that we are flipping the coordinate system upside down, so must multiply by -1.

y2=0*x1+(-2/SCREEN_HEIGHT)*y1+0*z1+0*w1

for the z coordinate, which in the end should wind up between 0 and 1 and starts out at -128(which maps to 1) to +128(which maps to 0), we again must invert by multiplying by -1, divide by 256, and add 0.5. it winds up looking like this:

z2=0*x1+0*y1+(-1/256)*z1+0.5*w1

since w is 1 throughout, 0.5 times w will give us the slight offset we need to make this sort of thing work.

from here, you just keep working backwards. you can even use 3d models in this scheme, provided you orient them so that their "feet" or whatever are at 0,0,0, and z points downwards(or just construct a matrix that will rotate them so that this is so).