The implementation was done to gain better control over the order in which the sprites are drawn on the screen (which sprites that will appear on top of the others) and to simplify changing the view (the portion of the game world that is displayed on the screen) of certain sprites in the game but ignore other sprites like GUIs and HUDs.
In SFML there is a data type called RenderTexture, that works very similar to RenderWindow. The major difference between the two is that RenderWindow creates a graphical window presented on the computer screen whereas RenderTexture can not be viewed, only drawn as sprites on other surfaces.
I use RenderTextures as the data type for my layers. The layers are stored in a list, in the order they are supposed to be drawn out. All sprites are now associated with a layer variable, which is just an integer that the drawing function uses to determine which layer it should be drawn on.
When all sprites are drawn the view is changed on the specified layers by using the inbuilt functionality renderTexture.setView();
A thing to remember when using RenderTexture as a layer is that the RenderTexture.clear() function has by default to fill the screen with a non transparent black color. To make the layer transparent in the clear function you need to specify the clear color like this .clear(sf::color(0x00,0x00,0x00,0x00)) So that the alpha channel (the fourth value) is set to be fully transparent.
Since entities in this game can have more than one sprite I also implemented a sprite list in each entity. The sprite list consists of a std::vector containing std::pair where the first value of that pair is a pointer to a sprite and the second value of the pair is the layer specifying int for that sprite. To reach the sprite, for example when changing the position of it one needs to write like this inside the entity class: m_sprites[index].first->SetPosition(x,y);.
Implementing layers was a high risk move, since I did not know if it was going to work as I wanted and it required rewriting a lot of code in many classes before I could see a result. It took more time than I thought it would because of all the code needed to be rewriten to work with the layer code. I could have reached similar results without the layers by adjusting the position of all sprites according to the game view in the window before every time the sprites are drawn to the window. I choose the layer approach over the moving sprites approach because it made more sense for me to think in terms of layers and I thought it would generate code that was easier to understand and read. In terms of performance I have no idea what approach is more suitable. In the end I got the result I wanted.
