Page 4. Microsoft XNA's Frame Dependency vs Independency
Prerequisites
Before jumping into this project, it's important to make sure you've got the general framework covered. If you're entirely new to Microsoft XNA and MonoGame, it's recommended to start with our introductory project. Please follow the walkthrough provided on Page 1: Microsoft XNA's Hello World w/ MonoGame.
List of Prerequisites:
A working installation of Visual Studio
MonoGame framework installed
.xnb of your desired font (Review Page 1 to make one)
What is Frame Dependency?
If you've been tinkering around with your game and realized that the speed of your game objects is changing as you adjust the frame rate, you may have encountered a common issue known as "Frame Dependency." Frame dependency occurs when the speed, position, or any attribute of a game object is directly tied to the number of frames rendered per second. This means that the more frames you have in a second, the faster your game object will move, and vice versa. Such a design can be problematic as it introduces inconsistency in gameplay across different hardware setups.
Why is it a Problem?
Imagine playing a racing game where you seem to go faster on a more powerful machine simply because the game runs at a higher frame rate. That wouldn't be fair, would it? Such frame-dependent behavior can break the gaming experience, make certain aspects of the game uncontrollable, and even introduce bugs that are hard to trace.
Mitigating Frame Dependency
To create a consistent gaming experience, we want to aim to make our game logic frame-independent. This means decoupling the speed of game objects from the frame rate. Here’s how you can do it:
Use Elapsed Time
Instead of updating your game objects' attributes per frame, update them according to the amount of time that has passed since the last frame. This can be done using the gameTime.ElapsedGameTime.TotalSeconds
property, which gives you the time elapsed since the last frame in seconds.
Why the Multiplication by a Constant?
The constant value (like 200
in the example) provides you with the flexibility to adjust the speed to a level that feels right for your game. This constant can be fine-tuned based on your specific requirements.
How was the color updated?
newG
is a byte variable that will hold the updated green component of a color.100 * elapsed
multiplies a constant (100) by the time in seconds (elapsed
) since the last frame was rendered. This ensures the change is consistent over real-world time.color.G + 100 * elapsed
adds this time-adjusted increment to the current value ofcolor.G
.% 256
ensures that the value wraps around to stay within the byte range (0-255).(byte)
casts the resultant value back to a byte.color.G = newG
finally updates theColor.G
property with the new byte value.
Full Code
Last updated