When to WAIT?

Hello,

I’ve been thinking about vsync, and wondering when would be the best time to call WAIT.
I’m guessing that the best time to call WAIT is immediately before doing any graphics drawing, like this:

REPEAT
 PROCcontrol
 PROCmove_player
 WAIT
 CLS
 PROCdraw_background
 PROCdraw_player
 PROCswitch_shadow_buffer
UNTILFALSE

My reasoning is that, as I understand it, when WAIT returns, you’ll be at about the beginning of the period of time where nothing is changing on the screen (because the CRT beam is moving back to the start position, or something)

I haven’t given this much thought until today. Previously, I had done it like this:

REPEAT
 PROCcontrol
 PROCmove_player
 CLS
 PROCdraw_background
 PROCdraw_player
 PROCswitch_shadow_buffer
 WAIT
UNTILFALSE

But I’m not at all sure if my new way of doing it (as of today) is actually better than how I was doing it before, or if I understand any of this correctly. So I’d like to ask, when’s the best time to WAIT, and is my understanding correct, or incorrect?

- Patrick

My reasoning is that, as I understand it, when WAIT returns, you’ll be at about the beginning of the period of time where nothing is changing on the screen (because the CRT beam is moving back to the start position, or something)

Traditionally, yes. The WAIT should go before the CLS so the screen redraw happens while there is nothing being output to the monitor.
However VSync is faked on the Pi and, for boring technical reasons the sync event happens about halfway down the screen.
Triple-buffered graphics are recommended.

By the way – how do you draw the screen? If you can completely fill it with rectangles and such, the CLS might be superfluous? Just an idea…

The traditional way of using 2 screen banks works as follow: when you switch screen banks, the display driver is most likely still in the middle of sending the old display bank data to the monitor and will only use the new bank afterwards, i.e. once a VSync occurred. As you switched between 2 banks, that old display bank is your new bank so if you write to the screen before the VSync occurred, the data being sent to the monitor could be already contain parts of your new frame. Hence the rule, switch the screen as soon as you’ve finished updating your screen and don’t start updating your screen before a VSync occurred.

Now as Rick’s mentioned, on the Pi we don’t receive the VSync info from the monitor, but for the sake of convenience a fake VSync is generated at the same rate as the refresh rate of the monitor. Since its a fake, you will run into the issue mentioned above, so the work around is to use an extra screen bank screen bank (thus triple buffering) so that when you change screen banks the new bank you will write to is not the old display bank, but the bank used before that one.

Note regarding VSync, the simplest way is to use WAIT (or SWI OS_Byte,19) but if you are too slow, i.e. your processing is slower than the refresh rate of the monitor, there is no need wait for the next VSync if one already occurred during your processing, so you can make you can instead use SWI OS_Byte,176 just after the bank switching to note down the VSync count and instead of a WAIT loop on SWI OS_Byte,176 till the count changes.

Rick, André,
Thanks for the information. From now on I’ll try to use triple buffering.

By the way – how do you draw the screen? If you can completely fill it with rectangles and such, the CLS might be superfluous? Just an idea…

Good point, and in my example I wrote ‘PROCdraw_background’ which would suggest that the whole screen is getting written over. Although in most of the simple BASIC games I’ve written so far, the screen hasn’t been completely filled, so I’ve still needed to use CLS.