Long time lurker, first time poster. Really appreciate the forum - got some great tips from here on a variety of subjects to do with Android/Java!
I've started working on a little project, the first part of which I thought I had sorted earlier today. The first part involves being able to have a cube move around a playing field by clicking in one of four places (top left bottom right). The animation appeared to be fine so I changed about the texture and UV map to ensure it was infact rotating correctly. It all seems to work ok UNTIL the animation portion is over - and even then only for certain situations.
Example: in the video linked below you will see me moving the cube up, down, left and right. As you can see, that renders fine. Then I move it up one square and left one, then right one. On both these movements the rotation goes a little bit..squiffy. Instead of rotating on the x and y axis, it appears to be applying rotation to the z axis (note that the direction the number faces changes). The same happens if I move it down one square and move it to the left or right.
Here is the code from my draw loop. This is based off of the NeHes tutorial #6 ported to the Android - the only changes to the cube class being a modified UV map and texture.
cubeMoving: an integer that acts as a flag to determine which direction the cube is moving in cubeMovingStep: an integer that acts as a progress marker for the animation cubeXPos/cubeYPos: integers that determine the position of the cube based off of the default orientation cubeXState: a float that stores the incremented rotations gained from cube movements
If anyone can provide any insight as to why this might be happening, I'd be greatly appreciated. If you need any further code I can provide it.
After alot of thinking, and scratching my head I think this is more to do with how I'm tracking the rotation of the cube. Due to it moving around the board it is not a simple matter of keeping track of and restoring the rotations. As the attached scribble shows, this is more of a logic problem than a problem with the OpenGL code.
After further deliberation, I believe the above problem arises due to the fact when you rotate with glRotatef any further rotations are subject to any prior transformations/rotations. Due to this constraint, I must apply a single rotation that accounts for both the X and Y rotation. This I think must be done using Quaternions.
I've spent time looking into 'Quaternions', with some success but mostly befuddlement. I'll keep trying.