Reply 20 of 22, by Scali
wrote:Talking about framegrabber and forgiveness of inexact timing. Do you think it was for that reason than in some video game, sprites where blinking on the screen ? I dont think old sega master or nintendo system where really double buffered capable and some games would had blinking sprites on the ntsc version, for instance, but not on the pal or the whatever version there is in japan because of vsync inaccuracy ?
Well, it is related to timing, but a different kind of timing.
The timing I'm talking about is the timing of the video signal itself, and the display being able to sync to the signal and decode the pixels and colour information properly.
If your display can sync to the signal in general, then by defintion the sprites will work correctly as well.
The reason why sprites sometimes flicker can be because they are enabled/disabled at the wrong time. Sometimes this is because of timing bugs in the code (eg, if you write a game for a PAL system, and try to use the same timing for an NTSC system, it will not work).
Sometimes it is done deliberately because they want to display more sprites than what the system is capable of. A classic example is Pacman for Atari VCS. They could only show 2 sprites at the same time, but the game requires 5 sprites in total: Pacman and 4 ghosts.
So, they multiplexed the ghosts. Pacman is shown on every frame, and every 1st frame, the first ghost is displayed, every 2nd frame, the second ghost is displayed etc.
In general, you can 'reuse' sprites multiple times on screen, and the main limit is the number of scanlines active on the same scanline.
This is especially obvious with shoot-em-up games. Often they show large waves of enemies, many more than what the system can display. Eg, you have a system with 8 sprites in total, and you show 20 enemies, bullets, and your own aircraft. All is fine, until you get more than 8 sprites that line up horizontally. Then the sprites will start to flicker, because only 8 can be shown.