HTML and CSS Reference
In-Depth Information
The processing budget dictates how much processing time is available until the next frame is called. You need to
consider that if your game is running and displaying graphics at 60 FPS, you have 16.67 ms to handle the following:
Pixels being painted on the screen
Calling the next tick on the physics engine
Updating variables, game state, and other objects
If for some reason you're unable to process all those things in that amount of time, you will be skipping a frame,
which could incur jerkiness or slowdowns in the animations. Which is why, for example, some developers choose to
display graphics at 30 FPS. Instead of having just 16.67 ms, they have 33.3 ms to take care of everything, leaving some
leeway to handle more demanding scenes or calculations. Others may choose to call the update loop at 120 FPS to
have increased precision in physics calculations, but to display graphics at a constant 30 FPS.
So, the question arises, what happens if you want to be able to display graphics at a constant 60 FPS with no
stuttering or slowdowns? That is, you want to be able to process all these things in less than 16.67 ms, leaving some
leeway for when your optimization efforts are not enough.
The truth is that optimization of update loops has been, and will most likely always be, a hot topic of discussion.
There will always be some sort of limitation, restriction, or problem that you'll need to work out to make your games
run better, or that allows you to create richer and more exciting experiences for your users. There is always room to
make things faster, and sometimes the gains can be enough to make us say, “Wow, now there's enough processing
power to add this new feature I've wanted to add” or “Hey, this can now run on my smartphone!” So in my experience,
they are always worth pursuing.
In the past, game developers had to work with even tougher constraints. Not only were processors slower, but
graphics and storage capabilities were extremely limited as well, which is why they had to come up with incredibly
clever “performance hacks” to make their games better. Competition has been, and will most likely be in years to
come, fierce. For this reason, I propose that you study how “old” games were made.
High-Performance Update Loops
Unlike in other languages such as C or C++, creating a recursive function without an exit condition will create a
UI-blocking infinite loop, exhausting the computer's memory; therefore, it's necessary to use another method.
In the past, there were two methods that allowed you to accomplish this: setTimeout and setInterval . Both
functions work similarly, by accepting two parameters: a function or string with the code that you want to execute,
and another with the delay (in milliseconds). For example, two possible implementations of update loops using
JavaScript follow. The first one, shown in Listing 8-1, uses setTimeout .
Listing 8-1. Using setTimeout
// Define the amount of times the loop is going to get called
var maxCount = 3;
// Call the function for the first time
update(0);
function update(current) {
// Execute the function 3 times
if (current < maxCount) {
console.log('this is a test!');
setTimeout(function() {
 
Search WWH ::




Custom Search