SDL_image to OpenGL Texture loading

SDL Development
1

################################################################################
I’m looking around for a cross-platform solution to loading textures for use
with OpenGL and SDL_image seems to be a viable solution. I’ve played around a
little with it so far, compiled with the examples from the Doc Wiki but havn’t
been able to find anything I’m completely happy with.

What I need is the following:

  • The ability to load any of the image formats that SDL_image is able to load
    reliably across multiple platforms.
  • The ability to cater for different bit sized formats ( ie 8 / 24 / 32 etc bit
    images ).
  • Loaded images that are correctly oriented for OpenGL conventions (ie the image
    starts in the lower left corner).

Are there any Open-Source solutions avaliable for this? Or does anyone have any
code avaliable that will accomplish the above?

Cheers,

2

What I need is the following:

  • The ability to load any of the image formats that SDL_image is able to load
    reliably across multiple platforms.
  • The ability to cater for different bit sized formats ( ie 8 / 24 / 32
    etc bit images ).

SDL_image does all of this, but you’ll need some glue code for making the
OpenGL textures. (Since probably almost every project using SDL_image and
OpenGL has code doing more or less the same, perhaps this could be added
on to some later version of SDL(_image)?)

  • Loaded images that are correctly oriented for OpenGL conventions (ie
    the image starts in the lower left corner).

Umm, this convention doesn’t apply to textures, AFAIK.

In texture space, (0,0) is the “beginning” of the texture data fed to
glTexImage. (x,0) always belongs to the first row of the texture data,
(x,1) belongs to the second row, etc. glTexImage doesn’t have any notion
of directions as in up/down/left/right or or upper/lower corners. It only
is given texture data as a sequence, and the only sensible thing to do
with that is to map (0,0) to the beginning of that data.

Indeed, this seems counter-intuitive if you map a rectangle with e.g.
corners in (0,0), (1,0), (1,1), (1,0) and have texture coordinates set to
the same as their vertex coordinates.

Some confusion on this seems to stem from some NeHe tutorial, which used
some really primitive BMP loader which didn’t flip the image data (BMPs
are stored upside down for some reason), and thus (0,0) of those textures
became the lower left corner. In some SDL port of those examples the
texture coordinates had to be flipped, and this was blamed on SDL (or
SDL_image) even though it originally was due to usage of a primitive
function where it’s flaws accidentally matched some incorrect assumptions.

If you still like and want this kind of behaviour, you can of course flip
the image data manually before uploading it.

Are there any Open-Source solutions avaliable for this? Or does anyone
have any code avaliable that will accomplish the above?

Almost any GL/SDL project contains code which does this. You can also
take a look at testgl.c in the test directory in SDL.

// MartinOn Tue, 27 Jun 2006, Mathew Byrne wrote:

3

Martin Storsj? <martin martin.st> writes:

Umm, this convention doesn’t apply to textures, AFAIK.

In texture space, (0,0) is the “beginning” of the texture data fed to
glTexImage. (x,0) always belongs to the first row of the texture data,
(x,1) belongs to the second row, etc. glTexImage doesn’t have any notion
of directions as in up/down/left/right or or upper/lower corners. It only
is given texture data as a sequence, and the only sensible thing to do
with that is to map (0,0) to the beginning of that data.

Indeed, this seems counter-intuitive if you map a rectangle with e.g.
corners in (0,0), (1,0), (1,1), (1,0) and have texture coordinates set to
the same as their vertex coordinates.

In all the 3d packages I’ve worked with, and AFAIK with general OpenGL,
this convention is used. I tend to like it as it matches up nicely with
the default OpenGL coordinate system and cartesian coordinates in general.
In an imaging sense it seems counter-intuitive however in a 3-dimensional
scene, it’s often neater and more consistent to use the bottom-left texture
coord conventions.

Thanks for the info, you’ve put me on the right track.