greetings all =D

I thought i would step in and just pose the question ''why?''

why would you want to do it mathamaticly, when it''s just as easy and sufficantly fast *IMO* when looping through the tiles and checking that the pixel your mouse is over on a given tile image isnt transparent *color key comparison, or alpha byte/bit*

now i know everyone is screaming "GAH! what if i have a 1000x1000 sized tile map? what then mr. smarty pants?"

well i would first wonder if your actualy enumerating all those tiles each frame *and I know your not drawing them all*.

so the first step is before you render your map create a subset of the map, part of the map that is visible,

now that you have that array, your probably only looking at maybe 200 tils at most *depending on tile size and display res i know but lets be realistic=)*

so then you want to what tile your mouse is over, obviously this should be done once, in response to a mouse move or frame update

so you loop through the subset of the map, checking for tiles who''s rectangular boundries fall within the point, when you find one, do a hit-test on the tile''s image *which could mean a lock ,read and unlock on vram but who cares, 1 or two isnt gonna kill ya. when you find the tile that has a positive hit test *mouse is over a part of the image that is opaque, or atleast not fully transparent, then you save the tile''s pointer, you then use that pointer *which could be null* as reference to the tile structure, simple as that, no crazy math=D
and to make things even simpler=D, for each map in the game you could simple generate a boolean hit-test mask in the shape of the sized tile this particular map is using and read from that, totaly removing the lock,read,unlock overhead. so all there is to it is to loop through some tiles and do some point-in-rect tests, sounds simple and straight forward to me=)

ok now I know im gonna get flammed for providing a lo-tech solution, so just be gentle



Raymond Jacobs,

www.EDIGames.com
www.EtherealDarkness.com

well.. I suppose that would work too, but I am thinking of implenting zoom in my tile editor also (not done yet though). That way I would be able to see a whole bunch of tiles at one time. But that matter can probably also be solved using color key somehow.. I don''t know

Why do it the easy way when there is a hard!

You would do a point-in-rect hit test on each visible tile

when one of those becomes true then you do a mask test =)


as for tile to screen coords

that sounds like drawing to me =)

im sure there is some kind of transform you could apply that would map the screen space directly into tile space and back

*rotating and scaling apropriatly*

but thats way over my head =D




Raymond Jacobs,

www.EDIGames.com
www.EtherealDarkness.com

So, I started doodling a bit, and here''s what I came up with:

You''re on to something with dividing a tile into the four sections ABCD, but i came to realize that section B is the same as section C, and section D is the same as section A. Really there are only two cases, not four, of these "quarter tile" coordinates.

the width of these rectangular sections is the width of the tile over two, and the height is the height of the tile over two, so it is easy enough to determine which rectangular section a particular point is by division.

//which quartertile are we in?
quartertilecolumn=worldx/(tilewidth/2);
quartertilerow=worldy/(tileheight/2);

//we''ll need these later...
quartertilex=worldx%(tilewidth/2);
quartertiley=worldy%(tileheight/2);

the only difference in the two cases is the slant of the line, one is positive (\) and the other is negative(/), according to their slopes in the coordinate system of the screen. the manner in which you determine the slant of the particular rectangle the mouse resides is to find out if quartertilecolumn plus quartertilerow is an odd number.

within the rectangle, the line is drawn between two corners, either from (0,0) to (w,h) or from (0,h) to (w,0), where w is tilewidth/2 and h is tileheight/2.
based on the linear equations for these lines, we can determine whether a particular point is above, below, or on the line.

equation for (0,0)-(w,h)

(x2-x1)*(y-y1)=(y2-y1)*(x-x1)
(w-0)*(y-0)=(h-0)*(x-0)
w*y=h*x
-h*x+w*y=0

dropp off the =0, and you''ve got a linear equation. for any particular x and y, only 0 means "on the line", positive and negative are on opposite sides of the line, which makes for a really simple test.

say that w and h were both 4(making the tiles 8x8):
x->
y
|
v
0 1 2 3 4
0 0 - - - -
1 + 0 - - -
2 + + 0 - -
3 + + + 0 -
4 + + + + 0

the actual values do not matter, only the sign.

for the other slant (0,h)-(w,0):

(x2-x1)*(y-y1)=(y2-y1)*(x-x1)
(w-0)*(y-h)=(0-h)*(x-0)
w*(y-h)=-h*x
w*y-w*h=-h*x
h*x+w*y-w*h=0

and again drop the =0, and here''s the graph for w and h of 4 for all x and y values within

x->
y
|
v
0 1 2 3 4
0 - - - - 0
1 - - - 0 +
2 - - 0 + +
3 - 0 + + +
4 0 + + + +

how is this all useful? well, based on the quartertile row and column, you can determine which two tiles the mouse might be in, and you can determine the slope of the line bisecting it. with the equations, you can tell what side of the line you are on, which you can use to decide which tile of the two the mouse is in.

is this "better" than a mousemap? no. in fact, it is almost identical to a mousemap. really, you wouldn''t want to calculate with these equations each time the mouse moves. you''d want a lookup table, which would serve exactly the same purpose as a mousemap.