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.
In this tutorial, we will create a drawing system and start preparing for our collision system. To do this we need to make a few changes to our tilemap parser. We will be creating an additional layer within Tiled that will include only the tiles that we want our player to collide with. Currently we have rudimentary support for multiple layers, however, we only support the one tileset (the image containing our tiles). We’ll want to change this as we will be using different tile sets for different layers. For more information on what Tiled is and how we are using it in our game, you can read the previous tutorial. Also, we currently have no way of specifying the order that sprites are drawn to the screen, so even when we add another tile layer it will not appear in the correct order. At the moment they are drawn in the order we add them to the ObjectCollection, which is not ideal; so we’ll add support for setting a sort order for our drawable components. We’ll then use this to draw our collision layer on top of our platform layer.
There’s a lot to get done this week so let’s start by opening Tiled and creating a new layer called Collisions. I’ve Imported a new tileset which is just a red square. You can use any tiles you want for this layer as eventually we will not be drawing them. I’ve chosen red sprite as it provides a contrast with our current map so it is obvious which tiles are collision tiles and which are not. Place the collision tiles on a new layer called ‘Collisions’ and wherever you want the player to collide with the environment. The name of the layer is important as you’ll see shortly.
Collision layer in red.
Once done you can save and close Tiled. I’ve updated the map in the folder for this tutorial so you can use that if you would like.As the layer uses a new tileset, before we can import this layer in our game, we need to add support for multiple tilesets. This will involve making a few changes to our TileMapParser class. We’ll start by creating a new TileSheets alias.
TileSheets is a map of integers and a shared pointer to TileSheetData. The integer represents the starting id of the images in the tileset, I’ll explain this in more detail shortly when we get to implementation.We’ll also need to update our BuildSheetData and BuildLayer function declarations so that they return and receive our new TileSheets.
BuildSheetData now returns a pointer to our newly created TileSheets rather than a singular TileSheetData and BuildLayer accepts TileSheets as a parameter instead of a singular tileset, as each layer may have tiles from multiple tile sheets.With the declarations modified its time to update the function bodies. BuildSheetData requires the biggest change as it is responsible for building the data structures for our tilesets.
We now loop through nodes with the name ‘tileset’ and then do the usual process of building the TileSheetData for that node. This is then added to our new map of tilesets. We use the id of the first tile in the tileset as the key. For example, if the first tileset we add has 4 tiles, its id will be 0 (we start the index at 0) and when we add the next tile set, its first id will be 4.
Tile maps with ids.
With that done your IDE of choice (if you use one that is) should be having an issue with the BuildMapTiles function because we have not yet updated the return parameter when we call our newly updated BuildSheetData function. We’ll fix that now.
The last change we need to make in our parser is in the BuildLayer function. Now that it accepts multiple tilesets, we first need to find which tileset it belongs to before we can set a tiles texture information.
- We loop through the tilesets in reverse order as the tilesets are added with the tile ids in ascending order.
- If the tile id is greater than or equal to the key we know that the tile belongs to this tileset as we are iterating over the tileset in reverse order.
- If no tileset is found we skip this tile. This should not happen and we will want to add additional logging here.
Once we have the tileset we can create the tile data the same way we did before.
And that’s it for our parser! We can now use multiple tilesets however if you run the game you will probably not see the new layer. This is because we have not created a method of drawing sprites in a certain order as currently they are drawn in the order we add them to the object collection.
You can set a sort order for sprite renderers in Unity.
To accomplish this we’ll need to create a drawable component and a drawable system. As you’ll remember from previous tutorials, a component is what we use to extend objects functionality and a system will control the components. This is the beginning of a conversion to a true Entity Component System model that we discussed here. Although we’re not converting completely (yet) as components in an ECS are purely data objects and our components will still do some processing i.e. drawing the sprites.
We’ll start with creating the component, C_Drawable.
This allows us to set and retrieve an integer that we use to sort our sprites before drawing. Draw is a pure virtual function, as this will be the parent class of any component that requires drawing and should not be instantiated. All components that will draw to the window will inherit from this class. This includes our sprite component, so let’s change that now.
The sprite component is the only component we currently have that draws to the window so it is the only one we need to change.As we will soon have a separate system for drawing we can remove the Draw function from our Component class. So the new Component class looks like this:
To draw objects we will need to modify our Object class. First, we add a pointer to a drawable component as a member variable and then we modify our AddComponent function so that we check if the new component inherits from C_Drawable, if it does then we set our drawable member variable to point to this component.
I’ve also added a GetDrawable method that returns a reference to our drawable component.
The last change we’ll make in the Object class is to have our draw method call our drawable component rather than looping through every attached component. We could check to see if the drawable component is not a nulptr before calling its draw function but this will be handled when we create our drawing system.
We are currently limited to one drawable per object at the moment as it simplifies our drawing system but we’ll be expanding this in future.Now with our drawable component complete, we’ll create the drawable system which I’ve called S_Drawable. I prepend S_ to the class name to show that it is a system, feel free to disregard this naming convention and name the class whatever you want.
ObjectCollection and our drawing system manage separate collections that contain similar objects (with S_Drawable containing a subset of all objects as it only stores objects with a drawable component). Doing this allows us to store, and sort the data in different ways depending on the needs of each system. For example, if we only maintained the one collection and sorted it by draw order, then when it came to implementing our collision system having the objects sorted by draw order is of little use. Using a separate collection for collisions allows us to store the objects into different zones to minimise the number of collision checks we perform (more on that in a when we start our collision system). However, there are a number of disadvantages: firstly we have to manage these collections separately, when we remove an object from the ObjectCollection we expect it to be removed from the game so we’ll have to check all other systems and ensure it is removed from their collections too. Also, it uses additional memory for each collection, however as they are all pointers to objects we’ve minimised this disadvantage.
We’ll start the implementation with the Add function. Its role is to check to see if the object has a drawable component and if it does it is added to this systems collection. Once the vector of new objects has been processed we sort the collection based on the sort order of its drawable component with lower sort orders appearing at the beginning of the collection and higher sort orders at the end of the collection.
By sorting the objects in this way, when it comes to drawing them, we can simply loop through the collection from beginning to end, call the objects draw method and they are drawn in the correct order.
As I mentioned earlier when we remove objects from the main ObjectCollection we also want to remove objects from this system so we have to have a ProcessRemovals function.
This works in the exact same way as it does in ObjectCollection. Talking of ObjectCollection, we need to make a few changes there to use our new drawable system. First, we create a drawable member variable.
We also have to call the ProcessRemovals function on our new system.
And lastly, rather than loop through every object in the Draw function, we now just call our drawing systems which draws the objects in the correct order.
This is everything we need to do for the moment to be able to set the sort order of sprites. To test it we can set a tiles sort order in our TileMapParser based on the layer they are on. We’ll do this in the Parse method.
We set the sprite sort order in reverse because that is how it is drawn in Tiled. The layers first in the list are drawn on top of subsequent layers. Now when you run the game you’ll see that our new collision layer is drawn on top of our platform layer. Great!
Our collision layer is now drawn.That’s all for this week. As a final note there are a few things to have in mind about the current limitations of our drawing system:
- We currently do not support layers. It would be good if we could set a group of sprites as a background layer for example and have them always drawn before subsequent layers.
- We are drawing everything regardless of whether it is onscreen to not. We should add Occlusion Culling.
- We have a limit of one drawable per object. In future, we will want to add more.
- If we add a new drawable component to an object the drawable system will not sort its collection to accommodate the new object, consequently, it is likely that the object will be drawn out of order.
This is not everything we’ll change before we’re done with our drawing system. It is just a few ideas that I had as I was writing this tutorial.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 🙂