So lets say I successfully poll the CRU for vsync and eventually detect one...
In my code, I now know Ive hit a 1/60th of a second NTSC (or 1/50th second, PAL) event. I believe thats it.
This vsync event now triggers a decision tree gate which runs a specific segment of code. Perhaps I decide to do three things when vsync is detected:
A. Update the player character position.
B. Hit my roll-ur-own sound routine to update background music.
C. Refresh the game scoreboard.
How do I know theres enough time to do these things between vsyncs?
You don't. We'll get to that.
How many tasks may I tie to the vsync event?
Well, if any number of tasks takes too much time, one may split things, reorder etc.
Im thinking about counting vsyncs and enabling sub-events based on determined vsync counts...
Absolutely. You would only update the score if the score has changed.
Am I attempting to process as much as I can before the CRT beam travels from bottom right to top left on the screen?
Yes. It's actually at the visible bottom just outside the 192 scanlines that makes up the display (24 character lines 32 columns), and just until the display starts again (the 24 lines, a good number of scanlines down the screen). Also called the vertical gap.
The vertical gap/blank goes on right after this (the 24th line is blank)
and stops just before the colors (1st line of characters)
I guess what Im looking for is a few tips and techniques on the topic.
Have a black background. This shows up in the border of the display. Change the background color to red when the vsync is detected. Change the background color to whatever for each of your major tasks (3-12). Change background back to black when all is done.
You will see some nervous color bands representing the time each task takes.
The idea of using the vsync signal as a constant interval timer is manageable.
If I try to do too much after a vsync is detected Im thinking Ill miss the next vsync, and my interval timer will then become inconsistent and result in stuttering video/audio?
Yes, that is a concern, but try it out. Obviously one has to update the display right after the vsync (to avoid screen tearing), and game logic, positions, collisions etc. can be done after the update of display (effectively displaying what was computed in the previous frame). Depending on the use of buffers, updating the display can be rather fast (like switching the screen image table).
Hope this helps.
Edited by sometimes99er, Wed Feb 27, 2019 4:39 PM.