Tilemap Scrolling Demos

[aros-sg]

Originally Posted by MickGyver

please post any improvements / optimisations if at all possible.

Who knows. Theoretically it may be possible to get rid of annoying copper split, if ones uses three buffers (buffer 3 is clean buffer for restoring bobs).

333333
333333
111111
111111
111111
111111

111111
111111
222222
222222
222222
222222

222222
222222
333333
333333
333333
333333

Two of the buffers are always consecutive in memory (the third most of the time not) = no copper split needed.


Each frame when the back buffer got cleaned (restore bob gfx trash) it should look like the restore buffer so if bad luck strikes and the back buffer (which will be display buffer in next frame) would become the one to cross the single wrap line at the bottom of memory it could swap role with the current restore buffer.

[ross]

Originally Posted by aros-sg

Theoretically it may be possible to get rid of annoying copper split, if ones uses three buffers (buffer 3 is clean buffer for restoring bobs).

Two of the buffers are always consecutive in memory (the third most of the time not) = no copper split needed.

Each frame when the back buffer got cleaned (restore bob gfx trash) it should look like the restore buffer so if bad luck strikes and the back buffer (which will be display buffer in next frame) would become the one to cross the single wrap line at the bottom of memory it could swap role with the current restore buffer.

You caught my attention, it's a good idea
(actually I didn't read the whole thread, so I might not have the whole issue).

The only drawback is that if you use triple buffering is mandatory to update two of it (in scrolling regards) in each frame.
But if your engine already expects it normally, then nothing changes.
This preclude you some tricks, like the partial only cookie cut on big objects (because you are forced to a full backgroud cleanup every frame).

This can be an intriguing exercise

[Marle]

Originally Posted by MickGyver

A few days ago I had eye surgery so to occupy my mind the day before, I was fighting to get the 8-way scrolling algorithm by aros-sg to work and I succeeded! There might be some bugs still, but according to my tests it seems to work. The example uses interleaved bitmaps. I have avoided using MOD, divisions and multiplications wherever possible.

Wow thank you for so kindly posting this hard work, I have been hoping to start on an idea for a game for so long, but the 8 way scrolling has defeated my intellect (of which there isn't much haha) so maybe I may stand a fighting chance now

Thanks again.

[earok]

I'm trying to optimise my engine further as it's starting to choke with a few Bobs running around on screen. One idea that came up from discussions with Alpine9000 is to precalculate addresses to blit from and to - not exactly memory efficient, but saves Blitz from having to work out the addresses of a tile and the destination on the map every time a tile needs to be drawn. So I've implemented that in my engine.

First up, the blitter functions. These are hard coded specifically for 32 color 16x16 interleaved tiles (won't work on non-interleaved tiles, as you'll need to do several blits)

#ScreenModulo = #XFillSize*2-2
#TileSize = 64*80+1

Statement PrepareTileBlit{}
    Move.l #$09f00000,$DFF040 ;A->D copy, no shifts, ascending mode
    Move.l #$ffffffff,$DFF044 ;no masking of first/last word
    Move.w $0,$DFF064 ;A modulo=bytes to skip between lines
    Move.w #ScreenModulo,$DFF066 ;d modulo=bytes to skip between screen lines
End Statement

Statement DoTileBlit{source.l,dest.l}
    Move.l D0,$DFF050 ;Source
    Move.l D1,$DFF054 ;Destination
    Move.w #TileSize,$DFF058 ;Start Blit
End Statement

PrepareTileBlit only has to be run once at the start of your tile rendering process (you'll need to re-run it if you use a regular Blit function). After that, with DoTileBlit, simply feed your source and destination addresses.

Here's my code for calculating those.

*Tile\Source = Address + (*Tile\Source * (2 * 16 * 5))
;2 bytes across * height * depth

*Tile\Destination = (x*2) + (y Mod #YFillSize) * (#XFillSize * 2 * 16 * 5) 
;Tiles across * wordsize of 2 * height of 16 * depth of 5

Address is the address of the tilemap. I haven't added a bitmap address on to the Destination as I'm using a double buffer system (so I'll still need to add that address whenever I blit tiles).

[E-Penguin]

 *Tile\Source = Address + (*Tile\Source * (2 * 16 * 5))

Tile source is defined as a multiple of tile source? Is this something that gets evaluated as the map scrolls?

[earok]

Originally Posted by E-Penguin

 *Tile\Source = Address + (*Tile\Source * (2 * 16 * 5))

Tile source is defined as a multiple of tile source? Is this something that gets evaluated as the map scrolls?

Sorry, ugh - for clarity, I should have put

*Tile\Source = Address + (TileID * (2 * 16 * 5))

The reason I set the value to a multiple of itself is the original value is set by the map creation tool. I simply take that value and change it to be the literal memory location of the tile graphic.

It only gets evaluated once (when the map is loaded).

[E-Penguin]

Ah, that makes sense. Thanks for the clarification!