Info on Scrolling Tile Based Games

[thewiz]

Hi Folks,

After seeing Bobs Virus game, I thought I would ask how people would code a routine that displays tiles that allow for scrolling.

For example, tile sizes are 4 x 4 chars, screen size is 24 x 24 chars. Allow for 256 titles.

Any takers or existing code?

Cheers

[bobs]

The usual way is to store the map as a list of tiles and the draw routine finds the tile at the top-left of the display and then draws each tile required to fill the playing area.

VIRUS does this, but backwards, in that it actually starts drawing from the bottom-right, and works left then up to the top-left of the screen, so I can use different size tiles (the backgrounds & objects are 2x2, but the player & enemies are 3x3).

If you want to scroll in steps smaller than the size of a tile - character scrolling for example - you have a decision to make; You can either clip each tile which overlaps the edges of the playing area so only the visible portions of the tile are drawn, or you can use a back-buffer which is larger than the playing area, blit all the tiles to that without clipping and just copy the correct area of the buffer to the display. The clipping takes time, but so does the overdraw of the back-buffer method, along with blitting of the back-buffer and obviously the additional memory overhead. In VIRUS, due to the different tile sizes, the clipping calculations were using a lot of code, and I also wanted a flicker-free update, and so it uses a back-buffer.

(is that the kind of thing you were looking for?)

[thewiz]

Thanks Bobs, that was the kind of thing I am after. I can see how using a back buffer would work.

All that would be left is a check when the player gets close to an edge.

Cheers

[bobs]

Thanks Bobs, that was the kind of thing I am after. I can see how using a back buffer would work.

All that would be left is a check when the player gets close to an edge.

Cheers

Back-buffers are very handy, but take extra time & memory, so you need to decide on a case-by-case basis whether it is worth using one, or just a good clipping draw routine instead. With the 81 having a character-mapped display buffer, a back-buffer for the entire screen isn't too large - 768 bytes - and copying from the buffer to the screen can be done pretty quickly using LDI or LDIR. On a pixel-mapped display, such as the Spectrum, the amount of data is much larger (6912 bytes), taking a lot longer to copy, so a dirty-rectangle system for only copying regions which have updated can be employed to speed things up, but with a character-mapped display the dirty-buffer system can take longer to utilise than copying the whole screen!

The tile data needs to be thought about as well, as it might be better to store it as position + tile index, rather than a rectangular buffer of tile indices - especially if your map contains a lot of empty space.