OK, I know how to grab map-data from an array and draw it to the screen. the problem I am having is that I want to scroll the screen in all directions, and have realised that I need to calculate offsets for the map and screen. I would like the map to be pixel perfect positioned so that I can draw the map from any given pixel (x,y) within any given tile. However, I am very confused when trying to do this and have failed in all my attempts so far. Can anyone explain this in ENGLISH (no C/C++ code please) or point me to a good reference doc / URL ? I would prefer a plain English explanation in laymans terms, as I`d like to actually understand the concepts, rather than be told to cut and paste some code.... Thanks in advance... r!K rik@ram-productions.net ICQ #74183404

if you''re familiar with directx this should be easy. draw your entire map first in an offscreen surface. its like a temporary buffer where you store all your graphical data. then just calculate for the location of your screen and blt the portion you need. for example, if your screen resolution is onl 640x480 and your entire map is 1024x768, just copy a portion of your actual map which has a dimension of 640x480 and blt it in your primary surface, instead drawing the entire screen all over again. i''ve tried this a couple of times and it works. i managed to scroll my entire map very smoothly

I have had this same question the other day, and came up with just about the same answer as pcvsee.

The only problem with this that I see is what if you map was many mnay thousands of pixels.. that is quite a chunk of memory to hold in the back buffer.

here was my solution ( because my map was extremely large). I had a surface that was exactly 1 tile bigger on each side. This was my back buffer. I drew the tiles to that back buffer and then blitted it to the primary. If I would reblit it depending on where the character went. now if the characters went out of the one tile boundary, I redrew the back buffer with a new tile boundary.

That way instead of holding the entire map in memory I only held a small piece at a Time. Check out the following:

size of Tile = 16 pixels

size of map = 500 tiles

primary surface = 800X600 by 16 Bpp (128,000 pixels on x, 96,000 on y)

back buffer surface 832X632

say that the Primary SUrface Tiles is 2, and the back buffer Surface tiles is 1:

111111111111111111
122222222222222221
122222222222222221
122222222222222221
122222222222222221
122222222222222221
122222222222222221
111111111111111111

that represents memory. then what happen is when the player pressed a key, the primary surface would move in that direction a pixel at a time. then If the player had moved more than >= 32 pixels in say, x direction, a new set of tiles would be blitted to the back buffer on the X side. Same thing for the y.

Smooth quick scrolling, only taking a small amount of memory.

If this isnt clear let me know


to Code, or Not To Code

Edited by - cxi2 on November 22, 2000 2:15:25 PM

cxi2, how does that work unless the card supports wide surfaces?

Having a wide system memory surface (which is supported on all cards) and moving a screenfull of data isn''t particully fast at the best of times.

I''d like to know how you did it otherwise, ''coz it would make something I''m doing a bit easier.

-Jamie


Waassaap!!

Hey, since you know how to draw make the tile arraay and display it on the screen, can you send me the code for that?
I want to look it over and learn how to do it.
Thanks...

eklar_1@hotmail.com

I know you asked for no C++ code, but here is my example function for using any blt, it is not meant for tiles, so it would be rather slow having to run this calculation for each tile. My former 2D engine used it to keep things from being partially blt''ed off of the screen.

It wouldn''t be slow if you only did it with the tiles on the edges of the screen, the ones that may go off the sides of the surface. Good luck .

  // dRect is the destination// sRect is the rectangle from the source// rRect is the ''size'' of the destination (0,0,width,height)bool Environment_R002100::buildMODsRect(RECT &dRect, RECT &sRect, RECT rRect) {  if(dRect.right<rRect.left) {    return false;  } else if(dRect.left<rRect.left) {    sRect.left += rRect.left-dRect.left;    dRect.left = rRect.left;  }  if(dRect.bottom<rRect.top) {    return false;  } else if(dRect.top<rRect.top) {    sRect.top += rRect.top-dRect.top;    dRect.top = rRect.top;  }  if(dRect.left>rRect.right) {    return false;  } else if(dRect.right>rRect.right) {    sRect.right -= dRect.right-rRect.right;    dRect.right = rRect.right;  }  if(dRect.top>rRect.bottom) {    return false;  } else if(dRect.bottom>rRect.bottom) {    sRect.bottom -= dRect.bottom-rRect.bottom;    dRect.bottom = rRect.bottom;  }  return true;}  

http://www.gdarchive.net/druidgames/

What I did for my game is actually to draw from the back buffer onto itself. My game is an RPG, and most of the time the tiles need to be redrawn when the player''s character moves, so that the character stays at the center of the screen. So most of the screen doesn''t actually need to be redrawn, it just needs to be moved a little bit. DirectX allows you to use FastBlt() from a surface onto itself, and even guarantees (past a certain version, I forget which - 5.0 maybe?) that the blit won''t corrupt the image by writing to an area before reading that area.

So if I need to redraw the screen, offset by (4, 8) pixels, I first blt the back buffer to itself, offset by that much, and then mark the small rectangles around the edges that need to be redrawn. Everything else doesn''t change, which saves a lot of double blitting and transparent blitting of game sprites. It was tricky getting all this set up, but I''ve been very happy with the results.