PDA

View Full Version : Vincent gives upside down mirror image output!!!



GreatApe
04-17-2005, 10:44 PM
I was working some OpenGL ES code on the Nokia v2.0 Open GL SDK, I based how did my Open GL code on on the Example3D game from Nokia, all worked fine upto this point.

I then made a build of the project under the UIQ SDK using the Vincent OpenGL ES implementation, I got this working only to find the whole display was an upside down mirror image of how it appeared under the S60 SDK.

To check it wasn't just me doing something silly I ported the Nokia Example3D project over to the UIQ SDK and sure enough exactly the same problem.

Going back to the original version I had noticed the Y-Axis did seem to be wrong way up, increasing the y-position of an object moved it down the screen.

Trying to understand what's going on here I've been looking at the example (and my code copied from it) uses glLoadMatrixx. The second and third columns all seem to be negated, why is this being done? I can't really get my head around all the complications here, trying something as obvious as making the main 3 columns non-negative, or all negative doesn't give any sensible result, the code I'm looking at is as follows from CPolygonObject.cpp.

// Generate rotate matrix for OpenGl from example's rotate matrix
GLfixed mat[4*4]={ (*aRotateMatrix)[0]*mul, -(*aRotateMatrix)[4]*mul, -(*aRotateMatrix)[ 8]*mul, 0,
(*aRotateMatrix)[1]*mul, -(*aRotateMatrix)[5]*mul, -(*aRotateMatrix)[ 9]*mul, 0,
(*aRotateMatrix)[2]*mul, -(*aRotateMatrix)[6]*mul, -(*aRotateMatrix)[10]*mul, 0,
(*aRotateMatrix)[3]*mul, -(*aRotateMatrix)[7]*mul, -(*aRotateMatrix)[11]*mul, 1 << glShift };

// Init OpenGl for drawing
glLoadMatrixx( mat );

dorbie
04-21-2005, 10:24 PM
It's negating elements in your matrix? I don't know what's going on there, I am skeptical about this claim. That would be bad behavior regardless of the correctness of the result. However it this is your app code doing this it's completely misleading information, it's up to you to understand your own app.

This sounds like something as trivial as descending vs ascending display image y axis.

Nothing should be reversing user specified matrices, it should be handled internally probably by the back end rasterization or the internal viewport transformation if that's fixed, you should see no platform to platform difference looking at the matrices (again unless this is your app in which case you should be fixing your code not posting).

One test would be to loadidentity model and projection matrices and then move an object on screen with a simple viewport (yea take a good look at your viewport call and make sure it's legal).

Regardless of native screen Y addressing (often +y = down), OpenGL +Y should be oriented up so implementations which do this do the right thing.

One possibility is that it's working and the issue is physical display orientation of the devices you're using, assuming that the platform has some concept of diaplay orientation.

Start with figuring out whether +y is up and +x points to the right with identity matrices and then you will know for sure which implementation is correct.

[ April 22, 2005: Message edited by: dorbie ]

hmwill
04-22-2005, 05:23 AM
AFAIK this is an artifact inherited from the Windows Mobile version that has not been addressed yet. For Windows Mobile, the bitmap is set up such as increasing y-coordinates go up on the screen. (I.e. bitmap coordinates are the same as GL coordinates)

I'd assume that the blitting code in eglSwapBuffers has not been set up correctly in the current Symbian build.

So Symbian support is still work in progress, which is why there are no 'official' builds available yet.

Hope that helps.

- HM

GreatApe
04-25-2005, 12:41 AM
Thanks for the responses, it certainly does appear to be do to with the low level bitmap format, I had a quick look at sorting it out in the code but doesn't appear to be any easy quick fix.

don
04-26-2005, 04:09 PM
hm,

If you're creating a DIB section selected into an offscreen DC for the back buffer in your Windows Mobile version, you can set the BITMAPINFOHEADER::biHeight to a negative value when creating the DIB section and that will create the more common "top-down" DIB (origin at upper-left corner).