What I do is store them thus:

00 01 02 03 04
10 11 12 13 14
20 21 22 23 24 
30 31 32 33 34
40 41 42 43 44

& draw them like this (from memory):

int drawX, drawY;
for(int y = 0; y <= 5; y++){
   for(int x = 0; x <= 5; x==){
      drawX = (x * tileW - y * tileW) + scrollX;
      drawY = ((x + y) * (tileH / 2)) + scrollY;
      blit(map[x + (y * 5)].img, screen, drawX, drawY);
   }
}

I think that's how I do it, anyway. Not sure...

[edit: Hideously wrong. I apologise. ]

OMFG

store:

int tiles[3000][3000];//for whatever int property u wanne use(e.g. like which bitmap used)

draw them:

            00
        01      10
    02      11      20
03      12      21      30
    13      22      31
        23      32
            33

which makes it easy(i hope) for u to see that u don't need to draw them all/or check them all. It it really easy to just draw e.g. tiles[2][1] to tiles[3][3]

                21      
            22      31
        23      32
            33

As for danielH, DON"T U SEE THAT U DON"T HAVE TO DRAW THOSE TILES IN THAT STUPID ORDER....

      0
    1   2
  3   4   5
6   7   8   9
  A   B   C
    D   E
      F

~~~~~~equals sick(even when u first store the precalculated positions, by which u also don't need to draw them all))

sorry for my rant... but com'on.

hellow goodbites(sorry just had to do that:D(well at first it was spelling fault))

yeah I hope that danielH now gets it, after u and I, just after eachother said just about the same;)

here is some comment on your points:

1. as you could have read... it is a wrapped/looping map.
2. no point there cos we do care about the non-visible tiles... maybe you'r right but we have to focus on the problem here... maybe start a new threat for it cos I think your not right, see 3.
3. (that was fast, wasn't it). the calculations will be about the same. cos with the place of the screen u know on which tile that is and than u know the top of the partial tile-map...
http://home.wanadoo.nl/~mkmk/screentiled.gif
so as u can see on the beautifull picture, u need to check exactly 2 times as much tiles, but as this is a really fast algoritm and u don't need to draw anything...(doesn't take any significant time) it won't be a problem.
4.(my point)... odd/even gives to many complications... which aren't there in diamond..

so yeah maybe it is a, how do we say,"uninformed".

and now everybody bow for me... (pls)

A lot of your posts seem to convey that you think you are the sole holder of truth and knowledge in this thread For the record, spellcaster (one of the better coders around here) has written some pretty extensive tilemap (isometric and otherwise) tutorials on his (now gone) old site, and DanielH has a very good isometric tilemap demo on his site. You may prefer your methods, but they do know what they're doing.

Maybe we should have you all make a tilemap demo in 24 hours and see who did the best job I'm with spellcaster on this one ....

The reasons why rectangular maps better are:
- less instructions needed to draw lines
- less complicated to convert from screen to tile coords
- more easy to work with in editors, mainly because translation from screen to til pos is straightforward and "3d" / or multiple layers can be added without any new logic.

This is also stated above (way above)

Regarding your clever way to find the first row:
assume 32x32 tiles.
assume that the first visible pixel (in world coords) is 734,555.

Could you now please show me the algorithm to translate this into the first tile you need to draw?
After you found that tile, please also state the number of tile columns you need to draw, and the number of visible tiles for each tile column.
In other words: show me your calculations to ensure that only the visible tiles are drawn.

blah, blah, blah, ...

Goodbytes: I realize the drawing would be the same, but the storage would confuse me. I like to have things visual. And this was easier to visualize.
DOAdal3t: You do have to draw them in that order. And as I said before I only draw the tiles that are going to be visible that frame.

spellcaster: I do use rectangle maps.

Excerpt from the Book of Dan. In the beginning Dan said 'This is the first time I've done one of these so I'm not sure I know what I'm doing'.

It might not have been the correct way to do it, but it is my way. And a very good result in the process, which I'm happy with. How abouts you check it out? Le'me see whas yous guys thinks.

Using a rectangle map the way spellcaster says doesn't sound good to me. How do you figure out which tile is up left. Well if the row is odd then it is this, but if the row is even then it is this.

UpLeft:
Odd: tile - 1
Even: tile - width - 1

That was the one reason I did not do it that way. My way:
UpLeft:
Odd: tile - 1
Even: tile - 1

This post will probably be a pain in the arse
for people since I took the liberty of posting it
w/o reading any of the above posts and
maybe I even am talking about a compleatly
different thing...

but wouldn't plotting the map to
a page (or whatever they're called), then
rotating the entire output (clipped so it
doesn't go slow) and plotting that to
'screen' be the fastest and easiest way
to do isometric maps?

er... whats the prob w/ sprites?
just add them to the page that is going to be
rotated:

Map -> Page
Sprites -> Page

Rotate Page

Page -> Screen

But this way there isn't hardware acceleration, so it will be a lot slower.

And about the rectangle vs diamond thing: you can have this:

  - - 1 - -
  - 2 3 4 -
  5 6 7 8 9
  - A B C -
  - - D - -

You store the map as a rectangular one, but the you only draw the tiles that would be inside the diamond. You have unused memory, but maybe you can use those dummy tiles for storing some info.

The first time I thought about how to do my tile engine, I thought that this could be am easy way, but I ended doing a rectangular map, like spellcaster. I never thought that a 'real' diamond map would be a good aproach.

@logan666 : You have to check if there's at least 1 pixel of your tile in the screen. If none at all, don't even use the masked_blit(). The less you'll use drawing functions, the quicker your program will be. Make your own cliping tests, like :

for(my=0; my< 30; my++ )
{
   for(mx=0; mx< 30; mx++ )
   {
      sx = (SCREEN_W/2 -32 x) + (mx * TILEM_W) - (my * TILEM_W);
      if ((sx >= -64) && (sx < SCREEN_W))
      {
         sy = cy + (my * TILEM_H) + (mx * TILEM_H);
         if ((sy >= -32) && (sy < SCREEN_H))
            masked_blit(tile,buffer,0,0,sx,sy,64,32);
      }
   }
}

For the screen --> tile coordinates, it's not really hard. I'm placing tiles in a virtual space, and I "move" my screen over it. Then knowing the mouse position in the screen, no problem to know where it is on this space, then not really hard to know what tile it's pointing it (it's even a pixel-correct position):

{"name":"shem16.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/adc2391a21b71beec500b841ddca0cda.gif","w":601,"h":579,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/d\/adc2391a21b71beec500b841ddca0cda"}

If this image is too wide, I can reduce it, np. That's the logic I use for my Diablo II map editor, and it works pretty well.

[EDIT : thanks DOAdal3t for the img tag syntaxe.]

But it's an old image I have made there. You can speed up the process by making a 2D array, width & height of 1 tile,, and each cell of this table will tell you on which tile you are, like :

0000112222
0011111122
1111111111
3311111144
3333114444

1 will tell that you're on the x, y tile
0 that you're on the x-1, y
2 that you're on the x, y-1
3 that you're on the x, y+1
4 that you're on the x+1, y

You've got the idea.

Btw, how do put images in your posts guys ? I have searched for a help / list of code, like [img]...[/img] tags but didn't found any.

Ok, let's see:

x,y = 734,555
tileX = (734 + 555) / 32
tileX = 40

tileY = (555-734) / 32
tileY = -5

I doubt that.
Oh, I also think that you can't get the correct tile, if you don't know the size of the map... sorry about that. Let's say the size of the map is 100x100.
So, try again. Maybe you can now solve the riddle?

Once you found the correct tile in the upper left corner, please answer also how many tiles you need to draw in each (map) row... ie. how you r drawing algo ensures that only the visible tiles are drawn...

Since you can't actually use isometric tiles in your editor, you have several problems:
- no WYSIWYG
- No way to add several layers (like houses, trees, etc)
- Your artist can't test his tiles well. He needs to edit the map, then run the game just to see them in action.
- You need 2 tilesets. One for the editor, one for the game

Not sure how to comment that one.

I have no idea which would be the better way. Yours sounds more logical, but I don't like it. Mostly because I'm still thinking rectangularly with a rotated offset. Meaning I'm still looking at the same square, but rotated to a diamond.

I got the idea from a 3dpacman game I started where I could switch from isometric to normal drawing mode. I guess it just stuck in the head.

And about finding the tile. That's where my method is not prudent. I go through my template grid of 28x28 tiles. And find which one the point resides in using the color method. And as long as I keep track of which tile is at the top then I can find which one is anywhere in the grid.

But if I have a map of 100x100, I only look at the 28x28. If I have a map of 4000x4000, I look at the same 28x28. That was my whole thinking of why I created the template in the first place. I didn't know any other way to do it.

And that is the end of discussion. No more. Adding this to the ignore list.