Next up in my notes on DragonRuby: render targets!
Weirdly, the documentation on DragonRuby’s render targets is limited to example code. Personally, I prefer prose when I am trying to learn… so here we are!
In DragonRuby, a render target is like an infinite canvas you can render as many regular sprites onto as you want, then manipulate the whole thing as if it is one sprite.
This is especially good for things like tiled backgrounds that are built once and do not change.
Let’s take an example.
Clouds!
Let’s start off very simple and build up.
First, here’s all the code to render a single 250x250 pixel image to the screen:
1 2 3 4 5 6 7 8 9 10 11 |
|
More Clouds
Cool, but I’d like to fill the whole window with clouds, so I’m going to tile them.
The code below makes a 6x3 grid of the cloud image.
(In DragonRuby, the screen is always 1280x720. Our grid is 1500x750 but I’m not trying to be too precise with the numbers here.)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Ah… blue clouds. Nice.
On every tick, the code builds up an array of 18 sprites (images) and renders it out to the screen.
(There are a number of ways to make this more efficient - check out the previous posts in this series for different ways to “cache” the sprite information.)
Render Targets
But in this post we are talking about render targets - which is a way of rendering a bunch of sprites (or any other renderable thing) just once, and then treating the whole group of sprites as a single sprite. This is faster, simpler, and enables some neat effects.
The code only needs minor changes to switch the cloud grid to using a render target instead:
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 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
For convenience, the code above moves the creation of the cloud grid and the render target into a helper method which gets called on the first tick of the game.
args.render_target(:clouds)
automatically creates a new render target named :clouds
if it does not already exist. Then we can render things to it just as if it were args.outputs
.
Interestingly, render targets do not seem to have an innate width or height. In order to avoid unintentional scaling, you will need to “know” how big the render target is. In this case, we know it is a 6x3 grid of 250x250 images, so the size is fairly straightforward. I left the math in to make it clearer.
Finally, we reference the render target similarly to an image file, but pass in the name of the render target as the :path
instead of an actual file path.
Static Sprites, Too!
As explored in a different post, we can use static_sprites
to “render” the sprite once.
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 27 28 29 30 31 32 33 34 35 36 37 38 |
|
And now we can move the clouds around just by changing the attributes on the render target.
Adding a little bit of code at the end of tick
:
1
|
|
(The calculation and numbers aren’t really important here, I just fiddled around until something looked decent.)
Oh hey! Those extra pixels on the sides of the cloud grid actually came in handy.
What Else?
Remember, the entire render target is like one sprite now. That means all the regular sprite attributes (e.g. color, size, blending, flipping, rotation) can be applied to the entire thing at once.
Wait, did you say rotation?
Sure, let’s make ourselves dizzy.
1
|
|
Okay, that’s as deep as we’ll go on render targets in this post!