Background store/restore question

[Brick Nash]

Hi folks,

I've been tinkering away at a little game demo and it's going well, but I've hit a problem which seems to get getting bigger, so just want some advice before I commit to a technique.

I'm using the Blitter to draw the game's moving objects, but I'm doing it using modular type slices to construct an animation frame - the offsets of which are read off of a table and added to the main X/Y position. It works really well and I have stuff animating, but since I'm using the blitter on a single playfield, the background store & restore is getting very tricky to do with all these little pieces, and my drawing routine is just ballooning due to it (plus I'm still an assembly noob, so there's that as well). I was previously copying and restoring a big rectangle from the background for each object, but that wasn't very flexible.

I'm wondering if it might just be easier to copy and restore the whole (visible) 320x208 screen each frame, and that would restore the background for every screen object in one go without having to tediously do it piece by piece for every moving object? The problem with that is that it's a scrolling screen (twice the size of the visible screen, using a column blit on both sides for tiles, and then a pointer reset when the end is reached).

It would certainly save a LOT of hassle just refreshing the whole screen's background instead of saving/restoring a whole load of little bits, and I know the blitter is capable of copying very large rectangles, but if there's going to be a massive performance hit (I'm doing it on ECS A600) then I'll need to think of something else (I thought about using duel playfield mode to simulate a Megadrive style sprite layer, but I forgot that splits the bitplanes between each playfield).

Is this screen copy method maybe something worth pursuing?

Thanks!

[mcgeezer]

Solving that hassle will result in much better performance of your game, restoring the entire screen will pretty much take up the entire video frame.

You can restore faster using a few methods.

1) have a pristine copy of the background at all times and restore using a combination of the saved blit offset, modulo and blit size. (This is the method i normally use)

2) use tile based restores, mark which tiles are dirty and simply restore them. This saves you chip ram over option 1

3) use the method you mentioned and save/blit/restore ... the problem is its slow and uses memory

4) redraw the entire screen which is very slow, but depends how your game is made up action wise.

Geezer

[Brick Nash]

Originally Posted by mcgeezer

Solving that hassle will result in much better performance of your game, restoring the entire screen will pretty much take up the entire video frame.

You can restore faster using a few methods.

1) have a pristine copy of the background at all times and restore using a combination of the saved blit offset, modulo and blit size. (This is the method i normally use)

2) use tile based restores, mark which tiles are dirty and simply restore them. This saves you chip ram over option 1

3) use the method you mentioned and save/blit/restore ... the problem is its slow and uses memory

4) redraw the entire screen which is very slow, but depends how your game is made up action wise.

Geezer

Thanks for the reply.

The tile restore from Option 2 seems interesting, as I'm holding a tile sheet in memory anyway for the backgrounds.

Option 1 seems like the way to go though, but wouldn't that require saving whatever the screen is displaying at that moment ? (I'm using a HW scroll, so the background would change with the visible screen).

Thanks again!

[meynaf]

Do you have moving objects everywhere on the screen ?
If you have large areas that don't change often, you could restore only the part that encompasses all moving objects (finding this out is just coordinate comparisons to get min/max). It would already be faster than restoring the whole screen.

[Brick Nash]

Originally Posted by meynaf

Do you have moving objects everywhere on the screen ?
If you have large areas that don't change often, you could restore only the part that encompasses all moving objects (finding this out is just coordinate comparisons to get min/max). It would already be faster than restoring the whole screen.

I was previously just working out what the overall rectangle size of each animation frame was and just copying/restoring that for each object in one go, but they were pretty big, and trying to keep a steady origin point with changing frame sizes was a nightmare.

I think I may need to work out how to have a buffer(s) which can change size on the fly, but I don't know how to do that yet.

I think McGeezer's tile-restore method sound like it would work. I saw something similar on the Amstrad a few years ago, but that was just for static screen, so I may need to think about this.

I wish the Amiga (or at least the ECS) had a separate objects layer to blit to, but I guess this is all part of the challenge.

[DanScott]

Originally Posted by Brick Nash

I wish the Amiga (or at least the ECS) had a separate objects layer to blit to, but I guess this is all part of the challenge.

You can effectively do that using dual playfield (one playfield for background and 2nd playfield for moving bobs)... That way you probably *could* just clear the whole screen (using a combination of blitter clear and movem's with the CPU concurrently).

The ideal situation for you though, would probably be either:

• The "dirty tile" replacement method (could use 32x32 tiles for decreased CPU use, at the expense of a little more blitter use)
  
• Calculating the bounds of each "collection" of small bobs that make up each object, and using that for restore

[mcgeezer]

Originally Posted by Brick Nash

Thanks for the reply.

Option 1 seems like the way to go though, but wouldn't that require saving whatever the screen is displaying at that moment ? (I'm using a HW scroll, so the background would change with the visible screen).

Thanks again!

No, you don't need to save what's already there. When you render the screen backgrounds you do it on three screens instead of two, so you always have that third screen available to restore thus negating the need to save.

I think you mentioned above as well that you blit a whole wall of tiles... in scrolling games and depending on your speed you only need to blit a small number of tiles. So for example, if your screen height was 256 and your scroll speed of bplcon1 was 1 then you only need to blit 1 16x16 tile for each position updated in bplcon1.

If you give more info on what you are doing we can probably give more clearer answers to best solve the problem.

[Brick Nash]

Originally Posted by DanScott

You can effectively do that using dual playfield (one playfield for background and 2nd playfield for moving bobs)... That way you probably *could* just clear the whole screen (using a combination of blitter clear and movem's with the CPU concurrently).

The ideal situation for you though, would probably be either:

• The "dirty tile" replacement method (could use 32x32 tiles for decreased CPU use, at the expense of a little more blitter use)
  
• Calculating the bounds of each "collection" of small bobs that make up each object, and using that for restore

I think the dirty tile method is what I'm going to go for. It seems like the perfect compromise. I already have a 16 colour palette and shared graphics linked to that so I'd likely need to spend time redoing them for a duel playfield setup with the 7 colours each. Just replacing the tiles seems much easier!

Originally Posted by mcgeezer

No, you don't need to save what's already there. When you render the screen backgrounds you do it on three screens instead of two, so you always have that third screen available to restore thus negating the need to save.

I think you mentioned above as well that you blit a whole wall of tiles... in scrolling games and depending on your speed you only need to blit a small number of tiles. So for example, if your screen height was 256 and your scroll speed of bplcon1 was 1 then you only need to blit 1 16x16 tile for each position updated in bplcon1.

If you give more info on what you are doing we can probably give more clearer answers to best solve the problem.

I think I get you now. A screen to show, a screen to draw on, and a screen that just draws a copy of the background?

For the backgrounds, I'm just moving through a map, and blitting one column of 16x16 tiles (same column) at either side of the visible screen in hidden areas. That way I can reset the pointers and still continue to seamlessly scroll through the map.

It's scrolling 2 pixels at a time (Poking increments or decrements of $22 to BPLCON1's scroll value until a pointer reset) and this is based on whether the X-pos of the player is past a certain point of the screen (push scroll).

I'm really interested in the tile replacer as I that seems to be the most effective, so I think I'll go with that.

[mcgeezer]

Originally Posted by Brick Nash

For the backgrounds, I'm just moving through a map, and blitting one column of 16x16 tiles (same column) at either side of the visible screen in hidden areas. That way I can reset the pointers and still continue to seamlessly scroll through the map.

It's scrolling 2 pixels at a time (Poking increments or decrements of $22 to BPLCON1's scroll value until a pointer reset) and this is based on whether the X-pos of the player is past a certain point of the screen (push scroll).

.

You'll get a big performance boost by only blitting 2 tiles per frame instead of an entire column. It is very simple to do. Make your screen 1 word wider, and for testing open up diwstrt/diwstop so you can see the tiles being copied in per frame as bplcon1 updates the two tiles.... entirely up to you though.

[Brick Nash]

Originally Posted by mcgeezer

You'll get a big performance boost by only blitting 2 tiles per frame instead of an entire column. It is very simple to do. Make your screen 1 word wider, and for testing open up diwstrt/diwstop so you can see the tiles being copied in per frame as bplcon1 updates the two tiles.... entirely up to you though.

Do you mean for every increment/decrement of BPLCON1 I would blit 1 new tile into both the columns, instead of blitting the two entire column in one go when the pointers are updated?

I guess that would be easy enough to change, and if there's a performance boost then that would be great.

[mcgeezer]

Originally Posted by Brick Nash

Do you mean for every increment/decrement of BPLCON1 I would blit 1 new tile into both the columns, instead of blitting the two entire column in one go when the pointers are updated?

I guess that would be easy enough to change, and if there's a performance boost then that would be great.

That's exactly what I mean.

Yep - big performance boost because you are doing much less blits.

[phx]

Originally Posted by Brick Nash

For the backgrounds, I'm just moving through a map, and blitting one column of 16x16 tiles (same column) at either side of the visible screen in hidden areas. That way I can reset the pointers and still continue to seamlessly scroll through the map.

If your map is not endless you can just add mapwidth - displaywidth words to the size of your bitmap. So you can continue scrolling without having to blit a second column or reset the pointers. Halves your total number of blits again.

[Brick Nash]

Originally Posted by mcgeezer

That's exactly what I mean.

Yep - big performance boost because you are doing much less blits.

Great advice! Thanks. Sorry, for sounding thick, I just wanted to be sure.

Originally Posted by phx

If your map is not endless you can just add mapwidth - displaywidth words to the size of your bitmap. So you can continue scrolling without having to blit a second column or reset the pointers. Halves your total number of blits again.

Do you mean just make the size of the total area width the same size as the map (minus the visible part?) and just scroll through it? That would save a lot of recalculating stuff if there's no bpl pointers to reset.

At the moment, my total screen width is 704 and the visible part is 320. As I say, I'm just resetting to the starting point when I hit the right edge of the total area (but staying within the map position).

My map's width is 1280 (80 words), so it's exactly 4 times the size of the visible screen, although I may want to vary the size later on (but none would be endless).

[phx]

Originally Posted by Brick Nash

Do you mean just make the size of the total area width the same size as the map (minus the visible part?) and just scroll through it?

No. That would waste a lot of Chip RAM. Just add the total number of words you would have to move the BPLxPT when scrolling to the rightmost position on the map.

At the moment, my total screen width is 704 and the visible part is 320.

Then you can save a lot of Chip RAM. Three extra columns are needed (368). And the extra words for scrolling through the map.

As I say, I'm just resetting to the starting point when I hit the right edge of the total area (but staying within the map position).

Not needed.

My map's width is 1280 (80 words)

Which means you have to allocate a bitmap for 368x256(?) pixels plus 60 (80-20) words. For four planes this would be: 23*2*256*4+60*2 = 47104 bytes.
The 60 additional words allow you to continue scrolling to the right border.

[Brick Nash]

Originally Posted by phx

Which means you have to allocate a bitmap for 368x256(?) pixels plus 60 (80-20) words. For four planes this would be: 23*2*256*4+60*2 = 47104 bytes.
The 60 additional words allow you to continue scrolling to the right border.

Ok, I think I get the jist of what you mean (sorry, I'm still quite a noob at this). So it's basically just one screen with two edges for the blits and one extra for the scroll?

Are there any examples anywhere I could maybe have a look at for a reference?

[mcgeezer]

Originally Posted by Brick Nash

Ok, I think I get the jist of what you mean (sorry, I'm still quite a noob at this). So it's basically just one screen with two edges for the blits and one extra for the scroll?

Are there any examples anywhere I could maybe have a look at for a reference?

Boot up Apidya with winuae with the action replay cart and have a look how the screen scrolls to the right... exactly the same technique.

[phx]

Originally Posted by Brick Nash

Ok, I think I get the jist of what you mean (sorry, I'm still quite a noob at this). So it's basically just one screen with two edges for the blits and one extra for the scroll?

Exactly! And a few extra words on the bottom to be able to scroll the whole map width.

Are there any examples anywhere I could maybe have a look at for a reference?

There is always Georg Steger's legendary Scrolling Trick on Aminet, which everybody who wants to implement proper scrolling should have read by now.
Don't remember the exact path, as Aminet is down again, but it is definitely

ScrollingTrick.lha

.

[Grumpa]

In case it's not available at the moment, ScrollingTrick.lha is in the zone for you...

[Brick Nash]

Excellent!

Thanks for the help chaps.

[Brick Nash]

Originally Posted by Grumpa

In case it's not available at the moment, ScrollingTrick.lha is in the zone for you...

Thanks mate! Got it now, so will have a look at it today

I gave the 1 screen technique that phx suggested a try though, and it seemed to work straight off the bat. No resetting bitplane pointers and it scrolls nicely to the end of the map. I didn't add any extra words though, I just changed the BM width to 368 and it was fine.