Haunted Light – SpriteManager

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.

Haunted Light - SpriteManager

A screencapture of the class; “SpriteManager” which this post will cover.

Here’s all the functions and member variables of the sprite-manager object that’s conveniently called; “SpriteManager”.

Functions

  • SpriteManager()
  • void addTexture()
  • sf::Texture* getTexture()
  • sf::Sprite* addSprite()
  • void Cleanup()

Member Variables

  • 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

Advertisements

2 thoughts on “Haunted Light – SpriteManager

  1. Well, can’t find much here I would have done different, looks great. I return my class AnimatedSprite instead of sf::Sprite, and take the name for the .txt-file where the textures name, size, number of frames, duration for each frame and such is written. I guess you have another class to get this information, like an AnimatedSpriteManager.
    The one function I don’t have in my SpriteManager is getTexture(). I think I understand why you have it, but it would change all the sprites that use that texture, which might not be what you want sometimes. What do you think about also having a function that copies a texture and returns pointer to the new texture, like sf::Texture* copyTexture(const std::string& _name)? Then you could change the new texture without having to worry about other sprites having their textures changed.
    You have a good structure on your blog-post and the class, functions and variables are well named and I can see with a glance what everything is doing. I almost wish you had done something stupid or wrong so I could write about it, but can’t find anything that is wrong or things to change.
    Good work with the blog and the code.

  2. I’m supposed to comment on you blogpost (initially Calle’s, but couldn’t find his blog), and give feedback on what is good and what could be improved.

    I like that you show us some of the code, but a visual example of the result of the code (a prototype where this was implemented for example) would be nice (it was only a minimum requirement of one picture, you were free to use more than one).

    AddTexture() only take one argument, but what happens under-the-hood? How does it add a texture from only the filename? Or is AddTexture() the equivalent of LoadImage() and AddSprite() only defines what part of the texture to use? The function names doesn’t seem right, you’re supposed to know what the function is doing just by looking at the name, return-type and what arguments it takes in, they shouldn’t clash with each other; AddSprite() returns a sprite and doesn’t take a sprite for argument. That sounds more like a GetSprite() or CreateSprite() function.
    Naming policys is mainly for the programmers convenience, since the code most likely will be closed-source in the future, but it would be wise to consider the naming in the future.

    I see that the map use objects of a texture, not pointers to a texture, while GetTexture() returns a pointer, is this intended? Cleanup() (and custom deconstructors) is only needed if you deal with pointers, the member variables in this class is properly deleted at the end of the object’s lifetime since none of them are/contain a pointer. It’s currently redundant.

    The naming and Cleanup() aside, I like that you describe your code, keep that up.

    I’m a little unsure as to what your position/role in the group are from reading this post, I can clearly see you are a programmer, but do you have any other role? Producer? Lead Design? Lead Programmer?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s