This is part of an ongoing series where we write a complete 2D game engine in C++ and SFML. A new tutorial is released every Monday. You can find the complete list of tutorials here and download the source code from the projects GitHub page.
As games become more complex, the issue of how to manage a games assets and resources is only becoming more difficult; which is why, even though we do not have many resources at the moment, it is a good idea to start the groundwork on what will become a robust and generic (it can handle any resource we throw at it) resource management system.
A good resource manager will be efficient and allow us to easily re-use our assets without having to re-allocate memory for previously used resources. For example, we do not want to create copies of the same texture, when we can just create the one and pass the reference to any system that needs it.
In the context of this article, a resource can include sprites, audio files, and fonts; but they can also be text, XML, and JSON data files. It is pretty much anything that is not code.
Our resource manager will handle instantiation, allocation, and retrieval (using a resource id) of our games assets. It will also be generic so that we can easily instantiate different resource managers that are responsible for allocating different resources.
I attempt to avoid using the word ‘manager’ in my class names (you’ve probably seen many examples of GameManagers, LevelManagers, etc.) for many of the reasons outlined here. With that in mind, I’ll call our resource manager ResourceAllocator.hpp. This provides a bit more information about what the class actually does.
The class makes use of template functions. As the methods are templates they will need to be created in the header file. We’ll create the Add function first. This will be responsible for loading the resource and adding it to our resource allocator.
1. We store the file path as well as the resource so we can use it as a unique identifier. Two assets with the same file path are assumed to be the same asset. This prevents us from creating the same assets twice.
2. As we call LoadFromFile on our new resource, it is important that any asset we use has this method implemented. SFML resources (sf::Texture, sf::Font etc.) have this method by default so we do not need to worry about writing our own implementation for them.
The Add method is relatively simple. It provides the bare bones of what we require from a resource manager. We will change things in future tutorials but for now, it works and does everything we need it to. It is worth noting that it returns an integer, this is the id of the resource. If we want to retrieve or remove a resource we will need this id.
Now that we can add resources lets create the Remove method.
This iterates over our resource collection and if it finds the resource with the associated id it is removed from the collection.
Adding and removing won’t do us any good if we cannot retrieve our resources, so let’s create the Get method. We will also create a way of telling if an allocator has a resource with the specified id.
A shared_ptr is returned to a resource (if present).
With the resource allocator complete for now, we can change our existing code base to make use of it, starting with our sprite component.
- We currently need to manually pass the reference to the resource allocator to the component; in future, we can look at different ways of accomplishing this.
Make sure you delete the existing reference to the texture as we will retrieve this from our new resource allocator. We’ll keep the reference to the sprite as this is a lightweight structure. You can find out more about SFML sprites and textures here.
We now set our sprites texture by retrieving a smart pointer to a texture from our resource allocator. As the texture is on the stack the local reference is removed at the end of the function. Each sprite component no longer needs to store there own texture as our resource allocator handles that for us. This prevents us from allocating duplicate textures as we create more sprite components.
Now that our sprite component requires a texture allocator, any class that instantiates the component will need to pass through that class. Therefore our game and splash screen scene will need to either create or have a reference to the allocator. As they both need the reference, and it’s likely that future scenes will also require access to a texture allocator, we can create the texture allocator in the game class and pass it through the constructor to our scenes.
Now we need to set the texture allocator in our OnCreateMethod.
We’ll also pass a resource allocator to the SceneSplashScreen.
1. We assume that this is the first time we will be using the logo so this scene will add it to the texture allocator.
Now we need to pass the texture allocator to our splash screen and game scene in the Game class constructor.
We also need to create a reference to the texture allocator in our Game header. We’ll only have the one copy of the texture allocator for now but in future, we may want different systems to be responsible for their own resources.
Make sure you run the game to check we have not broken anything, and you should (fingers crossed) be greeted with the now familiar sprite. Next week we will look at one method of handling the large number of objects that our game will eventually have and then we will finally start making changes to what is displayed on screen when we start our animation system.
As always, if you have any suggestions for what you would like covered or are having any trouble implementing a feature, then let me know in the comments and I’ll get back to you as soon as I can. Thank you for reading 🙂