7800Basic timing

[+Karl G]

I'm wondering about some of the specifics of timing with 7800Basic games. From what I understand, the game code runs both offscreen, and during the visible screen. I'm wondering where in the frame one is after a drawscreen, however. Past the visible screen? Before it? Where in the frame does 7800Basic put its housekeeping code?

 

If one wanted to know if the current code being run was being executed during the visible screen or offscreen, is there a way to determine this programmatically?

 

From what I understand, when there's too much code in one frame, it redraws the same frame again, causing a visual slowdown, correct? Are there any other side-effects of this other than the visible slowdown, and perhaps not being able to keep an accurate frame count?

[RevEng]

Everything I'm about to talk about is with reference to regular 7800basic operation vs double-buffering. With double buffering enabled your game code and screen updates happen whenever they happen, without regard to the timing within the TV frame.

 

After a "drawscreen", your code begins to run right near the top of the visible frame. I say "near" because there's a few things that happen first - some interrupt handling, including any "topscreenroutine".

 

Your game logic will continue to run throughout the reset of the visible frame, until you either:

• run out of visible screen time, at which point it will begin to execute out of overscan.
• execute your first plot* statement, at which point 7800basic will wait until overscan, to avoid glitches that could happen if you update the display while it's being drawn.
• call another drawscreen, which will cause the CPU to wait until the top of the next frame.

 

The above stuff is why my performance recommendations say to do all of your game logic right after drawscreen, and leave any plot* commands to happen right before the drawscreen. Since plot* commands run during overscan cpu time, which is more limited than visible cpu time, it's best to reduce any game logic around your plot* commands.

 

If you wanted to know if some of your code was running during the visible frame, you could change the background color before and after the code in question. The height of the painted rectangle tells you how much of the visible frame the code is taking up. If you see the painted rectangle running off the screen and overlapping itself at the top, your routine is using more than a frame.

 

If your game logic runs too long and the next visible screen happens before your "drawscreen", generally you just see a repeat of the last frame. In theory, because you may not have finished plotting some objects, those objects may be glitched or missing. In practise, an occasional dropped frame doesn't usually result in visible glitching, due to the previous frame likely being very similar to the past one. If this overage is more than occasional, than the chance of object glitching goes up, but even here it just depends on how often things move in your game and where the plot* statements actually happen.

 

If your game does a frame count via the main loop, then indeed your count would be off with regard to TV frames, though accurate with regard to game-logic "frames". If your game does a frame count via interrupt, then your count would be accurate with regard to TV frames, and off with regard to game-logic "frames". Which accuracy you value more is up to you.

 

There shouldn't be any other effects of an extra frame, other than your game moving slower if they happen regularly. Music, sound effects, and other time critical stuff happen via interrupt.

 

I probably value 60hz updates more than most people, so I worked pretty hard at getting Salvo to run within budget in most circumstances. Part of that was painting the routines with the background color, and ensuring everything fit within the frame. Certain game logic routines are spread across different frames, or run only on certain frames, to accomplish that.

 

When game objects need to move quickly, true 60hz update makes the game motion appear smooth, silky, and alive, in a way that you usually only experience on the 2600.

 

[+Karl G]

Okay, thank you for the detailed explanation. One last question: is there any way to wait for overscan for any processing that I would want to do offscreen without having to e.g. do a dummy plot command? I'm aware of "userinterrupt", but am also aware that I should be careful to avoid operations that use temp variables there.

[RevEng]

You're welcome. It sounds like using the drawwait command during your main loop is what you're after.

 

It should be noted that on many TVs you will be able to see background color changes in overscan, depending on your screenheight. If you needed to avoid that, you'd need to do something with userinterrupt instead, since that runs right as vblank starts up.