triple buffering

[ervin]

Hi folks.

I'm experimenting with using the extra RAM in the 6128, and I've read a few posts about triple buffering.
I'm trying to figure out how I could benefit from triple buffering, and how to use it sensibly.
Can anyone offer some tips?
Or share any experiences with triple buffering?

Thanks!

[andycadley]

The problem with triple buffering on the CPC comes down to only having 64K of usable video memory and each screen display being 16K. If you can reduce the usable area down to 8K, I guess it would be more manageable although your screen would be tiny. 

There's also the issue of finding a convenient memory arrangement that lets you access the right pages of RAM both for reading graphics data and writing to whichever target screen you need at the time. The 128K banking arrangements aren't terribly helpful in that regards, especially given you need suitable locations for things like the interrupt handler and stack too.

It's probably less of an issue in a GX/Plus cartridge game, because you can bank ROM much more flexibly and RAM is a lot more plentiful when you don't need to store code in it. You also have the benefit of the screen split hardware which could help having to replicate things like a status bar in different banks.

[McArti0]

You can create a system with software only for addresses 4000-7FFF based on jumps to other banks and use the C0, C4-7 settings
Then you have access to 3 buffers bank 0,2,3. Of course the firmware doesn't work. Mode 2 interrupts, common stack in each bank.

[McArti0]

But we've already talked about this:
https://www.cpcwiki.eu/forum/index.php?msg=235994

Maybe tell us where you have doubts?

[ervin]

Thanks for your replies guys.
I've managed to make stuff work with different ram banking schemes (thanks to the discussions in that other thread), but I haven't tried any code related to triple buffering yet.
I'm still at the thinking and understanding stage.
Assuming I can figure out how to do it, what would the benefit be?

@abalore has mentioned that triple buffering was one of the most important optimisations in Alcon.
https://www.cpcwiki.eu/forum/programming/hyperdrive-development/msg223048/#msg223048

And @arnoldemu mentioned a long time ago that by using triple buffering, there is no need to sync with frame flyback.
https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/60hz-cpc/msg4856/#msg4856

@gerald mentioned something similar here.
https://www.cpcwiki.eu/forum/programming/frame-locking/msg65913/#msg65913

Is that potentially the main benefit?
Would I do something like the following?

buffer A is currently visible.
buffer B has been drawn completely.
buffer C is being drawn to.

When buffer C is finished, buffer A goes to the back of the queue, buffer B is made visible, and buffer C moves up. Buffer A then starts getting drawn to.

buffer B is currently visible.
buffer C has been drawn completely.
buffer A is being drawn to.

When buffer A is finished, buffer B goes to the back of the queue, buffer C is made visible, and buffer A moves up. Buffer B then starts getting drawn to.

etc.

Is that the idea?

[GUNHED]

You can create a system with software only for addresses 4000-7FFF based on jumps to other banks and use the C0, C4-7 settings
Then you have access to 3 buffers bank 0,2,3. Of course the firmware doesn't work. Mode 2 interrupts, common stack in each bank.

A common stack in each bank? So you copy the stack when switching the bank? Won't work in real life. Better use a own stack for every bank.

[GUNHED]

The whole triple buffer thing makes only sense if the time needed to draw one frame has a huge variation from screen to screen.

Or you use two screens and one buffer for the background. Makes only sense if you work with static pictures - w/o scrolling.

[McArti0]

A common stack in each bank? So you copy the stack when switching the bank?

NO. I understand this as no change SP when changing banks.

[andycadley]

You can create a system with software only for addresses 4000-7FFF based on jumps to other banks and use the C0, C4-7 settings
Then you have access to 3 buffers bank 0,2,3. Of course the firmware doesn't work. Mode 2 interrupts, common stack in each bank.

A common stack in each bank? So you copy the stack when switching the bank? Won't work in real life. Better use a own stack for every bank.

It can work as long as you're very, very confident about when bank switching will occur. It's pretty much a sure fire route to shooting yourself in the foot unless you're enormously careful though.

[andycadley]

The goal of triple buffering is never to be stalled waiting for a display flip to happen (unless rendering is so quick it takes less than a frame).

It's a more complex setup though and RAM gets very tight. More often than not you can get away with just double buffering if you can keep rendering time down to a minimum. It's really only when it takes between a frame and a frame and a half to render on average that you're really likely to be winning.

[abalore]

I don't know if you would call it triple buffering. Alcon had two switching visible buffers and a third invisible buffer which holds a clean copy of the background. That makes the sprite erasing in the other two buffers a lot faster.

[andycadley]

Yeah, that's not triple buffering, it's just using three buffers. The clean background doesn't even need to be accessible to the Gate Array, which simplifies things even further.

[McArti0]

I've read it and I understand it now. Triple buffering is needed when most frames are rendered in 20ms and suddenly some frames are slightly longer or even one frame is twice as long.
Then it's time to render it because we have two left to display. Of course we have a lag of 40ms.

On CPC with the 512kB extension, we can create even a quadruple buffer with the C1+, C3+ settings because we have many banks instead of bank7 and we see the entire 64kB as vram.

[djaybee]

So, yeah, triple-buffering has the advantage that you (OP) describe.

You can work with a single buffer, but it's got to remain clean enough at all times (e.g. constantly working incrementally).

You can work with a double buffer, where one buffer (front) is clean and gets displayed while you work into the other buffer (back). If you can't immediately page-flip (either because the hardware doesn't support it or because you don't want the tearing to be visible), you end up in a situation where you've finished drawing into your back buffer and you have to wait for the page-flip before you can draw your next frame.

With a triple buffer, you have 2 back buffers, once you're done drawing into one of them, you can immediately start drawing into the other one, so you have a higher frame rate compared to double-buffer since you can always start drawing (with the understanding that there'll be some judder). This is not useful if you can draw faster than your refresh rate, but that's a good problem to have.

Double- and Triple-buffering on the CPC face 3 main challenges:
-all the buffers must fit in the low 64kB of RAM.
-if you use the firmware, it carves out 2 chunks of RAM in those low 64kB.
-bank mapping only has a small number of configurations, which creates constraints. E.g. using banks 1 and 3 for buffers feels natural, until you realize that no memory config maps bank 1 at the same time as banks 4-6, so you can't directly copy graphics from banks 4-6 to bank 1.

For triple-buffering specifically, the smaller your screen, the easier things get. Smaller than 5.33kB, 3 buffers fit in 1 banks, that's very easy. Smaller than 8kB, 3 buffers fit in 2 non-contiguous banks, that's very feasible and very similar to regular double-buffering. Smaller than 10.66kB, 3 buffers fit in 2 contiguous banks. Up to 16kB, 3 buffers need 3 banks, Beyond that and up to 21.33kB, you need all 4 banks and madness lies ahead (you can do resolutions like 312x280, 352x248, 376x232 in mode 1).

[ervin]

Thanks everyone for your replies.
All of that gives me a lot to think about.