Sprite itself is a lightweight class and doesn't directly have an impact on performance.
The texture it uses and the draw calls made by the sprite is what needs to be considered.
If you use multiple textures, then you'll be paying the price of a texture context switch, which can be okay, but can also quickly add up. As such the general recommendation is to use texture atlases (e.g. tile maps), which then lets you reuse the same texture, but with a different texture rect.
Draw calls are slow and one of the most common causes for rendering performance issues (with SFML).
This should usually be fine for a few hundred sprites, if you get into the thousands, you should really reconsider your options. The general recommendation here is to switch to vertex array or vertex buffer, which allows you to render a whole "mesh" of vertices in a single draw call.
The best source (pun intended) for these questions is the source code:
https://github.com/SFML/SFML/blob/2.6.x/src/SFML/Graphics/Sprite.cppAre sprites stored on the GPU (ie all he details about the graphical icon)?
No, sprites reside entirely on the CPU/RAM side. Textures however are stored in VRAM (which is why copying textures is expensive, as you first have to move it from VRAM to RAM and then back to VRAM).
How do you judge whether you have too many sprites?
There isn't a specific rule. Usually things become noticeable if your game (not some artificial "benchmark") doesn't manage to get a reasonable framerate (60-200fps).
Is there context switching that takes place with spite data stored on the GPU? Is it switching in and out from the CPU if there isn’t enough capacity?
[/quote]
Sprites are lightweight objects. You can use them even as temporaries and recreate them every frame, but just because you can, doesn't mean it's really recommended.
Recent Posts
