The Heads Up Display, early stage [WIP]

So this past week I’ve been working on the Heads Up Display, the HUD for our space shooter project Fancy Mansion. Well, the name is about to change to something else once we come up with a fitting name.

I went through some iterations when working on this task, since I couldn’t really decide on one solution over the other in the beginning until I remembered what a second year student told me about RenderTextures.

Now, remember, at the moment, all the screenshots you’re about to see, is a work in progress, and I will post an update on the HUD in its final state later down the line.
This is a picture of the HUD atm. Note the fine programmer art in the bottom right corner, beautiful.

Inventory                                                                                                Score                                                                                                      Hand slot

So the HUD shows what the player has in her inventory, how much score she has and what the avatar is currently holding in its hands (the Hand slot). When the player is located at the drop off zone the items in the inventory light up, showing the player that she is within the drop off zone and that she can empty the inventory.

From this:

To this:

Later when the proper art is in place, a picture of the Q-button on the keyboard will be visible as well, which when pressed empties the inventory, and increases the score. Some animations and sound effects will play as well. Yeah, feedback! It’s good for you.
Either way, the important thing is that you understand that all of the different things in the HUD are separate sprites, and some of which I want to change from time to time. Eventually, I will add some numbers on the screen depending on what each item in the inventory is worth (in score), more highlights, animations and key indications.

The problem is that there will be a lot of sprites in the HUD, each that take up some RAM and CPU power. Each sprite must stay in its correct location on the screen when moving the camera, so I need to move all the sprites and things might get messy.

So instead of having lots of sprites, I let the program draw each and every sprite to one big sprite and then draw this one big sprite to the screen:

From this                   ————–>          To this

Instead of using a regular texture, SFML has a thing called a sf::RenderTexture. This is really easy use and I did it like this:
A temporary sprite is loaded with one specific texture, say the inventory texture. The position of the temporary sprite is set to a given location and then the temporary sprite is drawn to the RenderTexture. After that is done, a new texture is loaded to the temporary sprite, positioning, size and the croping of the texture is corrected to match the new texture and the same temporary sprite is drawn to the RenderTexture, however it now has another texture!
I have if-statements controlling what should and should not be drawn to the RenderTexture, eg. sometimes I don’t want to display a certain thing or when the player is at the drop-off zone things will be highlighted, there for a different part of the texture needs to be drawn. Since we keep the highlighted version and non highlighted version in the same texture we need to know when to draw the highlighted and vice versa. It is easier to have all textures for an item in one .png file instead of having two different .png files for each item. It saves the computer some RAM and CPU power as well.
This whole process is iterated through several times until the whole HUD is drawn to the RenderTexture. Then a new sprite holding the RenderTexture is positioned to follow the camera and the sprite is drawn to the screen. The RenderTexture is cleared with transparent color after it has been displayed to the screen, meaning this process is done once every loop.

Using and drawing to RenderTextures is practical since I don’t have to create 30+ different sprites that all take its fair share of RAM and CPU power. The GPU does not have to draw 30+  different sprites to the screen for the HUD, it only draws one sprite. This is however more practical when dealing with huge amount of sprites, like in a tile map system that can contain several thousand sprites. This HUD consisting of 30+ sprites wont really have an impact on the performance of the game, however, it is super cool and practical.
I actually might do this for our tile map system as well, if I have time for it…

About Johan Holmér

2014  Programming

View all posts by Johan Holmér →