Each object does have its own sprite. I load up all the textures in the graphics class. Then I create a sprite and send it over to another class. I only do this once per class. Anyway thanks for the advice everyone

So essentially you are having your graphics manager create a sprite, passing that sprite a texture, then returning the sprite by value from the method so that elsewhere you are assigning that returned sprite to your class Sprite member? It's okay to do it that way, the Sprite copy and assignment operators are well implemented. It does result in some unnecessary copying, but since it's only done once per object it shouldn't be a problem, and it's a very miniscule amount of data to be copied anyway

Edit: My own personal preference in a situation like that is to have the graphic manager manage graphics only (ie, textures). I write a method, called something like getTexture(), which will load the named texture if not already loaded. Then rather than a method in my object class called setSprite(), I would call setTexture() instead. The reasoning for this is that it should not be the responsibility of the graphic manager to know what texture to assign a given object. The graphic manager should not be the one making the decision that this object gets the player texture, while that object gets the enemy texture. What if you want to implement more than one type of enemy? Or what about special effects? The graphic manager should just be a dumb class, solely responsible for managing graphics. (The Single Responsibility Principle) Giving it more responsibility than that only complicates the code when you want to expand it.

.In that case, your player creation might look like this instead:


player.setTexture(graphicsManager.getTexture("playerSprite.png"));


In this case, it is trivial to use a different sprite image for another object.

IF you have a Sprite object that is the same through out your program, you should use the same sprite, no need to have mutliple of the same data loaded. Creating a sprite manager class that manages them and has methods for getting pointers to sprites, and/or use shared_ptr/weak_ptr.

This is a pretty good place to use shared_ptr, because you may not want the added complexity of a SpriteManager, however you do want to pass around the same object in a reference style. If you have a c++11 compiler ( VS2012, MINGW, GNU ) then you can use shared_ptr to do this, it would be a good solution.

You could even type def to something easier like

typedef std::shared_ptr<Sprite> SharedSprite;

IF you have a Sprite object that is the same through out your program, you should use the same sprite, no need to have mutliple of the same image loaded. Creating a sprite manager class that manages them and has methods for getting pointers to sprites, and/or use shared_ptr/weak_ptr.

In SFML, a [font=courier new,courier,monospace]Sprite[/font] doesn't own the texture, it just stores a reference to it. You can have multiple sprites all using the same texture without any kind of sprite manager.

[quote name='EddieV223' timestamp='1355697194' post='5011379']
IF you have a Sprite object that is the same through out your program, you should use the same sprite, no need to have mutliple of the same image loaded. Creating a sprite manager class that manages them and has methods for getting pointers to sprites, and/or use shared_ptr/weak_ptr.

In SFML, a [font=courier new,courier,monospace]Sprite[/font] doesn't own the texture, it just stores a reference to it. You can have multiple sprites all using the same texture without any kind of sprite manager.
[/quote]

Ok I changed Image to data.

Doesn't really make sense to share sprites, since they encapsulate transformation data. If the two objects share the exact same position, orientation, scale and image, then I would say you have not two different objects, just one object and one duplicate.