Shadow memory on Pi Harder

In order to smooth-out an animation I’ve used a shadow memory command. To make it run slower I’ve inserted a delay of 5/100 second which makes the animation stutter for about 1 second before continuing. On more complex shapes stuttering becomes a lot worse. Example works well on my R-Pi 2B computer. I’ve had a look at shadow memory in the past but couldn’t make sense of it. Examples of how to do this properly would be welcome.

MODE 1920,1080,32
ORIGIN 1920,1080
S1$=1$=“2”
FOR ang = 0 TO 10*PI STEP PI/100
GCOL RND,RND,RND OSCLI"FX112,“+S1$:OSCLI”FX113,"+S2$:SWAP S1$,S2$:WAIT:IF INKEY:CLS
ELLIPSE FILL 0,0,500,300,ang
NEXT ang

Sorry about program formatting. I’ve posted correct coding here…

http://www.riscosbasic.uk/problems/Anim_ellipse.zip

On the PI, the VSyncs are fake ones, of correct frequency but not linked to the display.
This means that with double buffering you end up writing to the bank that the hardware is still displaying.
The work around is to use triple buffering to ensure that there is an intermediate bank the writing bank and the display bank:
write to 1 and display 3 → write to 2 and display 1 → write to 3 and display 2 → …

Plus, 5cs is quite a bit, 20fps, only marginally faster than Super8… ;)

If your animation isn’t too complex, a 2cs delay (50Hz) will look better. But don’t just bung in a 2cs delay. Check the time before waiting for VSync, then check it again afterwards and work out how long to wait catering for the VSync (in other words, 1cs if the ticker has changed, 2cs if not). This ought to even out at “about 50 FPS” with VSync to keep the display stable.

Thanks for your replies. Didn’t know that double buffering fails to work on the R-Pi. Triple buffering seems to be the way to go for more complex animations. I’ll investigate coding for the VSync timing as per your suggestion Rick.

VirtualRPC also does not have Vsync. I found I got great results by writing to a sprite and blitting that to the actual screen. This has the advantage of also working within a window of course.

Memory bandwidth on actual silicon may be very different though.

On the PI, the VSyncs are fake ones

They used to be fake, but I’m sure they’re now real.

The issue on the Pi is the delay time on the message being sent from the GraphicsV driver via the firmware (which processes them at VSync) to the GPU. In the case of a frame buffer swap its delayed enough to cause the OS to be out of sync with the hardware.

Double-buffering does work, but you have to invert the buffers so you’re always writing to the visible buffer – which is actually now the back-buffer if you’re swapping at the monitor refresh rate. Triple buffering is preferred as it avoids having to check explicitly for the Pi, but it doesn’t change the fact the visible display isnt the one selected, which is always 1 VSync behind.

…if that makes sense!

Palette swapping is also delayed – it used to be two VSync behind but after some tweaks by Jeffrey I believe it’s now performed at the next VSync, so matches the frame-swap delay.