Texture compression

[pamaury]

Hello,
it's not really a feature request but an idea that came to my mind. Why not implement texture compression ? This can be done in a standard way using extension(ARB_texture_compression and EXT_texture_compression_s3tc I think) and it has many advantages when using lots of textures. It of course improves memory usage but it generally also increase performance with a minor quality loss. That's just an idea but what do you think of it ?

[Laurent]

Yeah, it sounds nice but you guys know that any new feature must prove it's really useful before being integrated into SFML
In particular, I'm not so sure it's really relevant in this context.

It of course improves memory usage

So far, nobody ever complained about video memory usage.

it generally also increase performance

The performance bottleneck in SFML is the huge number of states switches. Decreasing the texture usage won't help actually

with a minor quality loss

Quality is important for a lot of people. But if this feature is provided as an option I guess it's not a problem.

This feature can be interesting, but as it's not necessary right now, and there are so many other important things to implement, I won't give it a try.

Maybe next year :lol:

[pamaury]

I agree with most points except for memory usage. If some people want to have support for huge images, memory usage might become an issue.
I also believe it could have to uses for someone who uses SFML only to use OpenGL and the image facilities to load textures and that want full control over the texture parameters but that's not the majority, obviously.
Just some note about quality: with compression it's possible to have a bigger image that has the same memory usage that an uncompressed image with a lower resolution but the compressed image looks better because it has an higher resolution.

If I have time, I'll try to do some modification to see what is feasible.

[Laurent]

If some people want to have support for huge images, memory usage might become an issue.

I agree, I just said that nobody complained about it so far

I also believe it could have to uses for someone who uses SFML only to use OpenGL and the image facilities to load textures and that want full control over the texture parameters but that's not the majority, obviously.

People using sf::Image for loading OpenGL textures will do it manually anyway, they will use Image only for loading pixels from the file. That's because SFML is aimed at 2D rendering, so it doesn't generate mipmaps and stuff like that.

Just some note about quality: with compression it's possible to have a bigger image that has the same memory usage that an uncompressed image with a lower resolution but the compressed image looks better because it has an higher resolution.

A 1:1 rendering will always look better than an image which has been scaled down. Moreover, the colors may never be 100% accurate with compression, even with a huge resolution.

If I have time, I'll try to do some modification to see what is feasible.

That should not require more than a few lines of code

[raytaller]

Hi :-)
I am now evaluating SFML as a replacement of my current game library (Irrlicht).
My (2D) game will have more and more texture, and the ability to use compressed textures is one of the most important factors in my decision. Do you confirm it is a matter of a few lines of code to enable this feature, and to keep it compatible with the main trunk ?
Thanks, and anyway, SFML is a really great project !

[Laurent]

matter of a few lines of code to enable this feature, and to keep it compatible with the main trunk ?

Yes. But you'll have to distribute your modified version of SFML.

[raytaller]

Thanks ! I'll switch to SFML soon, then :-)