SFML community forums

Help => General => Topic started by: Chunker120 on May 18, 2013, 03:00:56 pm

Title: SFML how to handle large spritesheets?
Post by: Chunker120 on May 18, 2013, 03:00:56 pm
I am working on a basic game with NPCs, and each NPC has a resolution of 120x1030, it holds all animations in a single file. Each animation has 4 frames and I just add them under each other.

The problem is, I have noticed some small performance drops (Got a pretty weak computer) when trying to use sprites with the spritesheet (I have a sf::IntRect set up, so it only displays a portion of the sprite).

Is the small performance drop because of the large spritesheets? If so, can I do anything to optimize it? (Putting them outside the spritesheet is not an option because I need a lot of different humans)
Title: Re: SFML how to handle large spritesheets?
Post by: Nexus on May 18, 2013, 03:25:21 pm
No, the performance drop shouldn't be because of the spritesheets. After all, OpenGL holds the texture in memory anway, you just use different texture coordinates.

If the limiting factor are the number of draw calls, an optimization would be to use vertex arrays instead of sprites. But before, you should profile the application to see the real bottlenecks.
Title: Re: SFML how to handle large spritesheets?
Post by: Chunker120 on May 18, 2013, 03:41:46 pm
No, the performance drop shouldn't be because of the spritesheets. After all, OpenGL holds the texture in memory anway, you just use different texture coordinates.

If the limiting factor are the number of draw calls, an optimization would be to use vertex arrays instead of sprites. But before, you should profile the application to see the real bottlenecks.

I see, I was mainly asking this because I was getting 65 FPS before, and 63 FPS after adding a few humans in-game. Perhaps it's the architecture of the class rather than the spritesheet.
Title: Re: SFML how to handle large spritesheets?
Post by: Nexus on May 18, 2013, 04:05:09 pm
65 and 63 FPS is not really a difference that lets you draw meaningful conclusions. Of course, rendering isn't free, but you should not spend too many thoughts about it if there is no performance problem.