Reading from a backbuffer on the Raspberry Pi

Jon Abbott, in ‘General→Raspberry Pi 4’ wrote: “Any self-respecting game dev would use triple buffering for anything targeted at a Pi, to ensure no matter what machine it runs on, it’s updating a backbuffer.”

Here I refer to a ‘hardware’ backbuffer whose base address is returned by OS_ReadVduVariables 148.

It turns out that any self-respecting game dev using his own custom graphics routines, especially those that read a lot of RGB pixel data from the background (e.g. alpha blenders, alpha channel-based collision detection, basically any read-modify-write graphics op.), would not want to read directly from a ‘hardware’ backbuffer (on a Raspberry Pi) if he cares about performance because that’s several times slower than reading from a private buffer or a RISC OS Sprite. I discovered this only quite recently. IIRC, writing to a buffer/Sprite is also a bit faster than writing directly, but not by much. So my strategy will probably be to render everything to a private buffer (or Sprite) – which may involve reads as well as writes, and then ‘blit’ the final image to a backbuffer thereby avoiding any reads from that backbuffer.

David.
—

Definitely try to avoid touching screen memory where you can, I believe caching is disabled on GPU RAM (on the Pi, others may differ) so it’s probably really slow.

With ADFFS I implemented a GraphicsV driver that enables caching and handles the cleaning at VSync. Not something I’d advocate doing though, unless you’re really hitting GPU memory.