Well, except that to prevent tearing, you have to draw just behind the monitor's refresh line (well, at least when we had cathodic monitors). And that required an awful lot of super accurate timing (on PC at least)

Or, draw just ahead of it. I think that is a matter of perspective.

The idea being to have the graphics there for the display device to render them. Once it has done that, they are no longer needed, until next frame.

Doing that actually needs only a small buffer, but is timing intense, also compute and write demanding.

If one has a sprite capability, and or a larger, or full frame buffer, just write from the top down, starting at the beginning of blank from the previous frame.

Drawing behind works simplest assuming a full frame buffer, so the new follows the old once the display has pushed those pixels to eyeballs.

Another scheme, used in DEFENDER and ROBOTRON, among many others, is to divide the screen into top and bottom regions. Or more, depending.

Render into the one the display is not using. This is more coarse, but can be less complex to arrange.

The timing depends. If one is working scanline by scanline, yeah. Need accurate timing.

When working with screen regions, or just a blanking period, the requirement is relaxed. Really, all you need is to understand the speed of the object draw engine and a quick sort to insure the initial part of the frame is drawn in time for the display.

Screen regions also work well when the renderer cannot get a full frame drawn every display frame. There, a priority system will draw what is needed, delay that which is not.

I enjoy doing ths kind of programming. A full double buffer is a luxury :D

Cool stuff! Perhaps one could have even written some routines to kinda abstract that?

An "engine" could take care of synchronizing rendering with reading, but the difficult part is application specific: ensuring that rendering fits in the specified number of CPU cycles.

For many cases, one ends up writing a little kernel that manages the display.

Break the display into whatever elements make sense, and insure timing is all sorted. Run tests to get maximums.

Once it is running, the rest feeds it with pointers to objects, and lists or the objects get generated dynamically at display time.

Various schemes apply to overtime requirements. In old Williams arcade games, one method was to just move baddies to a non displayed region. Aggresive players would fire off a ton of shots to trigger this.

Another is to delay animation or movement.

The kernel can do that, but it gets more complex and slow. Dumber kernels are faster. Higher level code can manage what the kernel has to do.

One thing is smart to do though, and that is to have the display kernel fail gracefully. Use hardware timers, or loop counters to prevent overdraw and the loss of display sync normally associated with that condition.

there's a bit of discussion about isometric tile rendering nonsense, although not specific to vsync, in David Brevik's diablo postmortem https://www.youtube.com/watch?v=VscdPA6sUkc

along with a whole lot of other fascinating stuff

That was a great video. Enjoyable talk.

At one point, they were drawing tiles, the walls associated with them, objects, etc...

Moving objects would end up between tiles and the sprite would be cut off by a different tile draw. Worse, there was no sort order that worked for all cases. They ended up creating, what the speaker called "an ai" to move the object away from the draw conflict, get it all drawn, then move the player back, just ahead of the actual motion...

In hindsight, they could have just decoupled the walls from the tiles and it all could have been a lot simpler!