What is the best practice? How fast is copying sprites? A design decision.

[deso]

This is more of a design decision than a technical issue.

So, I'm wondering about this. I have this design decision, where I can store the sprites of several objects inside them, and request them when I want to draw them (every frame), or I can store all the sprites in a container (vector, or a map, a map would be ideal, I guess) inside the class responsible for drawing the stuff.

The thing is, the position is of each object is saved inside the object itself, so it's much easier to just ask "gimme your sprite" and receive a ready sprite at the right location and draw them, then to keep track of which sprite belongs to each object, and have to ask the object for his position, then set the sprite coordinates.

 I'll have objects die (it's a game after all, stuff dies), if I keep the sprites inside the class, I'll have to keep track of which objects died and remove their sprites too. If I keep on the objects, once they die, they will be removed and it won't be on the list of things to draw anymore.

The only drawbacks I can see to keeping the sprites inside the objects they belong to is that the objects will have to know the size of the map squares to calculate their position properly AND it can be slow if copying sprites is slow. Alternatively, I can just make a member function to return a pointer to the sprite and draw the sprite from inside the object directly, but maybe that hurts encapsulation?



Loads of options, loads of ways to shoot yourself in the foot in the future.

[Nexus]

Have you searched a bit? I have responded to this question myself a few times, for example here, here or here.

I would start with the simplest approach (keep a sprite in every object, or recreate sprites on-the-fly). For better separation of graphics and game logic, it's also possible to just store the drawable representation in every object, but let only the central rendering class access and modify it.

[deso]

Uh, I usually search before posting, but I think I didn't this time. My bad.

Thanks for your answer, tho, I'll check out the other threads.

[Mörkö]

Here is another suggestion based on how I usually do rendering in my small projects.

Instead of using any sf::Sprites, store only one texture in a singleton, lets call it RenderingSystem. That texture is your spritesheet which contains every sprite.

Then, create a base class called something like Renderable, with a virtual method called get_vertices(VertexArray & vertices).

The idea is that every drawable entity in your game inherits Renderable and override get_vertices. When its time to draw, you create a vertex array and pass it to every drawable entity which inserts its vertices according to that instance's position, etc. And then you just draw that array.

That way you don't need to store the sprites in each game entity, nor do you need to keep track of which sprites should be removed.

To make it better, you can use std::vector<sf::Vertex> instead of sf::VertexArray, that way you can keep the vector loaded with static sprites and only insert the vertices of dynamic entities that need re-drawing.