glInit must be called once per translation unit (module)!

[yrro]

If you build the code at http://robots.org.uk/stuff/texture-testcase1.zip (devkitarm 21 and PAlib 20080203), you should get a grid of tiles, but every other tile will be corrupted.

The tiles are drawn by two identical functions; quad_me in the main module, and quad_me_not in the quad module. The different is that quad_me works whereas quad_me_not does not. I have no idea why moving this code to another module breaks texturing so I thought I'd ask here for help. Any takers?

edit: I've created a version that does not use PAlib (except for the arm7 code). It therefore builds with devkitarm 23b. Can be found at http://robots.org.uk/stuff/texture-testcase2.zip.

[cheesethulhu]

I don't know if this is actually a bug or just a design decision I don't understand. Either way, I recently ran into the same problem (without PAlib). videoGL.h creates a static pointer to some GL related data in each source file it gets included in. If glInit() does not get called from each source file that calls one of a handful of GL functions (in this case glTexCoord2f()), it ends up using an uninitialized pointer to that global data and therefore doesn't know the actual size of your textures.

One way to work around this (other than only using one .c file), is to include a function in quad.c that call glInit() and then call that from main() right after its call to glInit().

Code: Select all

/* in quad.c */
void
quad_c_glInit(void) {

	glInit();
}

Code: Select all

	...

	glInit();
	quad_c_glInit();

	...

You might want to change the name of this topic to something like "Must call glInit() from each source file".

[yrro]

Thanks for your reply, I'd never have spotted that myself.

[dovoto]

No idea how a bug so glaring made it this long without being noticed. Thanks, its definitely not a design decision (or at least not one I made).

Fixed and updated in the cvs.