sf::image vs sf::sprite in my project

[kingcools]

Hi, in my current project(a beat *em up (maker,2-d sprite based), based on an existing one) for which i will use sfml 2.0. i have to load certain filetypes, one of these contains images(crazy, i know).

Now this beat 'em up of course has to handle the players character, whose image handling i'd like to discuss.
I need to store all sprites and print them on screen on demand at a given position.
This of course in certain orders predefined by the creator of that character(in external animation files describing sequences of images(does not store the images itself)).
Furthermore should simple image/animation manipulations be possible such as rotating the current sprite(s) and, most prominent, displaying afterimage effects.

Would i copy the images' data into sf::sprites(which is fast to draw) or would i create my own class inheriting from sf::drawable?
Is sf::sprites suited for this? Because the documentation of sfml 2.0 says sf::images is fast in manipulating images, nothing alike is stated for sf::sprites.

To be more precise:
What i wished my system was like:

Animations are just a set of pointers to beforehandedly loaded images who then are drawn onto the desired position on screen.
Only problem: What if i, for example, want to rotate the image by 90 degrees? I do not want to touch the loaded sprites directly, so would i have to copy those and manipulate the copies? This would oppose my idea of animations just "pointing" to images not copying them(which would be faster)...any ideas on this one?

[The Terminator]

sf::Texture is a better choice because it lives inside the graphics card, which allows for very fast loading, manipulating, etc. sf::Image is a resource heavy class that can cause you lots of trouble if you aren't careful. Plus, sf::Image is almost never used in SFML 2.0 projects because sf::Texture offers much faster speed. For your animations, which you obviously want to be fluid and fast, sf::Texture is a definite better choice.

[kingcools]

THank you I did not even know about sf::texture(when i scrolled over it i always thought it was for like 3d stuff or whatever), i will look into it

[Nexus]

You have to understand the separation between the classes.

On one side, there are the resource classes sf::Image and sf::Texture. Images are containers of pixels and allow random access. Textures store the pixels on the graphics card, they hold the graphics data to render. Resources are both heavyweight. The Terminator is wrong, textures are not faster or anything than images, they provide a completely different set of operations (images cannot be used for rendering). In general, it is advisable not to manipulate resources classes continously after loading.

On the other side, there is the "front-end" class sf::Sprite. Sprites internally keep a pointer to a texture. They are very lightweight, and allow to transform textures or a part of them, and to display them appropriately on the screen. It is usually no issue to have many sprites.

For your specific case, you should just use sf::Texture and sf::Sprite, they perfectly fit your needs. When you want to change the frame of your animation, you call sf::Sprite::setTextureRect() in order to refer to a different rectangular part of the texture. Any time you apply a transform like rotation, you directly change the sprite. This won't affect the referenced texture and is a very fast operation (1 assignment).

[kingcools]

For your specific case, you should just use sf::Texture and sf::Sprite, they perfectly fit your needs. When you want to change the frame of your animation, you call sf::Sprite::setTextureRect() in order to refer to a different rectangular part of the texture. Any time you apply a transform like rotation, you directly change the sprite. This won't affect the referenced texture and is a very fast operation (1 assignment).

Thank you for your advices.
Do i understand you correctly that you recommend to load all the images into one texture and then change "current sprite" by changing the region of the texture thats displayed?
otherwise i do not understand your "use sf::sprite::setTextureRect()" hint^^

edit:

i thought a bit more about my project and you must realize that the image data only stores the palette element it is using(each pixel is one byte which refers to an element in the used palette). This allows to easily change the coloring of the image by just replacing the current palette with a different one.
This seems to be impossible with the image classes provided by sfml 2.0, isnt it?

So probably it would make most sense to inherit from sf::drawable and build my own image class?

[Laurent]

If you want to handle paletted images as fast as possible (ie. on the GPU), you must use a shader. Doing it on the CPU will kill performances, since you'll have to re-convert it to a RGBA texture everytime you change the palette.

[kingcools]

Thanks, i will look into that too then

edit:
to sum this up:

so i use sf::texture to store the images in memory(memory of the graphic card, right? though the location does not matter for the planning stage) and use sf::sprites to display them.
Furthermore do i use pixelvertices to modify the palette/colors of the images?

[masskiller]

Furthermore do i use pixelvertices to modify the palette/colors of the images?

Fragment (GLSL as this is OpenGL) shaders, a hue shifting shader can do the job, there is surely more than one on the net if you search well.

[kingcools]

Ok, thank you