[Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Hello!

In August 2005 I wrote to this list asking what you'd think about
exposing the bitmap loader functions from SSG. This would allow
PLIB users to use these loaders for more than only texture loading,
or it would simplify writing more complex texture classes for
SSG. During the last 1.5 years I didn't find the time to start the
project for which I needed this, but now it would really come in 
handy.

Background: I need to load a huge image (bigger than GL_MAX_TEXTURE_SIZE
in usual OpenGL implementations) and split it into smaller
tiles. Then each tile will be used to create a texture. With the
current SSG API I'd have to write my own bitmap loaders, because
each loader automatically invokes ssgMakeMipmaps() and then
discards the pixel data.

So what I suggest is basically the following:

- Each bitmap loader provides a new public function "ssgLoadFOORaw()"
  or something similar, which opens the file, allocates memory
  for the pixel data and loads it into memory. This is basically
  what the existing "ssgLoadFOO()" functions do, but they do two
  more steps: they implicitly call ssgMakeMipmaps() which then
  will free the pixel data.

- A replacement "ssgLoadFOO()" calls "ssgLoadFOORaw()" to load the
  file, then creates the mipmaps and discards the pixel data.

So this wouldn't change the existing API in any way. It would just
expose the functionality of the raw pixel loader functions to
make them useful for the user. Internally it's ideally just one
more function call when loading a texture, so this shouldn't
really hurt in any way. Again, it's no additional functionality,
it's just a matter of splitting the existing loaders into two
separate, useful pieces.

Of course I'd prepare the patches with these changes.

What do you think?

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de