The post ended by hinting at a more efficient way to render outputs instead of adding them to e.g.
args.outputs.sprites each tick.
This post explores the world of “static outputs”!
First of all, we should address the most confusing part of all this.
“Static” does not mean the images don’t move or change. Instead, it means that render “queue” is not cleared after every tick.
Normally, one would load up the queue each tick, like this:
1 2 3 4 5 6 7 8 9 10
But this is kind of wasteful. We are creating a new hash table each tick (60 ticks/second) and then throwing it away. Also each tick we are filling up the
args.outputs.solids queue and then emptying it.
Instead, why not create the hash table once, load up the queue once, and then re-use them?
That’s the idea of static outputs!
There are static versions for each rendered type:
Here’s an example with comments explaining what the code is doing. This “game” simply moves a square back and forth across the screen. This is the entire program!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
The resulting output looks like:
This example introduces
args.state. This is basically a persistent bag you can throw anything into. (For Rubyists - this is like OpenStruct.)
direction are not special, they are just variables we are defining. We use
||= to initialize them because we only want to set the values on the first tick.
This example illustrates the point from above - every tick it creates a new square and adds it to the queue. The queue is emptied out and then the code starts all over again.
Seems wasteful, right?
Caching the Objects
First thing I think of is - “why not create the square once, then just update the object each tick? Does that work?” Yes! It does.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
In this code, we create the
square only once and then store it in
Instead of having a separate
x variable, the code updates the
x property on the square directly.
This is better, but we are still updating
args.outputs.solids each tick.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
In this code, we use the fact that the first
0 to add the
args.outputs.static_solids just once. It will continue to be rendered on each tick.
Intuitively, since the code is doing less, it should be faster. But does it really make a difference?
It depends on your game, how much it’s doing per tick, how many sprites you are rendering, and what platform/hardware it’s running on.
The examples above? Not going to see any difference using
In these examples, you can play with the number of “stars” rendered to see different performance. On my ancient laptop, I do not see a performance difference until around 3,000 stars.
Your mileage may vary, though!
Should I Always Use the Static Versions?
It depends! Probably not?
If your code mainly manipulates the same objects around the screen and always renders them in the same order, then using the
static_ approach might be simpler and faster.
But in many cases it might be easier to simply set up the render queues each tick, especially if the objects rendered or their ordering change regularly. Otherwise, managing the state of the rendering queues can become cumbersome. (We haven’t even talked about clearing the static queues, for example.)
Some of this comes down to personal preference and how you would like to structure your code. But hopefully this post has helped explain how to use the
args.outputs.static_* methods in your game!