[SDL] SDL under Windows, and more....?

Marco Iannaccone marciann at tin.it
Sun Jan 28 05:48:46 PST 2001


Thu, 11 Jan 2001 Gil wrote:
> I'll tackle two birds with one stone, since the answer two both questions
> are related:
> 
> First my reply to David Olofson:
> 
> > Various generic tool functions (such as the surface/texture management)
> could
> > probably be ripped out and placed in a stand-alone library, possibly
> included
> > with the main SDL distro, if the complete library becomes too big, complex
> > and/or specialized.
> 
> Read my other post.. Your library would do the trick, but the changes I'd
> like to see made to SDL are trivial.. Basically I think a function which
> "converts to the correct orientation and bit configuration for use with
> opengl, and trucates the surface to 2^n height and width"

Ok; perhaps not as trivial as the function below (what about other formats,
prucedural textures and other stuff?), but still not exactly a huge project.

I don't know about the truncation part, though... Stretching with
interpolation would probably be more appropriate - if non power-of-2 sizes are
to be allowed at all, that is. The same goes for non-rectangular images; they
could be - stretched as needed if the card doesn't support non-rectangular
textures. In both cases, the function should check with the OpenGL driver and
then use the best method.


As to the implementation, does anyone have this kind of code lying around? (If
not, I'll just have to hack it. Either way, I'm obviously not the only one who
could use this basic texture conversion function.)


And speaking of implementation, any ideas for an API to deal with partial
texture updates? (I'll need that in order to deal with sprites and tiles as if
they had their own textures, without having to upload the entire bank texture.
This is required for procedural sprites and tiles, pixel effects and the like.)

I was thinking along the lines of sticking with the usual integer surface
coordinates (pixels with top-left = (0,0)). In other words, something like
SDL_BlitSurface(), but with an OpenGL texture as the target, doing any required
conversion and flipping on the fly. (If the source surface is using the same
pixel format as the OpenGL texture, only flipping is needed.)

OpenGL textures should probably be abstracted as SDL_Surfaces for all this to
be truly useful and still efficient... Creating an SDL_Surface in system RAM
would create an ordinary surface with a suitable pixel format + a flag
indicating that the y axis is flipped. (For software rendering code to map the
y coords properly.) That way one could do various operations on a surface, and
then download all or part of it directly to the 3D card, without a conversion
step.


//David

..- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'



More information about the SDL mailing list