Hi, I’m working in an isometric demo, up to now i got the projection working. I use this simple piece of code to get the job done

for(my=0; my< 30; my++ )
{
for(mx=0; mx< 30; mx++ )
{
sx=( mx * TILEM_W ) - ( my * TILEM_W );
sy=( my * TILEM_H ) + ( mx * TILEM_H );

masked_blit(tile,buffer,0,0,sx+SCREEN_W/2 -32 x,sy+cy,64,32);

}
}

As you can read the map is 30 x 30, tiles are 64 x 32.

The problem is how to draw only what is seen in a given moment and not drawing the entire map every time, so that drawing speeds up with bigger maps.

I’m still trying a couple of ideas I came up with but haven’t succeed.

Any one has an idea to help solve this isometric maddness?:-[

Figure out which tiles will be seen and only draw those. Take the camera position and use that as the center. Go out from the center a few tiles until you are sure that the view area will be completely covered. Then draw it. In my isometric game, I have a 14x14 grid of tiles, but I draw a 30x40 grid of tiles to cover any missing areas.

The vertical postion at the bottom might need some extra if you have a height to the tiles. I have a few tall tiles. they were disappearing instead of scrolling of the screen. I had to adjust the height until they no longer 'disappeared'.

The source code might not be understandable, but you can download my isometric source. 'Daython's Quest' from the link in my sig. Look under 'mygames'.

I created a template for the grid size. I calculated the position of the template when the game is initialized. And I use that template throughout the game to find the position of the mouse, etc...

Don't draw diamond shaped maps.
It's way harder to draw them, way hareder to find the mouse position, etc.

Simply draw the map the way you'd draw a normal rectangular map. But: For every row increase y only by half the tileh eight and offset x every other row by half the tile width.

If you want diamond shaped levels, simply put only visible tiles there, and use transparen tiles around them.

Did this make sense?

I'm curious again:) In an isomentric game, how to you handle the sprite drawing order. You must have to blit the one that are further away in the Y direction first? Or have I just answered it, loop through all the visible sprites checking their Y positions...

You might want multiple layers.

I have multiple layers.
I draw the ground first
then any buildings/walls
then any roofs.

I draw the people sprites in the middle of drawing the walls. Draw all the that are farther away first. then draw the sprite. Then repeat for next sprite.

and about the diamond shapes maps. Now you tell me. Oops. Because of the order of drawing, that is why I have a diamond shaped drawing

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

And it was hard to draw it. That's when I came up with the template system. I calculated the position for each tile before hand. Then all I had to do to draw it was draw the tiles

draw_map()
for int i = 0 to MAXTILES i++
template.draw(i);

Daniel H

what is the idea behind your template system ?

There are too many calculations done in the map drawing. By doing all the calculations once in the template there are very little left during drawing. So far I get 80+ FPS.

I like the idea. How daft is this. I'm barely 20% through my first game and I'm already planning my second!!!

Draw the map like this:

   0 1 2 3 4
    5 6 7 8 9
   a b c d e

Now imagine that the lines are half the tile height apart... like this:
http://www.steinke.net/download/iso.gif

See? That way you can use a slightly altered rect map drawing algorithm.

spellcaster: I did my isometric engine just like you (only that I have also height, so it's semi 3D . But that depends on the game.

Spellcaster:

I got the isometric stuff working with non diamond shaped maps, think its a better way to go, thanks for the advice.8-)

Glad I could help.
I had a similar problem some time ago... when I found the non diamond shaped version, my life got so easy

I'm dumb!... spellcaster shouldn't u know better...

use the diamond-style, but use it different...
(another way of drawing(really better for looping/wrapping tiles))

sorry I give u the dignity to commup with the anwser...(it is much better than that odd/even stuff) so that were all the hints...

[url http://home.wanadoo.nl/~mkmk/screen2%20copy.jpg]
ps... sorry the new engine is ready soon...(so new screenshots)

Not sure what you want to tell me here?
Main problem with diamond style is not drawing but screen->tile coords conversion.

And writing a map editor is much more easy as well.
But I'm always open to learn new things
So, enlighten me...

gay... but I now own u(if it is something new to you).. well I now own all the people who read it:

so bow for me, I am the elite...(still searching for others)

well enough about that;D

      0
    1   3
  2   4   6 
    5   7
      8

this is simpler isn't it... well it has more...

I still don't get it.
What's the good thing drawing your tiles like this? All you did was drawing right->left instead left->right.

IMO this adds one more step during the screen->map conversion process.

Ok, so what do you gain if you draw your map this way?

I never need to worry about odd/even... so e.g. circles will be circles...8-)

Odd / even?
Circles?
I never had problems before with circles... If I place circle tile nest to each other in the editor, I have a nice circle on the map.
And odd even is not really a problem. The most easy thing is to unroll the loop slightly and to draw both odd and even row in one iteration.

Ok, guess i'm dumb, but:
a) I don't understand the porblem you have with using a rect approach
b) I'm not sure how your approach is better than the ´"normal" diamond shaped map way

Help?

the algoritm to place the tiles(so that they overlap the good way) is fairly difficult in the other diamond way.
In my way it is really straight forward...

and about the circles... in my way it is really easy to change diameter without a set of precalculated masks(U use that... I think?).

I think u should relook the numbers...;)
(cya tomorrow(need to sleep))

Sorry, but I think you want to solve a problem which doesn't exist

        0
       4 1
      7 5 3
       8 6
        9

That's the "normal" way to draw diamond shaped maps, with (0,0) at the top, and map-x increasing down right, y increasing left-right.
So, basically you switched the direction of x (or swapped x and y, depending how you view it).

And i'd really like to know how you draw circles without having the tiles containg the circle gfx?
I mean, circle with a diameter of 10 tiles needs other gfx then a circle with a diameter of 20 tiles...

But the main problem with the diamond shaped map is the conversion from screen to map coords.

d00d, why did you not propose the "normal" way... Cos DanielH proposed:

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

which is totally sick...
and u only proposed the odd/even way...
So I thought why doesn't anybody propose the way I use...(yes your normal way is abvious totally the same(so yes we were talking about no problem))

But I still think that the "normal" way is better than the zigzaw way. take for instance the calculation of a guy on ht isometric tile-map... in the jigzaw-way u still need to worry about odd/even... and also for placement that is neccesary... as for the normal way... all is pretty straight forward...

Ok, assume you have a map drawn your way. Please tell me how do you translate a mouse pos into tile-coords?
Assume that the "tip" of your diamond is not visible, how do you determine what to draw? Ie. which tiles are in the first visible row?

Also, since you need to increase both x and y for each tile, you have more work in your inner drawing loop. At the end of a row you need to do additional work to reset the starting position.

Finding the correct number of tiles to draw per map row is also a problem since the number of visible tiles per map row differs...

Having multiple levels (along the z axis) does also become more complicated, esp. inside an editor.

Pardon? If the guy can move independently from the tile position (free movement) all I need are his world (screen) coords. Which can be translated to tile coords easily. But this is not needed, since you can do almost everything in screen coords (like sprite / sprite collision).
If he's attached to tiles, all you need to do is to keep constant track of the tile he's currently on (so the tiles have an object pointer which points to whatever is on them, like the player, enemy an item, etc).

So, in the worst case you need to convert screen to tile coords, which is almost as cheap as with normal rect maps.

My map is like this

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

but I draw it in this order. That was a problem.

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

By determining which tiles go where and when, the drawing was easy. All I have to do is supply which tile is at pos 0. Then the map template program does all the work. Very easy very quick.

I have varying size tiles, width and height. So I also check to see if any are inside the drawing area before trying to draw them. That saves time also.

About the tiles, the bases are all the same. 64x32, but you can have anysize object. Just center it vertically in the tile and adjust it so that the bottom of the object is in the center of the tile.

Ok, since both of you use diamond shaped maps... if you have a map which is way larger than the screen, how do you guys determine the upper left tile?

d00ds... think....So I was right, u people don't get it(well at least danielH)...

The drawing order IS:

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

And just for the info... my tile-map=3000*3000 tiles(32*32 bitmaps see my screenshot), and it is wrapped(looping)
and to spellcaster:
the "guy" has a real xy, a screen xy and a tile xy which is simply calculated from the other two.

During game play all I have to do is keep track of the very top tile. And adjust around it.

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. ]

That's the point. If the very top tile is at -1200 (in screen coords), it means that you have to draw a lot of other tiles before you get to the visible ones.

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.

spellcaster is right. Leave him alone.

Now, seeing as this is not Off-Topic Ordeals, I can't just leave it at that, I have to contribute something... I think. So, the way I see it...

The 'rectangle' layout that spellcaster discussed is better in my opinion, because:

1. Rectangular maps make more sense to the user when you have a map bigger than the screen, for scrolling purposes, because you never have to scroll diagonally when you reach the bounds of the map.

2. Rectangular maps are less complicated when you don't care about drawing tiles that aren't visible, because there are less variables to keep track of, if you can get over the odd/even thing.

3. Rectangular maps are insanely less complicated than diamond-shaped maps when you do care about drawing tiles that are off the screen, because it takes less work and fewer calculations to determine which tiles are on the screen and which are not.

I would prove these points, but I'm too lazy.

Also, DanielH, why draw your tiles in a different order that they are stored? You do realize that drawing them in this order:

    1
   2 3
  4 5 6
   7 8
    9

is functionally equivalent to drawing them in this order:

    1
   4 2
  7 5 3
   8 6
    9

right?
Why go to the trouble of drawing the tiles in a 'non-native' order?

[EDIT: Upon re-reading the thread, I'm not sure whether or not to brand this post as "stupid" and "uninformed" or not, but I'll keep it up just in case. ]
[EDIT 2: If it is stupid, please enlighten me.]

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)

ahm drawing some tiles in which order what so ever is not the problem. The problem is that you need to find the correct start position in the first place.
Do you have a working demo of your engine? Which has maps larger than a single screen? Say maps which are 10x10 screens large?

In closing: I must really say, that if you think using diamond shaped maps is better / more easy or faster than rect maps, then you're simply wrong.

Just want to point out that you need algos to solve problems which can be solved with a single formula with rect maps.
Also odd/even is not complicated at all? What's complicated there? I can't see the problem...

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 ....

com'on did you even read my post... the x,y position of the screen is known so the purple leftmost circle is known... and then also the other purple circle is known.

no demo... but working engine. I first used the rect form but in my game the diamond form really is even more at an advantage... demo will be ther is the new engine also looks good.

nice point u have there... I woundn't take on philosophy or something if I were u, cos for those studies you need reasons... maybe u should believe in god(sorry this is off-topic rant maybe start that threat somewere else:-X)

odd/even is not really complex... but more complex than diamond...

well see u again tomorrow... /me sleep

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.

I'll throw my two cents behind spellcaster. Rectangular isometric maps are more straight-forward. The whole odd-even thing is close to being trivial... anyone who has coded up a standard tile engine would know how to do it... just a few more simple statements in the loop.

Screen-to-Tile coordinates is easier with rectangular isometric. Can't argue with the math.

From what I can tell from DOAdal3t, he's finding the starting diagonal row and ending diagonal row from screen coordinates and screen size, using a screen-tile coordinate transform. Not a large speed hit. However, his method needs to check at least 2X the number of tiles that can be shown on his screen. A lot of inefficiencies from if statements and additional looping math overhead.

Compare with the rectangular isometric: the extra tiles to be checked (to see if they would actually show up on the screen) is on the order of the perimeter size of the screen rather than the area. The number of tiles drawn should be about the same.

I don't see an advantage with diamond isometric maps in terms of wrapped maps. The rectangular isometric handles wrapped maps as well as, if not easier than, rectangular isometric.

One last tidbit, games like Civ3 seem to use rectangular isometric.

I lied; I had another comment:

and other statements remind me of silly kids in junior high. These sorts of statements aren't exactly persuasive... in fact they just incite the crowd against you.

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

DanielH: While writing my reply above I realized that the 2nd best way to draw the map would be the you're doing it

Regarding top left tile: the question is how to find "tile" in the first place Point being here is that you have to deal with the fact that tiles are half tile size appart...
Translating from screen to your drawing order is the same as for rect maps. But you need to add one additional step to translate from drawing order to map-coords, so you know what you have to draw

Or am I missing somthing (wouldn't be the first time)? Could you use my example above to show us how your solution would work with the above values?

This way we can compare all three methods... allowing the lurkers to find the method they like best. It would also make the discussion more specific, since we then know the algos (which allows us to talk about the running speed and complexity of the solutions, etc).

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?

Nice idea. One problem:
Sprites

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

Sorry, that was too loose.
Imagine that you have a large house. That house would normally consist of many tiles, which are placed on a 3d map.
It would be pretty hard to render that one, unless you use sprites for all sorts of objects.

And then you won't need isometric tiles at all, so there's no need to rotate the map.

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.

tileX=(y+x)/32
tileY=(y-x)/32

tile[x+1][y-1]for going one tile to the right
tile[x+1][y+1]for going one tile down

and here the editor:
http://home.wanadoo.nl/~mkmk/MapEditor.gif

I don't see why i should do the odd/even stuff.
I think my system is a really clean one.

@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.

check the mochup is on:

<img src="http://www.allegro.cc/templates/classic/media/logo.gif" />

and join this discussion with all your heart;D

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.

d00d.... think. the calc was correct...
(some floor ceils not included, but that I hope u can figure out urself)
http://home.wanadoo.nl/~mkmk/I'm dumb!.gif

only for wrapping I need the map size...

I'm dumb!. bow for me now???

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.

I think you guys are missing each other.

Here's how I think DOAdal3t is doing it:
The starting drawn tile, in screen coordinates, is (scr_origin_x - scr_w/2, scr_origin_y - scr_w/2)

To find the starting tile in tile coordinates, he uses more or less:
tileX=(y+x)/32
tileY=(y-x)/32

Now the key is that a negative tile coordinate is okay if the map is not wrapping. The reason seems to be that DOAdal3t is "brute forcing" it. With this starting tile, the drawing loop would check for:
1) Legal tile coordinate. Obviously 'virtual' tiles with negative coordinates and coordinates > map size are skipped.
2) Whether the tile shows up on the screen.

With a wrapping map, all tile coordinates are made legal by use of map size.

As for the number of tiles per diagonal row, this would be approximately:
(scr_w + scr_h)/sqrt(2)/TILE_DIAGWIDTH
And similarly, the number of diagonal rows would be:
(scr_w + scr_h)/sqrt(2)/TILE_DIAGHEIGHT

The number of tiles that go through the loop would then be approximately:
((scr_w + scr_h)^2) / 2 / TILE_DIAGWIDTH / TILE_DIAGHEIGHT

This is approximately 2X the number of tiles used in a rectangular iseometric. Thus there is a lot of inefficiencies due to if statements and such.

sorry DanielH... I want a last post too...(nr. 50)

Just need to tell Plucky this:
U think U use this:
http://home.wanadoo.nl/~mkmk/screentiled.gif
so not approximately 2X the number of tiles but exactly 2x the number of tiles.
but is really easy just to check the correct ones because:
tile[x+1][y-1]for going one tile to the right
tile[x+1][y+1]for going one tile down

and yes as I use a wrapped map, -1 is no problem...

Think again.
Or do you have negative y positions in your map?
Normally only positive positions are valid. Even if we assume that negative values would be ok, -5 is around 39 tiles away from the correct result.

His map is wrapping. And the question was which tile is visible in the upper left corner.
He has not shown a solution for this problem.

Nope.
Your tile at map (0,0) is at ((map_width-1) * tile_width) / 2.
Since you need to calc all positions of your map relative to that tile...
I begin to think that you don't understand the question.
Anyway, let's assume that you found the correct tile to be displayed in the upper left corner (which is not the case, but let's assume it anyway).
How many tiles are visible? How does your drawing loop look like?
How can you do stacking tiles (in the editor)?

Ok, now let's assume that you actually manage to do this job... do you really think it's more easy than to simply use a rect iso layout?

You're (all ?) assuming that the tiles are a fix height (pure diamond tiles). And what about walls : same width, but any height. So a wall that have its 'feet' under the screen may not need to be draw, except if parts of it is so high that it need to appear in screen... In this case, you can't apply your optimizations, you need to check all the tiles that have their X in the screen (not too left, or nor too right), because maybe the high of their wall have to be draw.

nope.
Why do you think you have to do that?
Ah... guess you're using diamond shaped maps as well?

I am sorry matthew, but I have to say this...:
edit
Spellcaster you are not reading my posts:
I still believe u just don't wanna see the solution.
edit

And for once , just read my post.
I proved to you that the calculation:
tileX=(y+x)/32
tileY=(y-x)/32
is correct, because:
I took your question x=734 and y=555, but made the number smaller(x=73 y=55) to fit them in the bitmap I will show again:
http://home.wanadoo.nl/~mkmk/I'm dumb!.gif
(y+x)/32=4
(y-x)/32=-.6(equals -1)
and as you can see in the bitmap: that is the correct tile... which isn't on the tilemap, but that is no problem because I use wrapped maps
so if the screen pos is (73,55), the first tile will be tile[4][-1]

as for height check my screenshot:
http://home.wanadoo.nl/~mkmk/screen2%20copy.jpg
and I am working on my new engine so a new screenshot will be there soon.

Oy. Can we please ban this cretin?

EDIT: Interestingly, the tiles in his screenshot don't even line up right

just edited it... without knowing your post...

Nice gfx.

Maybe it's because of of my recent Diablo II map editor that I'm constantly thinking about height of diamond tiles. This game use them intensively. I have made a simple test program (with source) http://paul.siramy.free.fr/_divers/iso3d.zip (with so dull gfx), where you can see that it's not a problem to to the mouse --> tile in 3D iso. I'm using walls as I said, but to not make it too complex, I only use 'regular' walls, that go to the up, not to the bottom.

The mouse to tile function is quiet easy :

I'm using walls, so as I said I need to check all the tiles, but that's definitvely the drawing process that slow the program, not the checks. I have an average 25 fps on my P166 MMX. I won't say this is an optimized program, but an easy to understand one.

Sorry. But your are wrong again.
If you want to scale the whole thing, you need to divide the tile size by 10 as well.
If you don't do that, you get completely wrong results.
If you simply wanted to use smaller world coords, you're missing the point again. The idea is that you use these large numbers

Ok, now let's take a look at your 73, 55 example.
First of all: There's no way you can determine the correct position w/o knowing the size of the map.
Let's assume a 10x10 map.
Here's an image of a 10x10 map with 32x32 tiles. the point 73,55 is marked with a red cross.
http://www.steinke.net/download/iso.gif
If we assume positive x and y axis the correct position would be (-1,3).
Or if you increase x down/left (3,-1).
Ok, now let's assume that the map is only 5x5 tiles large.
http://www.steinke.net/download/iso2.gif
As you can see, the visible tile would be (1,1)

So much for:

You're also ignoring all other questions...

I agree with I'm dumb!. In fact, it's more like LMAO.

My only comment on this thread would be along the lines of "Nice show of restraint there Spell". Not sure I would have been so tolerant...

Just to wind everybody up. When I did engineering drawing at school, I'm sure Isometric drawing had different angles to the ones being drawn here

isn't it 7 and 23 degrees?
Been some time since I had tech drawing at school.

30 and 60 IIRC, but then ago, it is a very long time ago

spellcaster I think u just want me here banned, and therefor just don't wanna believe...

here is prove:
new engine: see the 3 tiles(cubes) that are above the others... they are (from bottom up)tile[2][2], tile[349][349] and tile[348][348]... so have fun don't believing me... I have my engine again(was rebuilding it) for about 10% fini...
http://home.wanadoo.nl/~mkmk/screencopy3.gif
the yellow rect is the mouse at tile[0][0].

ey paul... that mouse thing can be done much faster... and I don't have to check all 350*350 tiles tomake higher tiles...

Geez.
The point is I want to believe.
I'd really like to know a way to draw diamond shaped maps in a more easy way than rect iso maps. Really.
I'd also like to know how you can compute the correct positions w/o knowing the map dimensions.

So... could you show me?

Regarding the image: nice.
But it doesn't answer a single question

Oh, and I want to give you just one more thing to think about:
"For every complex problem there's a solution which is fast, simple and wrong".

gay... I see were u go wrong...
I told u... look at what I write:

u take (0,0) different...(sorry to say... but yeah that is a stupid place to put (0,0))...

look at my pictures and see that I take (0,0) at the top of the tile [0][0]... and now u can probably also see that my calculations are correct...
http://home.wanadoo.nl/~mkmk/storageDraw.gif

so now bow !!! jim too pls.

As I said before, you two guys are missing each other in a dark room.

I guess I should have been more explicit earlier in explaining that DOAdal3t starting tile is off the screen, which in screen coordinates is: (scr_origin_x - scr_w/2, scr_origin_y - scr_w/2) where the screen origin is the top left hand corner. So DOAdal3t is not trying to find the top left hand tile of the screen. The disadvantage of this is that you're forced to check twice as many tiles as that are necessary to draw on the screen; therefore about half of the checked tiles won't be drawn.

DOAdal3t: I said approximately 2X because 2X is true only when screen height and width are equal. The number of tiles to be checked is not 2xy (twice the area), but rather (x^2+y^2)/2 + xy. If y=x, then the equation turns into 2xy (2x^2). For most full screens however, x:y is 4:3.
[edit] or if screen height and width not equal, then the tile diagonal widths and height are proportioned the same. [/edit]

All that being said, I still like rectangular isometric maps. The overhead seems smaller.

precisely 2 times, cos it folds like an envolope... see previous pictures... but that is the stupid way of doing it... it is not difficult to check horizontally:

tile[x+1][y-1]for going one tile to the right
tile[x+1][y+1]for going one tile down

Moving the origin is clever
But drawing is still more complicated... but I must admit that I'm impressed. Moving the origin really is clever.
Your formulaes will work only for square (which means: non isometric) tiles, though.
But for this special case, the calculations are almost as simple as for the rect map layout

But: if you want to draw that map you still need to have extra checks to determine the number of tiles to draw and you still need extra operations to move from tile to tile.

And the map editor problems are still there.

So, at the moment I'm impressed by the idea to move the origin, but I still think it only helps to move closer to rect map layout. Rect map layouts have still more "pro"s, IMO.

Anyway: Nice idea

. My only contribution to this thread was to comment on your poor attitude. I stand by that comment. Your frustration at your inability to get a point accross, does in no way entitle you to insult a fellow member of this board. I have not been using these forums (or allegro for that matter) for very long, but recognise as a place where ppl treat each other with simple respect and courtessy. Somthing I think you stand to learn from.

spell:
ofcourse it will work on isometric (like 32*16)
tileX=(y*2+x)/32
tileY=(y*2-x)/32

and the number of tiles is only dependend on the screen_w and screen_h so:
if I have the starting points tile[x][y] then a 1024*768 screen will display tile[x][y] to tile[x-32][y+32](32*32=1024) and down to tile[x+48][y+48](16*48=768)... so not that much extra work...

and as for the editor I don't see were there are problems here... can u show me a editor of your type...(Then I can comment... lets take it to 100)

As for Jim... your contribution was just arrogant enough to make u bow... and as for the respect: respect with me you need to earn and if you read this post you can clearly see that spelcaster could have seen that origin difference much earlier if he had looked at my beautifull pictures with an open mind(as maybe he sees that now too)... and just for the record: it was I who pointed out what he didn't see. And a last point:
I did not for nothing change morron in (non reader/non believer).

My final post on this subject. I will treat you and what you have to say, with the respect you deserve. How you have the audacity to make a comment about arrogance is frankly beyond me. I notice a feature on this forum to ignore a user, this will come in very handy in your case.

This gets my vote. He may have had something useful to contribute from a technical standpoint, but his general attitude is not tollerable. Whereas I hate the idea of "heavy handed" policing of forums in general, I would hate to see this board deteriorate to this posters level. Which by tollerating him, we are advertising is acceptable.

I'm going to kill this thread as well.
It will become a flame war sooner or later... to be honest, I'm not sure I wouldn't contribute to t sooner or later

doad:
Regarding your postings... they were not clear at all. Same for your pictures.
And Jim is right: You do have an attitude problem.

Regarding the discussion: If you'd read the posts made by the others you'd find the answeres to most of your questions

Yes, this thread has become a non-sense war.
Just do whatever is more appropiate for your game. If you're doing a game like SimCity or Transport Tycoon, a diamond map is the best, for an RPG, for example, a rectangle map probably is better.

If you want an example of an editor that uses rect maps, you may take a look at mine:

screenshot 1 (building)
screenshot 2 (empty small map)
screenshot 3 (tile editor)

It works at almost 60fps in my poor pentium 166 at 640x480x16 (with hardware acceleration enabled) if the map is optimized

ellow everybody,(this is really off-topic and probably also nobody will read it, cos they killed it)

I thought there was no problem anymore... we both now know why we didn't understand eachother.

I do not really have any questions... but I now do know that if I have any, I will ask u... for u will do about everything to show me the anwser.;)

I know I too(:D) am extremely arrogant, but I also know from others and myself that it is grounded.
and yeah lets ban everybody who is smart and know it.

ps... real nice editor, Oscar

and if there was going to be a flamewar there should already be one