Hey, Ive been developing an iso engine for the last few weeks, and everything works nicely, even the scrolling when working with a few limitations... Im writing this at 2am, so hopefully it''ll make sense... currently my engine (unoptimized) works like this: I have a scrolling amount called "sx" and "sy", this amount gets incremented by a certain number when the key is pressed, so what I do is calculate the appropiate position in the map''s 2D array.. (my tiles are 64x32 iso).. so to get the position on the array all I do is: xpos = sx / 64; then I use xpos as the starting point in the drawing loop, like this: for (h=ypos; h < ypos + NumOfVerticalTilesOnScreen; h++) { for (w=xpos; w < xpos + NumOfHorizontalTilesOnScreen; w++) { // calculate the tile''s position on the screen and // draw it, no problem here, I think... } } I only did this to optimize the map drawing a bit, instead of drawing the entire map, I just draw what''s on the screen. well, that works great, except for one tiny detail, see, in my engine, I allow tiles of different sizes to be placed on the above layers (except the base layer), so, if I have a large tile that scrolls off to the left of the screen, it''ll disappear, so I figured I''d fix this by adding a couple of extra tiles to be drawn off-screen, which works ok, except that it introduces some weird scrolling errors, like sometimes it''ll scroll 3 or 4 tiles at once.. so after trying many to fix it for a LONG time, Ive reached the conclusion that maybe my whole approach is off.. So, I wanted to know what would be the best way to make the map scroll without scrolling errors or "jerking" while still allowing my tiles on the above layers to be of different sizes (it''s ok if I have to limit the size of the tiles on the top layers, I just dont want them to be necesarilly the same size as the base layer tiles). oh, and Ive already read all the tutorials on scrolling Ive found, but none of them have helped me in this regard, however, they did get me this far. If this didnt make sense let me know and I''ll make it a bit cleaner when Im a bit more awake... Thanks! VisualLR visual@guate.net Luis Sempe
visual@guate.net
http://www.geocities.com/SiliconValley/6276

one thing you could try is using tile extents. a tile extent is nothing more than a rectangle that is the smallest rectangle that could encompass everything on a tile, and at the tile''s world position.

for example, you have a normal tile (64x32) with the upper left corner being at 256,16, so the normal tile''s extent is (256,16,320,48)

and you have a tree who''s bottom lies in the middle of the tile, is 8 pixels wide, and 64 pixels tall, so IT''s extent would be (284,-32,292,32)

the combined extent would be (256,-32,320,48)... the smallest rectangle into which both would fit.

now, you translate this from world coordinates to screen coordinates with the sx and sy variables.

and, you see if the translated rectangle intersects with the screen/play area rectangle. if it does, then you blit the tile.

you can optimize this by keeping a lookup table of all of the tile''s extents, and a 3d array that gets marked as scrolling happens whether a given tiles is visible or not.
also, when scrolling occurs after the visibility has been calculated, you can just test the edge tiles for change in visibility, and not have to calc the whole map again.

TANSTAAFL,

I didnt understand tile extents very well, but it seems like an interesting approach, Im gonna try it (after re-reading your post several times, hehehe), a couple of questions tho...

When I have the tile extent for the tree you said in your example, do I modify the tile''s extents to clip it against the edge of the screen? cause currently my sprite engine does the clipping, not the map engine...

another question, I assume that I calculate the extents during the map loading and put them into the lookup table at that time, wouldnt this stop me from making changes to the map (say for example, the tree gets blown up by a low level deatomizer) would the lookup table need to be recalculated?

or maybe I just need a more detailed explanation.. hehehe

thanks man, later!


Luis Sempe
visual@guate.net
http://www.geocities.com/SiliconValley/6276