Texture Management in 1.3

SDL Development
1

The 2D API thread got me thinking of what to do when the time comes to migrate
to SDL 1.3. So I wondered whether in SDL 1.3 there will be better control for
OpenGL textures?

The things I wondered about were:

  • non power-of-2 textures (AFAIK requires extensions but AFAIK glSDL can do this)
  • keep a shadow software SDL_Surface, to modify pixels and re-upload.
  • mipmaps/filtering.
  • dithering (is AFAIK necessary if running in 16bit OpenGL video mode)
  • control wrap/repeat mode and border.
  • control anisotropy level + query max. anisotropy (requires extensions)
  • texture compression (requires extensions, GL_COMPRESSED_RGBA_S3TC_DXT5_EXT or
    whatever)

IMHO if SDL supports uploading textures to GL then why not also add these
features while you’re (we’re!) at it. Some of these features only make sense for
3D engines (e.g. anisotropic textures) but I wanted to ask anyway and look at
the chance of each feature being included in SDL 1.3. Note I haven’t had time
yet to check out the SDL 1.3 branch so I apologize for asking possibly redundant
questions.

Thanks.

2

Hello !

The things I wondered about were:

  • non power-of-2 textures (AFAIK requires extensions but AFAIK glSDL can
    do this) * keep a shadow software SDL_Surface, to modify pixels and
    re-upload. * mipmaps/filtering.
  • dithering (is AFAIK necessary if running in 16bit OpenGL video mode)
  • control wrap/repeat mode and border.
  • control anisotropy level + query max. anisotropy (requires extensions)
  • texture compression (requires extensions,
    GL_COMPRESSED_RGBA_S3TC_DXT5_EXT or
    whatever)

What does SDL 1.3 with the Textures already loaded when
for example switching the resolution, will it upload them
again to the Video Memory or is this the coders work ?

CU

3

The 2D API thread got me thinking of what to do when the time comes
to migrate to SDL 1.3. So I wondered whether in SDL 1.3 there will
be better control for OpenGL textures?

Well, I have yet to figure it out completely, but SDL 1.3 does have
the concept of textures, along with the surfaces, and there are
various new functions related to these textures…

The things I wondered about were:

  • non power-of-2 textures (AFAIK requires extensions but AFAIK glSDL
    can do this)

Actually, glSDL just hides the actual texture management from you. A
glSDL surface can concist of a part of a texture, tiles layed out in
a single texture, or tiles placed in multiple textures. That’s how it
handles non power-of-two surfaces, and surfaces that are larger than
the maximum supported texture size.

  • keep a shadow software SDL_Surface, to modify pixels and
    re-upload.

This is exactly what glSDL does. (The wrapper version effectively
piggy-backs the texture management on top of SDL software surfaces.)

  • mipmaps/filtering.

Replacements for the glu*() functions, that is?

That could be handy without OpenGL as well (together with scaling on
the 2D backends), so why not implement it on the SDL surface side?
Not sure if it should be integrated or an add-on library…
Integrating it could provide acceleration of the scaling and
filtering on some backends, I suppose.

  • dithering (is AFAIK necessary if running in 16bit OpenGL video
    mode)

Yes… Though I’m not sure where or how to implement this. Could be an
add-on library, but that pretty much rules out any chanses of
accelerating it.

Also note that dithering just doesn’t work with scaling, rotation and
similar transforms, unless it’s done “live” when blitting to the
screen.

So, although dithering can be very useful, it doesn’t fit perfectly
into the 1.3 API, unless we’re talking about real time dithering in
the backends. OpenGL and Direct3D can both provide this, AFAIK.
However, that conflicts with SDL 1.2 style SDL_DisplayFormat(), as
dithering is pointless if the source data has the same color depth as
the display buffer.

  • control wrap/repeat mode and border.

BTW, this would apply to the SDL backends as well, if SDL was to add
the ability to specify texture coordinates explicitly. (With the 1.2
API, source surface coordinates are calculated implicitly.) However,
I see very few actual uses for this, unless perhaps if we’re
considering this OpenGL quad style free transform blit I’ve been
talking about. That might complicate software implementations quite a
bit, though…

  • control anisotropy level + query max. anisotropy (requires
    extensions)
  • texture compression (requires extensions,
    GL_COMPRESSED_RGBA_S3TC_DXT5_EXT or
    whatever)

This looks like OpenGL helper library stuff to me… If you’re relying
on OpenGL anyway, there isn’t really much point in wrapping stuff
that can be done via the OpenGL API. Then again, if it’s simple and
handy and doesn’t bloat SDL significantly, it doesn’t really hurt to
have.

Now, if we were to implement a new “Clean3D” API, wrapping OpenGL,
Direct3D and a software rasterizer + extensions and whatnot, it would
be a different matter. However, that’s most probably better done as
an optional add-on library instead. (Which may or may not require
minimal support from SDL to access Direct3D directly in a clean way.)

IMHO if SDL supports uploading textures to GL then why not also add
these features while you’re (we’re!) at it.

Well, even though SDL explicitly supports OpenGL for direct use by
applications, and it makes sense to provide reasonably simple and
basic functionality that practically every OpenGL application will
need anyway, one has to draw the line between SDL land and add-on
library land somewhere.

I would say that as a general rule, if a feature can be implemented
cleanly outside SDL (or any other lean and mean low level library for
that matter), it should not be integrated.

If you want to collect various handy stuff in a single place (for API
concistency, minimal number of dependencies etc), how about an
official SDL Utility Library?

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 16 August 2006 11:58, Sebastian Posch wrote:

4

[…]

What does SDL 1.3 with the Textures already loaded when
for example switching the resolution, will it upload them
again to the Video Memory or is this the coders work ?

If SDL can handle this reliably, I still think it should be possible
for the application to tell SDL whether or not it should manage
textures automatically. On backends that will never lose textures,
this makes no difference, but on others, SDL may have to "waste"
loads of memory. This could have the application fail to run at all
on systems that would otherwise work, although with the potential
issue of having to reload all textures from disk after certain
events.

BTW, glSDL does keep backups at all times, but this is mostly for SDL
1.2 2D compatibility reasons (surface locking and surface->surface
blits), and because the original wrapper implementation needed the
SDL surfaces anyway, as the interface to the application.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 16 August 2006 12:15, Torsten Giebl wrote:

5

If you want to collect various handy stuff in a single place (for API
concistency, minimal number of dependencies etc), how about an
official SDL Utility Library?

you mean an “SDLX”? :stuck_out_tongue:

Even if it only had vector and matrix class(es) it would already rock.

Erik Yuzwa
Wazoo Enterprises Inc.

6

David Olofson <david olofson.net> writes:

I would say that as a general rule, if a feature can be implemented
cleanly outside SDL (or any other lean and mean low level library for
that matter), it should not be integrated.

If you want to collect various handy stuff in a single place (for API
concistency, minimal number of dependencies etc), how about an
official SDL Utility Library?

By all means, I agree with this.

However for the anisotropy I was thinking about the possibility of querying it
via a new SDL_GL_ flag (e.g. SDL_GL_MAX_ANISOTROPY)? It would work basically
just like SDL_GL_MULTISAMPLEBUFFERS. With SDL_GL_Get_Attribute() you could ask
the driver for maximum supported anisotropy and with SDL_GL_SetAttribute() you
could specify your desired max (let the user choose 4/8/16/… for performance
reasons). This would be just a tiny patch for the OpenGL backend in SDL 1.2 from
what I understand. However I don’t know if the Direct3D backend should then also
have this and I don’t know how it’s done there.

The reason I mentioned mipmaps was that an addon library would probably not be
able to control it from outside the offical SDL routine which uploads the
pixels. If you wanted to use any of the GL_XXX_MIPMAP_XXX filters then I think
you would have to duplicate all the code (figure out surface format and handle
errors etc.) whereas if it were directly in SDL then it would be very stable and
only a single ‘filter’ or ‘quality’ flag is needed for that function, and a call
to gluBuildMipMaps (if the glu dependency is not a problem)

The other idea I had was that both the mipmap level and anisotropy level could
be stored somewhere in the internals of the SDL_Texture struct inside SDL, so
that these per-texture settings wouldn’t be lost when SDL decides to re-upload
the surface to the card (which I figure SDL 1.3 will be able to do in some way).
Library users could specify these values once at texture load time and SDL would
automatically choose the correct settings for the texture everytime it is
uploaded again. This would be handy for Windows when you switch from fullscreen
to windowed mode etc.

I understand that the preffered option is to put things in addon libraries but
in this case it might make sense.

7

[…]

David Olofson <david olofson.net> writes:

I would say that as a general rule, if a feature can be
implemented cleanly outside SDL (or any other lean and mean low
level library for that matter), it should not be integrated.

If you want to collect various handy stuff in a single place (for
API concistency, minimal number of dependencies etc), how about an
official SDL Utility Library?

By all means, I agree with this.

However for the anisotropy I was thinking about the possibility of
querying it via a new SDL_GL_ flag (e.g. SDL_GL_MAX_ANISOTROPY)? It
would work basically just like SDL_GL_MULTISAMPLEBUFFERS. With
SDL_GL_Get_Attribute() you could ask the driver for maximum
supported anisotropy and with SDL_GL_SetAttribute() you could
specify your desired max (let the user choose 4/8/16/… for
performance reasons). This would be just a tiny patch for the OpenGL
backend in SDL 1.2 from what I understand.

Why, yes, I would believe this qualifies as “simple, small and useful
enough to be included.”

However I don’t know if the Direct3D backend should then also
have this and I don’t know how it’s done there.

This doesn’t apply to either of the "SDL 2D over accelerated 3D"
backends. The SDL_GL_* calls are intended for applications that use
OpenGL directly, and there is no corresponding solution for Direct3D.

I suppose the situation would become slightly different if SDL was to
actively support applications using Direct3D directly.

The reason I mentioned mipmaps was that an addon library would
probably not be able to control it from outside the offical SDL
routine which uploads the pixels. If you wanted to use any of the
GL_XXX_MIPMAP_XXX filters then I think you would have to duplicate
all the code (figure out surface format and handle errors etc.)
whereas if it were directly in SDL then it would be very stable and
only a single ‘filter’ or ‘quality’ flag is needed for that
function, and a call to gluBuildMipMaps

Right… They’re probably too closely related to be separated in any
sensible way. It’s either all in SDL or all in an external library.

(if the glu dependency is not a problem)

Well, I don’t know… Is GLU always present where there is OpenGL?
How about the GLU header dependency when building SDL? What about
loading it dynamically? (Required as a result of SDL loading OpenGL
dynamically…?)

I have a feeling it’s better to just implement it using the SDL
blitters, or somehow leave it for the application to decide whether
or not to pull in GLU.

The other idea I had was that both the mipmap level and anisotropy
level could be stored somewhere in the internals of the SDL_Texture
struct inside SDL, so that these per-texture settings wouldn’t be
lost when SDL decides to re-upload the surface to the card (which I
figure SDL 1.3 will be able to do in some way).

…and SDL would of course need this information anyway, to be able to
restore the textures correctly. Probably not much point in trying to
maintain textures otherwise. (It’s different with glSDL and similar,
because the application on the other side of the 2D API has no say in
how textures are actually handled.)

Library users could specify these values once at texture load time
and SDL would automatically choose the correct settings for the
texture everytime it is uploaded again. This would be handy for
Windows when you switch from fullscreen to windowed mode etc.

Simple solution (from the SDL POV): A callback system that allows SDL
to have the application do whatever it needs to do when textures need
to be restored.

I understand that the preffered option is to put things in addon
libraries but in this case it might make sense.

It might also make sense to put all of this in an add-on library. :wink:

The library could hook into the SDL event system or something so that
SDL can tell it when textures need reloading.

The advantage of having it in an external library is flexibility. If
it’s designed to be done in an external library, SDL has to provide
the hooks needed to do it. This means you can use the "standard"
library, some alternative library, or you can do it in your
application. I’m thinking procedural textures, nonstandard mipmap
scaling filters and stuff like that.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 16 August 2006 18:54, Sebastian Posch wrote:

8

Simple solution (from the SDL POV): A callback system that allows SDL
to have the application do whatever it needs to do when textures need
to be restored.

This might be a stupid suggestion, but why not have the SDL throw a
new event type like SDL_SURFACE_RESTORE or whatever that gets posted to
the main queue, instead of having the developer register a callback
function/object…

Then you can listen for it and act accordingly with your texture data, or
ignore it if you don’t need it…

shrug

Erik Yuzwa
Wazoo Enterprises Inc.