esrix
01-02-2006, 10:01 PM
This is indeed, going to sound very strange and unorthodox. But please know that there is method to my madness :)
I've been doing some R&D and graphical coding for a game with 2D sprites on a 3D environment ( I believe the expression is called "2-and-a-half-D"). Our game designer wants to use high-resolution sprites (512x512 pixels for each frame for each sprite!).
So, after some griping and toiling and posting on this forum, I managed to get the 512x512 sprites working with most memory issues resolved using SDL and some customized functions while running at a pretty decent speed (I'd explain this concept more, but it's too late at night).
The thing is, we've managed to make it as fast as it is now by using PNG images with a color index. Meaning the pixels in the SDL_Surface are referencing the color values from a palette, not really holding real color values in memory. It's much faster doing it this way instead of trying to load a full-on 32 PNG bit image at such a resolution.
However, this has now caused us a major problem. As far as I know, OpenGL uses 24 and 32 bit color and is not very supportive of color indexed textures.
I managed to write a function that gets around this... however, the function is too slow. While our loading and re-loading of sprite images manages a good 2-5 milliseconds each, the conversion from indexed image to 24/32 bit texture is a good 14-16 milliseconds! And we have more than one active sprite on the screen.
I know it sounds crazy, but as of now, this is the one obstacle standing between us and really nice looking sprites. So I was wondering if anyone has encountered a similar problem with OpenGL textures and indexed color images and, if so, how they managed to get around it?
I've been doing some R&D and graphical coding for a game with 2D sprites on a 3D environment ( I believe the expression is called "2-and-a-half-D"). Our game designer wants to use high-resolution sprites (512x512 pixels for each frame for each sprite!).
So, after some griping and toiling and posting on this forum, I managed to get the 512x512 sprites working with most memory issues resolved using SDL and some customized functions while running at a pretty decent speed (I'd explain this concept more, but it's too late at night).
The thing is, we've managed to make it as fast as it is now by using PNG images with a color index. Meaning the pixels in the SDL_Surface are referencing the color values from a palette, not really holding real color values in memory. It's much faster doing it this way instead of trying to load a full-on 32 PNG bit image at such a resolution.
However, this has now caused us a major problem. As far as I know, OpenGL uses 24 and 32 bit color and is not very supportive of color indexed textures.
I managed to write a function that gets around this... however, the function is too slow. While our loading and re-loading of sprite images manages a good 2-5 milliseconds each, the conversion from indexed image to 24/32 bit texture is a good 14-16 milliseconds! And we have more than one active sprite on the screen.
I know it sounds crazy, but as of now, this is the one obstacle standing between us and really nice looking sprites. So I was wondering if anyone has encountered a similar problem with OpenGL textures and indexed color images and, if so, how they managed to get around it?