3 ms·

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

• ddingus 8y ago
  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