How did classic side scrollers execute synchronized events and animation triggers?

I always wondered about the Super Mario series on Snes. I think this was done in the Z80 assembly. But since there was no real-time clock, how did they cope with all these timed, animated events with the assembly and without a real-time clock?

thanks

+6
assembly graphics
source share
4 answers

An important concept to consider is VSync speed. So often, the electron gun in the TV (or, equivalently in modern TVs) finishes drawing the screen and slowly moves up to the top of the screen.

Since this happens at a constant speed (60 times per second in NTSC, 50 in PAL), most games use this as their timer with a code that is roughly equivalent to this:

void main() { while(true) { updateGame(); updateSprites(); waitForVSync(); } } 

Obviously, this is greatly simplified, but what happens. Some games were so complex that they took up too much time and missed the VSync period. In this case, they will wait for the second VSync and, thus, will work with 30 (/ 25) FPS.

Sometimes you will notice a slowdown in NES games (for example). This is when the workload is so heavy that it lacks several VSync periods in a single action frame.

But yes, the bottom line is how time worked on older consoles (in fact, even many new consoles and computer games use the same system, not just old consoles!)

+5
source share

A very common method used on older equipment was to rely on the same time equipment used to display graphics. Old equipment literally transmitted data from its graphic port (composite video or, more often, RF), reading the pixel value from memory and putting it on the port along with some "synchronizing" signals to control the scanning electron gun in television.

A good bit is that the vertical synchronization signal, which makes the gun turn from the bottom of the screen to the top, is usually connected to hardware interrupts on the console processor, and at this very moment, which occurs exactly 29.97 times per second (almost 30 frames per second), occurs at a time when data is not transmitted at all in the video, because it is required that the beam "leans back" to the top of the screen. Changes in video memory will flicker at this time!

+2
source share

Games, as now, usually start a fixed time cycle (see Mike Caron's answer). Originally it was mainly for convenience; your rendering was synchronized with the refresh rate of the display in any case, in order to avoid a gap, it can also start all processing in time for one frame.

Currently, most games still advance time in discrete steps that are multiples of some base speed, usually 50/60 Hz or about 100 Hz - some titles still have VSync-based time, but most of them just use regular timers for this now. Currently, we use fixed time parameters for several reasons: firstly, games usually have at least some physical modeling, and it is very difficult to get physical modeling with variable time parameters stably - especially in real-time applications such as games where you cannot easily throw more processing power at it using more accurate integration methods, etc. Secondly, if you have any kind of networked network mode, you need to make sure that the game remains synchronous for all players. It is almost impossible to control (and debug) if everyone is on a different timer and processes events at a different speed. Forcing everyone to use a common time step, the task simplifies management by several orders of magnitude, because you can safely assume that two players who start in the same state and receive the same input will still be in the same state after 5 seconds, even if the players are watching on different things or have different machines, all of which affect the actual frame rate at which the game works (and, therefore, also the speed with which the game can process events).

+2
source share

Z80 supports a number of hardware interrupts - perhaps one of them was connected to a periodic timer (for example, every 10 ms). In some game consoles there was a time associated with updating the TV scan, so it was possibly connected. I don’t know SNES, so I’m thinking about how other modern systems work.

wikipedia says that SNES was a 16-bit system, so it was not a Z80, but 8 bits. He actually says it was 65c816

http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System

(the link above is talking about video sync interrupts, so I'm probably on the right lines, assuming that you are correct about real-time clocks)

0
source share

All Articles