Difference between revisions of "Gameplay synchronization"
From MSX Game Library
Line 1: | Line 1: | ||
+ | Synchronization | ||
+ | |||
Synchronization is the process that allows a code loop to run at a constant intended speed. | Synchronization is the process that allows a code loop to run at a constant intended speed. | ||
Line 12: | Line 14: | ||
So if your gameplay loop is not synchronized, the time the CPU needs to execute it will change the movement speed. And it's where code branching (‘if’ statement) makes it even worse because code execution time becomes not constant (for example a part of the code may be executed only if a collision is detected). | So if your gameplay loop is not synchronized, the time the CPU needs to execute it will change the movement speed. And it's where code branching (‘if’ statement) makes it even worse because code execution time becomes not constant (for example a part of the code may be executed only if a collision is detected). | ||
− | Synchronizing your code ensures your gameplay loop always executes at the same given speed. | + | Synchronizing your code ensures your gameplay loop always executes at the same given speed. #1 |
== How do I synchronize? == | == How do I synchronize? == | ||
− | ... | + | Synchronization simply consists of waiting for a signal sent at a constant frequency before executing an iteration of the gameplay loop. The MSX has a system (interruption) that allows a peripheral device to send signals to the CPU, which the program can then receive. |
+ | |||
+ | The most commonly used signal for gameplay synchronization is the one sent by the graphics processor (VDP) at the end of displaying an image on the screen: the "v-blank" (start of the vertical blanking interval). This signal is sent every 1/60th of a second (for NTSC machines at 60 Hz) or every 1/50th of a second for PAL/SECAM machines at 50 Hz. | ||
+ | |||
+ | If your gameplay loop waits for the v-blank signal, your code will always be executed at the same time interval regardless of its actual duration. This means that all movements you make will result in a constant speed. |
Revision as of 14:02, 16 October 2025
Synchronization
Synchronization is the process that allows a code loop to run at a constant intended speed.
Why should I synchronize?
Let's say you want a monster to move from left to right of the screen. You create a loop where you increment a X coordinate and set a sprite position accordingly. If you test your program, the monster will move at a constant speed… So why the hell should I bother with synchronization?
Let's continue the example: Now you add a simple code to handle player movement (with some input reading and basic physics and collision). You launch your program again and the first thing you notice is the monster moves slower than before. And when you start moving your character it's even worse: Not only does the monster move even slower, but their speed is no longer constant.
Why?
The speed is a quantity of movement over time. So, for a constant quantity of movement (eg. +1 pixel to the right) the longer the time, the slower the speed.
So if your gameplay loop is not synchronized, the time the CPU needs to execute it will change the movement speed. And it's where code branching (‘if’ statement) makes it even worse because code execution time becomes not constant (for example a part of the code may be executed only if a collision is detected).
Synchronizing your code ensures your gameplay loop always executes at the same given speed. #1
How do I synchronize?
Synchronization simply consists of waiting for a signal sent at a constant frequency before executing an iteration of the gameplay loop. The MSX has a system (interruption) that allows a peripheral device to send signals to the CPU, which the program can then receive.
The most commonly used signal for gameplay synchronization is the one sent by the graphics processor (VDP) at the end of displaying an image on the screen: the "v-blank" (start of the vertical blanking interval). This signal is sent every 1/60th of a second (for NTSC machines at 60 Hz) or every 1/50th of a second for PAL/SECAM machines at 50 Hz.
If your gameplay loop waits for the v-blank signal, your code will always be executed at the same time interval regardless of its actual duration. This means that all movements you make will result in a constant speed.