is faster, but with a very large image there is a higher risk of saturating the videocard RAM and get slowdowns.
This solution is also less correct regarding mipmaps and texture borders, beware of color bleeding, it looks very unprofessional.
But even for 60 fps animation, 1 bind per frame per different sprite will probably take a negligible time, so 1) seem good too.
Most games out there use a lot of different textures on the same frame.
Originally posted by ZbuffeR: so answer to your P.S. is “yes, if bigger texture is very big”).
Thanks for you answer!
Concerning what you mentioned above, did you mean that if the texture is very big then it will be much faster than using a lot of smaller textures, or the contrary?
For example, I also need to store the icons of my GUI, and I question myself the same thing, should I store them all in a big texture or use them separetly?
According to your answer, it seems that to avoid color bleeding one icon per texture is better. Did I understand right?
I edited my post to be clearer.
Often there is a “sweet spot” of texture size that gets the best hardware performance, probably around 1024*1024 nowadays, but would depend on the actual hardware of course.
One icon per texture will indeed avoid bleeding if done correctly. Much harder to do it correctly with texture atlases, but if a given icon has always the same pixel-to-texel ratio, it is easier to optimize for this case. Then you can still have problems with extreme (high or low) screen resolution.
As a general recommendation for all “perf-oriented” hacks, I would say, do your stuff without texture atlases, keeping each texture separate, benchmark it, and only implement texture atlases if you have perf problems, then re-benchmark to check the usefulness.