This week and the previous one have been great! We’ve managed to fix most of the game engine’s core features. In the forthcoming days we’ll start working on some simple gameplay implementations.
The development library we use for Haunted Light is SFML (Simple and Fast Multimedia Library). Well the name speaks for itself but it’s a simple-to-use framework to communicate with all the Input and Output devices of the computer. Without a development library you’d have to write code that directly sends instructions to e.g. the Processor or Graphics Card.
Onto the main topic of this post. I’m going to write about the structure of the “sprite-manager”. The sprite-manager takes care of loading all the images to the game, which in turn gets made into sprites. Sprites consists of a texture (i.e. image) and a rectangle shape which determines what part of the texture to show when in-game. The reason you’d have a sprite-manager is to make sure that the same textures isn’t loaded multiple times and take up an unnecessary amount of RAM.
I’ll go through what the functions and arguments are and then explain the details of how everything works. So that you easier can follow the next paragraph.
Here’s all the functions and member variables of the sprite-manager object that’s conveniently called; “SpriteManager”.
- void addTexture()
- sf::Texture* getTexture()
- sf::Sprite* addSprite()
- void Cleanup()
- std::string m_dir
- std::map<std::string,sf::Texture> m_textures
How it all works
- The function “SpriteManager()“, is the first function that’s called when our SpriteManager object gets created. It have one string argument; “_dir“, which defines the directory of all the images to load. This location is then saved in the m_dir member variable.
- The next funtion “addTexture()“, loads the supplied image and creates it into a texture which you can use later. It also only have a single argument which defines the filename of the image in question.
- “getTexture()” is used to get access to the stored textures, which is specified by the argument “_name“. This one is primarily used in cases where you’d want to set or change properties of the texture. E.g. if you’d want to change the interpolation method used when displaying the texture.
- Next up is the “addSprite()” function. This is where the sprite-manager returns a sprite to the object that requests it. In comparison to the previous functions, it have a total number of five arguments. The first one acts as a keyword which the sprite-manager uses to find the texture that’s stored in the member variable; “m_textures“. The second (_x) and third (_y) argument defines what x and y coordinates of the texture to use. And the last two arguments (_w and _h) defines, you guessed it, the width and height of the rectangle which crops out the new texture.
- Last but definitely not least is the “Cleanup()” function, which quite literally cleans up before the sprite-manager gets destroyed. Either by quitting the current state, e.g. go from the game-state to the menu-state. Or by quitting the game. This function goes through all the textures which are stored inside the member variable; “m_textures” and deletes them.
Now you know roughly how our sprite-manager works and next week I’ll be covering another part of our development!
~Per “Gimmic” Johansson