SDL OGL Texturing

Include the "glext.h" header in the source file (if it doesn't come with the compiler, you can find it online). Then change the GL_BGR to GL_BGR_EXT. You should also check to make sure that the extension is supported, but it's a relatively safe assumption that it will and you're justing playing with the tutorial for now anyway (as far as I know)...

Or for a quick and somewhat hackish fix add #define GL_BGR 0x80E0 somewhere near the top of the file.

The problem is that Windows' OpenGL implementation is extremely out-dated. Since the tutorial port was written for "Linux/SDL" it was a safe assumption that GL_BGR was defined as it'd be difficult to find a default OpenGL implementation that was outdated so much it wouldn't work in *nix.



[edited by - Null and Void on January 27, 2004 8:47:57 PM]

Thanks so much, I spent about 4 days trying to figure that problem out by searching the net aand different forums and no answers.
I used the hack code and it worked perfectly, the include file "glext.h" wasn't found so i must not have it.
Just wondering if writing a function to swap the rgb to bgr is more efficient(better) or would the hack code suffice for a 3d game since all it does is swap colors and dosn't use the opengl api extensively if at all?

[edited by - mindemc on January 28, 2004 2:43:32 AM]

Manually swapping RGB to BGR should never be faster than just telling glTexImage that it''s BGR arranged data (though, if the driver is sub-optimally written, it could be the same speed).

The way you will probably want to handle it is to test for support of the EXT_bgra extension or if the OpenGL version is greater than or equal to 1.2 when the program starts (if you check at compile time for GL_VERSION_1_2 you can get false-negatives, so don''t completely rely on it; the MCD and ICD can have different versions, but the ICD cannot have a lesser version than the MCD). If either of those are true, you can just rely on the GL_BGR constant. If nothing indicates you have BGR support, you should swap the data and use RGB instead.

I suppose you could just have your program fail to run (spit out an error and die) if BGR support isn''t there, but that''s a big hostile to its users (albeit only a tiny potential percentage of them).

If your code is robustly written, all of this can be handled transparently without you needing to worry about it more than once.

By the way: a version of glext.h can be found here, found on the same page as the extension registry. It might not be completely up-to-date. Personally, I maintain my own extension header inside my toy-engine as I wanted it to be setup "just-so" and it''s easier than ensuring the build environment''s glext.h is completely up-to-date.