SFML community forums
Help => General => Topic started by: eggw on August 01, 2015, 09:36:33 pm
-
At the moment, for my current project, I store all the sprites needed in a couple of image files, which act as sprite sets. So, for example, in units.png I'll have the different sprites needed for unit type 1, unit type 2, and so on.
The drawback to this is, of course, is that you have a limited subset of sprites to work with, since they all have to be present in that one image file at runtime; adding new ones will involve manually editing it, which is error-prone and a hassle. As far as I'm aware, it's inefficient for the GPU to have a different image file for each different sprite (especially when you have a lot to work with, as I do). However, I want it to be easy to dynamically add new ones - without that overhead of having plenty of image files. The idea I have is to do just that, give each unit its own sprite, but to merge them all into one big, cached image file at runtime - but SFML does not seem to have this capability. Is there a way to accomplish this, or perhaps a different solution altogether?
-
Are you talking about a texture atlas?
It's very well possible to do this with a render texture.
Whether it really makes sense in your situation is another discussion though. ;)
-
Are you talking about a texture atlas?
It's very well possible to do this with a render texture.
Whether it really makes sense in your situation is another discussion though. ;)
A texture atlas is exactly what I meant. I was not familiar with the term for it.
After doing a little reading on RenderTexture (having never used it before), it indeed does not make much sense for my situation, since I don't want everything in it to be drawn. What I basically want is to create a texture atlas (as a regular sf::Texture) out of multiple images dynamically at runtime, in order to avoid the overhead of lots of different small images.
-
What I basically want is to create a texture atlas (as a regular sf::Texture) out of multiple images dynamically at runtime, in order to avoid the overhead of lots of different small images.
Then a render texture is exactly what you want. You draw your images to it once and then use the underlying texture as your texture atlas.
After doing a little reading on RenderTexture (having never used it before), it indeed does not make much sense for my situation, since I don't want everything in it to be drawn.
The "make sense" sentence was more about, whether you actually gain anything from it or whether you just make your code more complex.
You shouldn't do optimizations just because you heard or read something about it. Write optimizations when your profiler shows that you have a bottleneck.
-
After doing a little reading on RenderTexture (having never used it before), it indeed does not make much sense for my situation, since I don't want everything in it to be drawn.
You use the render texture the same way you would use a texture (http://www.sfml-dev.org/documentation/2.3.1/classsf_1_1RenderTexture.php#a95bc5152c497066d31fdc57da8e17678): to show only a part of the texture/render texture, use a texture rectangle or set the texture co-ordinates to match.