HTML and CSS Reference
In-Depth Information
Not exactly rocket science, and that's the point. This function must be cheap to be worth it, as it will be used as
many times as there are live particles in the pool.
Discarding objects as soon as you can is the easiest way to save performance. It is far more time-consuming to
optimize a physics engine so that it becomes 10 percent faster than it is to discard 10 percent of your objects. By not
discarding objects, you are not only making the game perform worse than it should, but also wasting user CPU time
and battery life.
Culling for Rendering
Chances are that, the demo notwithstanding, you may actually care about offscreen objects. For instance, if your hero
were moving freely on a large map, you wouldn't discard enemies as soon as they were offscreen. In this case, you
would use boundaries that are much larger than the viewable area.
If your game boundaries are larger than the viewable area (see Figure
3-5
), you should check during the
rendering loop that each object is effectively in the viewable area before trying to render it. Otherwise, you will
overdraw (draw more than necessary) and end up burning precious graphics processing unit (GPU) power.
Figure 3-5.
The world may be larger than what the player sees
Note that if you use a framework, you should check to see if it does the culling for you.
Warming Up the Virtual Machine
Chances are that your game is far more complex than the demo. And, it's likely that on mobile, you get a rather choppy
frame rate during the first 10s-30s, while your code is being optimized on the fly.
Because those first seconds are crucial to the player experience, it's important to get a smooth frame rate from
the start. Otherwise, your game will be perceived as slow and laggy, and the player may very well quit and never
come back.
