Compressed textures

SDL Development
1

Would it be possible to add support for compressed textures in SDL 1.3? I mean thing like GL_COMPRESSED_RGB for internal texture format for OpenGL.

2

any comments?

3

What compression formats are you talking about? DXT1 thru DXT5, FXT1,
ATI’s compression format (3Dc) or something else? This would seem to be
something that is video hardware dependant and therefore difficult to put
into SDL in a generic way.

We already have people complaining that feature X isn’t supported on this or
that hardware (which is a specious argument IMHO).

KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of hardcoder
Sent: Thursday, February 11, 2010 12:43 PM
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Compressed textures

any comments?

4

I am talking about standard OpenGL 2 feature:

(from http://www.opengl.org/sdk/docs/man)

If the internalFormat parameter is one of the generic compressed formats,
GL_COMPRESSED_ALPHA,
GL_COMPRESSED_INTENSITY,
GL_COMPRESSED_LUMINANCE,
GL_COMPRESSED_LUMINANCE_ALPHA,
GL_COMPRESSED_RGB, or
GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage. If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format.

which is passed to glTexImage2D function. This uses whatever the driver thinks is suitable for the compression, and doesn’t even have to succeed. This could be based on some flags passed to SDL_CreateTexture func. Don’t really know Direct3D but can’t imagine it is not as easy.

5

It’s not a bad idea. What are the implications of this for texture
quality vs memory savings?On Thu, Jan 21, 2010 at 2:37 PM, hardcoder wrote:

Would it be possible to add support for compressed textures in SDL 1.3? I
mean thing like GL_COMPRESSED_RGB for internal texture format for OpenGL.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

6

I think it is really nicely explained here:

here:

and finally here:

Basically, it is designed to be render friendly - high quality, fast decoding, random access with compression ratio 4:1 or 8:1. It is supported by virtually all hardware since 19th century by all HW manufacturers. It cannot possibly hurt anyone to add support for this to SDL. It would be nice though to also add possibility to load compressed textures directly (dds-like files).

7

S3 doesn’t look it would be directly used with SDL textures.
If a programmer were to use SDL to assist loading compressed textures,
they would be loading already compressed textures. Otherwise there is
no advantage in compression, right? But that can already be done,
using directx/opengl directly within SDL.

OpenGL/directX are the only graphic api’s that formally support
S3(atleast from what I’ve seen) and SDL is cross-platform library that
supports more than just opengl/directx. It wouldn’t be very SDL-ish to
include it, I would think. People would complain the next day,more
likely than not, about the overhead adding S3 capability.

Because you have one of two viable options for supporting S3 while remaining
cross-platform

Decompress each S3 texture into a usable SDL_texture using software
techniques. Probably adding a libsquish dependency. (953 kb)

Or

Add S3 texture decompression capability in the software renderer
itself, using gl/directx when available.

It would probably add some serious kilobytes. And code too. Which
means potentially more bugs. SDL 1.2.x programmers got by just fine
without S3 compression.

Truthfully, this looks more like a “I want to squeeze every little
last bit of space/performance out of this machine” technique. Not a
simple, "I want to use mid-level library that supports every platform"
technique.On Tue, Feb 23, 2010 at 6:26 AM, hardcoder wrote:

I think it is really nicely explained here:

http://en.wikipedia.org/wiki/Texture_compression

here:

http://en.wikipedia.org/wiki/S3_Texture_Compression

and finally here:

http://en.wikipedia.org/wiki/DirectDraw_Surface

Basically, it is designed to be render friendly - high quality, fast
decoding, random access with compression ratio 4:1 or 8:1. It is supported
by virtually all hardware since 19th century by all HW manufacturers. It
cannot possibly hurt anyone to add support for this to SDL. It would be nice
though to also add possibility to load compressed textures directly
(dds-like files).

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

What is the main difference between SDL 1.2 and SDL 1.3? It is obviously hardware rendering. If you need cross-platform 2D blitting library, just go with SDL 1.2. But we are now finally moving forward with SDL.

Now, if it is decided that SDL 1.3 will use D3D or OGL then obvioulsy SDL should take advantage of those backends. Since both backends support storing textures internally in compressed format for many yeas now why not simply let SDL users take advantage of that. And again, as I said it can be optional renderer feature that could be obtained from SDL_RendereInfo struct. And I am not sure if I get you right but no, texture doesn’t have to be in compressed format before uploading to renderer to take advantage of the compression. And implementing it for OGL and D3D renderers is trivial.

The feature is in fact very useful for older hardware with limited video memory because 4x many textures can be stored inside it with minimum visual decrease. For a game implementation this usually means that in the video settings user can select visual quality:

lower - possibly means texture compression which makes more textures stored in actual video memory vastly increasing the speed of rendering
higher - where textures are not compressed possibly resulting in out-of-video-memory cases forcing textures to be stored in client side memory decreasing rendering, well this is why texture compression was invented in the first place.

Actually, texture compression may be as well used for increasing visual quality (by using higher detail image using same amount of memory) which IIRC was used in Half-Life 12 years ago…

But it is not about many pros of texture compression but about adding SDL support for it. TC is great and IMHO it would be nice if SDL supported it.

Jeremiah wrote:> S3 doesn’t look it would be directly used with SDL textures.

If a programmer were to use SDL to assist loading compressed textures,
they would be loading already compressed textures. Otherwise there is
no advantage in compression, right? But that can already be done,
using directx/opengl directly within SDL.

OpenGL/directX are the only graphic api’s that formally support
S3(atleast from what I’ve seen) and SDL is cross-platform library that
supports more than just opengl/directx. It wouldn’t be very SDL-ish to
include it, I would think. People would complain the next day,more
likely than not, about the overhead adding S3 capability.

Because you have one of two viable options for supporting S3 while remaining
cross-platform

Decompress each S3 texture into a usable SDL_texture using software
techniques. Probably adding a libsquish dependency. (953 kb)

Or

Add S3 texture decompression capability in the software renderer
itself, using gl/directx when available.

It would probably add some serious kilobytes. And code too. Which
means potentially more bugs. SDL 1.2.x programmers got by just fine
without S3 compression.

Truthfully, this looks more like a “I want to squeeze every little
last bit of space/performance out of this machine” technique. Not a
simple, "I want to use mid-level library that supports every platform"
technique.

9

So turning on TC makes everything related to video better regardless of
input? TC sounds like a feature you would expect in a game engine.

Do SDL applications look hideous or something?
I thought this was just the ‘good enough’ library. Display some images,
respond to events,play a sound. Simple/Direct. Minimalistic.If I wanted so
much more, I would use Irrlicht.On Thu, Feb 25, 2010 at 8:15 AM, hardcoder wrote:

And I am not sure if I get you right but no, texture doesn’t have to be
in compressed format before uploading to renderer to take advantage of the
compression.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org