Hi,
Thanks for all the replies!
That''s cool how some of you have got the maths-equation way working. Obviously it can be done that way - it was just giving me troubles. If I''d just sat down with a piece of paper and pen... oh well.
It seems no one else has tried the region thing then? I''ve been thinking about it and I guess that internally Windows has to do some pretty hefty calculations to work out the PtInRegion thing, right? I mean, you are in no way limited to quads, so the algorithm it uses must be either very complex, or very simple and slow. I''m not sure about that...
Anyway, the isometric thing was my first try at a tile map thing. IT sort of works but I tried using square tiles (looking straight down) and that is much easier (obviously!).
It would be cool if isometric tiling was incorporated into DirectDraw... specify a tilesize and bingo! Hehe.
Thanks again, you guys are really quick to reply!
MrBo.
Isometric Tile Mouse Stuff
Another method is to take your tile shape, colour the different areas with different colours, and read the values of the tile shape. Others have suggested it but I take it one step further.
I have a very short little program that creates a text file as a .cpp file with an array.
int make_map()
{
int x, y, colour, colourx, coloury;
char skill_fname[] = "Array.c";
FILE *tstream;
tstream = fopen(skill_fname,"wt") ;
fprintf(tstream, "int CoOrds[22][24][2] = {\n ", colourx, coloury );
for ( x = 0 ; x < 22; x++)
{
for ( y = 0 ; y < 24; y++)
{
colour = fg_getpixel(x, y );
switch( colour)
{
case (STEPPE1):
case (STEPPE2):
colourx = -1;
coloury = 1;
break;
case (WATER1):
case (WATER2):
case (WATER3):
colourx = -1;
coloury = -1;
break;
case (GREEN1)://djungle
colourx = 0;
coloury = -1;
break;
case (GREEN2)://mjungle
colourx = 0;
coloury = 1;
break;
case (GREEN3)://ljungle
colourx = 0;
coloury = 0;
break;
}
fprintf(tstream, "%2d,%2d, ", colourx, coloury );
}
fprintf(tstream, "\n ", colourx, coloury );
}
fprintf(tstream, "};\n" );
fclose(tstream);
}
int CoOrds[22][24][2] = {
-1,-1, -1,-1, -1,-1, -1,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1, 1, -1, 1,
.....
0,-1, 0,-1, 0,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0,-1, 0,-1, 0,-1, 0,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
};
void WhichHexIsIt(int ms_x, int ms_y, int *xhex, int *yhex)
{
int diffx, diffy, xstrip, ystrip;
xstrip = ms_x/22;
ystrip = ms_y/24;
diffx = ms_x - 22 * xstrip;
diffy = ms_y - 24 * ystrip;
*xhex = xstrip + CoOrds[diffx][diffy][0];
*yhex = ystrip * 2 + CoOrds[diffx][diffy][1];
}
It was a 22x24 Hex-map (don''t ask: I''ve moved onto diamond iso-tiles) An array that size might thrash the heap but computationally it''s lean.
ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, old Hex-Tile editor, diary, 3D Art resources at
Check out my web-site
I have a very short little program that creates a text file as a .cpp file with an array.
int make_map()
{
int x, y, colour, colourx, coloury;
char skill_fname[] = "Array.c";
FILE *tstream;
tstream = fopen(skill_fname,"wt") ;
fprintf(tstream, "int CoOrds[22][24][2] = {\n ", colourx, coloury );
for ( x = 0 ; x < 22; x++)
{
for ( y = 0 ; y < 24; y++)
{
colour = fg_getpixel(x, y );
switch( colour)
{
case (STEPPE1):
case (STEPPE2):
colourx = -1;
coloury = 1;
break;
case (WATER1):
case (WATER2):
case (WATER3):
colourx = -1;
coloury = -1;
break;
case (GREEN1)://djungle
colourx = 0;
coloury = -1;
break;
case (GREEN2)://mjungle
colourx = 0;
coloury = 1;
break;
case (GREEN3)://ljungle
colourx = 0;
coloury = 0;
break;
}
fprintf(tstream, "%2d,%2d, ", colourx, coloury );
}
fprintf(tstream, "\n ", colourx, coloury );
}
fprintf(tstream, "};\n" );
fclose(tstream);
}
int CoOrds[22][24][2] = {
-1,-1, -1,-1, -1,-1, -1,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1, 1, -1, 1,
.....
0,-1, 0,-1, 0,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0,-1, 0,-1, 0,-1, 0,-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
};
void WhichHexIsIt(int ms_x, int ms_y, int *xhex, int *yhex)
{
int diffx, diffy, xstrip, ystrip;
xstrip = ms_x/22;
ystrip = ms_y/24;
diffx = ms_x - 22 * xstrip;
diffy = ms_y - 24 * ystrip;
*xhex = xstrip + CoOrds[diffx][diffy][0];
*yhex = ystrip * 2 + CoOrds[diffx][diffy][1];
}
It was a 22x24 Hex-map (don''t ask: I''ve moved onto diamond iso-tiles) An array that size might thrash the heap but computationally it''s lean.
ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, old Hex-Tile editor, diary, 3D Art resources at
Check out my web-site
Yeah, thanks you all :-)
I did look through the month-old threads and found one with the description (based on that the X-Value does not change with the height, you can determine the row of tiles it must be in, ...), but all your methods (Regions, Colors, ...) allow you only to determine the TILE which was clicked on, while before (when I had no height values and used my maths equations), I got a float-Value as isometric coordinates, and thus WAY more precision (Well, if you can only position a house in 40-pixel-steps, it may be OK, but with units?). I know this could be solved by making smaller tiles, but they a) would need much more memory b) would limit the area you have to draw a transition between two terrain types. Do you have any ideas how I could implement more precision?
I did look through the month-old threads and found one with the description (based on that the X-Value does not change with the height, you can determine the row of tiles it must be in, ...), but all your methods (Regions, Colors, ...) allow you only to determine the TILE which was clicked on, while before (when I had no height values and used my maths equations), I got a float-Value as isometric coordinates, and thus WAY more precision (Well, if you can only position a house in 40-pixel-steps, it may be OK, but with units?). I know this could be solved by making smaller tiles, but they a) would need much more memory b) would limit the area you have to draw a transition between two terrain types. Do you have any ideas how I could implement more precision?
Hum, hum, I just can''t stay out of this, can I?
Well, a few ideas:
1) don''t use colours with D3D... they''ll f*ck up with FSAA!
2) I just finished click detection for my game. I''ve been wresling with it the last few weeks but I just solved it. It''s not even 100 lines of code (VB, and it''s still unoptimised) It''s finally done and works perfectly... my 4x4 unit (the very first one in the game) moves to exactly the pixel where I clicked... and it''s very hilly terrain.
Anyway - I did it mathematically by using the method of the triangle side vectors... I think I posted the general idea in some post but I''m seriously thinking of making a tutorial for this. Anybody interested?
- JQ, PWC Software
"programming is all about wasting time" -me
Well, a few ideas:
1) don''t use colours with D3D... they''ll f*ck up with FSAA!
2) I just finished click detection for my game. I''ve been wresling with it the last few weeks but I just solved it. It''s not even 100 lines of code (VB, and it''s still unoptimised) It''s finally done and works perfectly... my 4x4 unit (the very first one in the game) moves to exactly the pixel where I clicked... and it''s very hilly terrain.
Anyway - I did it mathematically by using the method of the triangle side vectors... I think I posted the general idea in some post but I''m seriously thinking of making a tutorial for this. Anybody interested?
- JQ, PWC Software
"programming is all about wasting time" -me
~phil
I thought I would add just one more thought here. In my iso game, as I'm drawing each 'space' on the map, I check to see if the mouse is in that space using a function like this:
Unfortunately, this would be hardcoded for my particular iso tile size (80 wide and 40 high), but should be easy to change. I hope that is useful to somebody. It is a pretty simple function, all things considered and seems to work for me.
Edited by - jaxson on November 12, 2000 3:52:18 PM
int is_mouse_in_tile(int mx, int my){ int intercept; if(mx < 40) intercept = mx/2; else intercept = ( 80 - mx)/2; if(my >= 20 - intercept && my < 20 + intercept) return 1; else return 0;}// mx and my are the current mouse coords relative to the// upper left 'corner' of the iso tile.// for example, if this is your iso tile// .// /// / // \ /// \/// then the period might be the origin for that tile. It// is pretty easy to find the coords of the mouse relative// to this point by just subtracting the screen coords// from the mouse coords.
Unfortunately, this would be hardcoded for my particular iso tile size (80 wide and 40 high), but should be easy to change. I hope that is useful to somebody. It is a pretty simple function, all things considered and seems to work for me.
Edited by - jaxson on November 12, 2000 3:52:18 PM
Well jaxson, nice code but toally useless when you have different heights (which this thread is all about...)
Sorry but that''s the way it is
- JQ, PWC Software
"programming is all about wasting time" -me
Sorry but that''s the way it is
- JQ, PWC Software
"programming is all about wasting time" -me
~phil
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement