I would really like to see a surface->gltexture formated surface function in
either the main SDL library or in SDL_image. Is there anything stopping
this? Has it already been implemented?
What for? Would it be a GLuint texture name or just something you could pass
into glTexImgae2D?
Either way, its not really appropriate.On Wed, Jan 10, 2001 at 12:03:36AM -0800, Gil wrote:
I would really like to see a surface->gltexture formated surface function in
either the main SDL library or in SDL_image. Is there anything stopping
this? Has it already been implemented?
–
Martin
Bother, said Pooh as Chewbakka ripped him in half.
Wed, 10 Jan 2001 Gil wrote:
I would really like to see a surface->gltexture formated surface function in
either the main SDL library or in SDL_image. Is there anything stopping
this? Has it already been implemented?
If I understand correctly what you’re after, I’m working on a library/engine
that includes something like this.
It could be a bit on the heavy side for what you want to do, though: My code
abstracts the textures as banks with N images each. When converting a surface,
it chops it up into tiles or sprites of specified size, then converts and
combines them into one or more quadratic power-of-2 sized textures, optionally
generating a border around each tile/sprite in order to get interpolation
right. More features to be added as I need them, although they may be biased
towards 2D rasterization.
(Further, I plan to implement a software engine using the same interface and
data types, so that 2D rasterization can be done without OpenGL as well - but
that’s another story.)
Of course, loading a single image into a texture is possible, as that’s
basically a simple special case of what this code is doing.
You can have the code if you want to look at it, but it’s more alpha than
beta. (Only deals with 24 bit RGB surfaces, does only batch loading; no single
image management etc.) If you need to get going right away, rather than rip
"usable" code from my lib, you’d better look at some OpenGL/SDL example or
something - for a simple texture conversion function, my code is a bit messy…
As to SDL and the API; don’t know what’s planned, but I’d contribute all or
parts of my library if it gets the job done and fits in.
The idea is that it should provide a 2D API that allows efficient
implementation using software rendering, 2D acceleration or 3D acceleration,
without forcing applications to mess with all the details of those targets.
There may be some kind of higher level 2D scene management, collision
detection, a basic physics engine and other stuff, but it’s too early to tell
how much of that can be implemented in a sensible way. (No point in creating
yet another library that’s either too complex or to limited for serious use…)
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.
//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 -’
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"
Now my reply for Martin Donlon:
What for? Would it be a GLuint texture name or just something you could
pass
into glTexImgae2D?
Either way, its not really appropriate.
This is what I meant, this code comes from the code for NEHEs tutorials
written by Sam:
SDL_Surface *ImageLoad(char *filename)
{
Uint8 *rowhi, *rowlo;
Uint8 *tmpbuf, tmpch;
SDL_Surface *image;
int i, j;
image = SDL_LoadBMP(filename);
if ( image == NULL ) {
fprintf(stderr, "Unable to load %s: %s\n", filename,
SDL_GetError());
return(NULL);
}
/* GL surfaces are upsidedown and RGB, not BGR :-) */
tmpbuf = (Uint8 *)malloc(image->pitch);
if ( tmpbuf == NULL ) {
fprintf(stderr, "Out of memory\n");
return(NULL);
}
rowhi = (Uint8 *)image->pixels;
rowlo = rowhi + (image->h * image->pitch) - image->pitch;
for ( i=0; i<image->h/2; ++i ) {
for ( j=0; j<image->w; ++j ) {
tmpch = rowhi[j*3];
rowhi[j*3] = rowhi[j*3+2];
rowhi[j*3+2] = tmpch;
tmpch = rowlo[j*3];
rowlo[j*3] = rowlo[j*3+2];
rowlo[j*3+2] = tmpch;
}
memcpy(tmpbuf, rowhi, image->pitch);
memcpy(rowhi, rowlo, image->pitch);
memcpy(rowlo, tmpbuf, image->pitch);
rowhi += image->pitch;
rowlo -= image->pitch;
}
free(tmpbuf);
return(image);
}
Rather then having to include this messy function in every project, I’d like
to have access to a version within SDL, so I cannot mess up during
reimplementation. Perhaps a call to SDL_DisplayFormat with an open gl tag on
the surface might convert the bitmap in this manner, then again a second
call would reverse the first… I still think it maybe appropriate for
SDL_image.
(/bait)
What do you think Sam?
This is what I meant, this code comes from the code for NEHEs tutorials
written by Sam:
[snip]
this function can essentially be replaced by a single call to
SDL_ConvertSurface after loading the image
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 -’
Thu, 11 Jan 2001 Mattias Engdeg?rd wrote:
This is what I meant, this code comes from the code for NEHEs tutorials
written by Sam:[snip]
this function can essentially be replaced by a single call to
SDL_ConvertSurface after loading the image
If everything is to be correct, SDL_ConvertSurface() has to do a y axis flip.
(Is this already supported? Couldn’t find it in the code…)
Anyway, how about using an SDL_Surface to wrap an OpenGL texture, as I
suggested in my previous post? Doesn’t seem too complicated in theory.
SDL_BlitSurface() would download to the card, while most other operations would
be disabled, just as for the OpenGL display surface.
Then one could implement SDL_BlitSurface() from texture surfaces to the
display surface… 
(Using the OpenGL API directly together with this would
require some attension, as the application could easily interfere with SDL
here. Not a problem for applications that just want to use OpenGL as an
alternative 2D rendering target, though.)
//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 -’