Caanoo / WIZ Wiz/caanoo - Issues With Glteximage2D And Gltexsubimage2D


dust32

Still Fresh
Joined
May 2, 2012
Messages
2
Hello guys,

I'm not new to OpenGL and graphics programming and I'm currently developing a simple OpenGL ES based portable utility toolkit similiar to GLUT, which is intended to work on the Wiz, the Caanoo and on Win32 using an OpenGL ES emulator in order to facilitate development and debugging.

When implementing some dynamic texture atlas functionality I've encountered heavy problems while using glTexSubImage2D on the Wiz, while on the Caanoo and the OpenGL ES emulator everything worked perfect. What happens on the Wiz is, that the uploaded sub image is horizontally shifted by roughly 4 pixels, i.e. the right border of the uploaded sub image appears on the left side of the specified destination rectangle. This effect does not depend on the pixel format of the input data, but it seems that it depends on the width of the sub image. I did not mess up the scanline aligment and pitch issues, because on Win32 using the OpenGL ES emulator no problems occur.

The other issue i've run into, is that on the Wiz when uploading 32bit RGBA / 24bit RGB texture data through glTexImage2D the color channels seem to be uploaded in a different order in comparison to the Caanoo or the OpenGL ES emulator. This is also true for the 16bit pixel formats.

The last problem, which occured, was that my Caanoo and my Wiz crashed with a seg-fault when trying to upload some 16bit pixel format textures and then some 32bit pixel format textures. This was not caused by any null-pointers, or wrong addresses because everything worked fine on the OpenGL ES emulator under Win32.

It seems to me, that the Wiz OpenGL ES driver has some bugs concerning texture upload functionality in comparison to the Caanoo driver. I'm using the OpenGLES libraries from the latest version of the Wiz firmware.

Can anyone confirm these effects or did encounter similiar problems?

Is there a solution or a workaround?

Thanks,
{dUSt}
 
I don't remember having any specific problems with textures. The only display corruption issues I experienced where caused by:

* Forgetting to shut down gp2xmenu
* Initialization of graphics context
* Insufficient cleanup of graphics context (affects programs running afterwards)

Here [1] is the code that works for me. It uses the "onboard" libSDL to initialize the graphics and then sets up a GL context. Also uploads textures in either RGB_5_6_5 or RGBA_5_5_5_1 format.

[1] http://svn.gna.org/viewcvs/*checkout*/freeeq/trunk/libtmepp/src/rendererwiz.cpp

Edit: Posted "plain" link because url tag did not work...
 
hmn said:
I don't remember having any specific problems with textures. The only display corruption issues I experienced where caused by:

* Forgetting to shut down gp2xmenu
* Initialization of graphics context
* Insufficient cleanup of graphics context (affects programs running afterwards)

Here [1] is the code that works for me. It uses the "onboard" libSDL to initialize the graphics and then sets up a GL context. Also uploads textures in either RGB_5_6_5 or RGBA_5_5_5_1 format.

[1] http://svn.gna.org/viewcvs/*checkout*/freeeq/trunk/libtmepp/src/rendererwiz.cpp

Edit: Posted "plain" link because url tag did not work...

Thank you very much for your help. I now had time to do some additional tests. I generated some artifical textures in memory and directly uploaded them using glTexImage2D and glTexSubImage2D. It worked perfect for WIZ and CAANOO. No swizzled color channels and no offset artifacts, when uploading sub textures. After performing some more tests I realized, that the problem is not WIZ's OpenGL ES driver implementation, but that the problem in reality is SDL_Image, which I use to load texture images from file.

I've prepared a single 32bit texture image and stored it as a BMP, TGA, PNG and an JPG image using Paint.NET. On the Wiz the TGA texture was totaly broken, the PNG texture did not load (i.e. it was empty ), the BMP and JPG texture had swizzled color channels.
On the Caanoo, all four formats did load, but for PNG and JPG the red channel and the blue channel were swapped. I've linked dynamically against SDL_Image, so I think, that the binary versions preinstalled on the WIZ/Caanoo of these libraries are used.
 
Last edited by a moderator:
{dUSt} said:
On the Wiz the TGA texture was totaly broken, the PNG texture did not load (i.e. it was empty ), the BMP and JPG texture had swizzled color channels.

I remember having problems with loading PNG files through SDL_image. Try copying libpng.so.3 (aka libpng.so.3.29.0) from the Wiz SDK (lib/target) next to your binary so it gets used by SDL_image instead of the onboard one. That worked for me when I ported the Zelda clones.

Interestingly enough, in my code that uses (onboard) libpng directly, I did not experience any problems...
 
Last edited by a moderator:
Back
Top