Advertisement

Unexpected rotations results (Lesson9)

Started by April 12, 2005 09:33 AM
1 comment, last by bearS 19 years, 10 months ago
using tut 9 moving bitmaps I (as usual) try to extend the functionality. I however got an unexpected result after implementing rotation araund the z-axis:

//adding global
GLfloat roll=0.0f;			// roll -rotate omkr z 

//in draw code:
	for (loop=0; loop<num; loop++)						// Loop Through All The Stars
	{
		glLoadIdentity();								// Reset The View Before We Draw Each Star
		glTranslatef(0.0f,0.0f,zoom);					// Zoom Into The Screen (Using The Value In 'zoom')
		
        glRotatef(tilt,1.0f,0.0f,0.0f);					// Tilt The View (Using The Value In 'tilt')
		glRotatef(roll,0.0f,0.0f,1.0f);					// roll The View (Using The Value In 'roll')		
		
		glRotatef(star[loop].angle,0.0f,1.0f,1.0f);		// Rotate To The Current Stars Angle
		//glRotatef(star[loop].angle,0.0f,0.0f,1.0f);		// Rotate To The Current Stars Angle		
		
        glTranslatef(star[loop].dist,0.0f,0.0f);		// Move Forward On The X Plane
		
        glRotatef(-star[loop].angle,0.0f,1.0f,1.0f);	// Cancel The Current Stars Angle
		//glRotatef(-star[loop].angle,0.0f,0.0f,1.0f);	// Cancel The Current Stars Angle		
		
		glRotatef(-tilt,1.0f,0.0f,0.0f);				// Cancel The Screen Tilt
		glRotatef(-roll,0.0f,0.0f,1.0f);				// Cancel The Screen roll		




//in ctrl section
	if (keys[VK_RIGHT])
				{
					roll+=0.5f;
				}



(and opposite for left of cause) But this does not work. The stars does not face the (camera) viewer at all time Any one see why? ------- wow -that formatted code -realy- badly I'l try to recopy it from dev / no- not a lot better -..
regards a.
I haven't looked at the way your draw yet, but I know the line:
if (keys[VK_RIGHT]){   roll+=0.5f;}

Will cause problems because of the way windows input works. If you are not using some sort of means ot limite your FPS, or do time based movement, then if the user hits the right arrow, more than likely roll is incremented by a number lager than 4.0f. You can try to add a keys[VK_RIGHT] = 0; after the roll+=0.5f; call and see if the movement is causing a problem as well. That probabally is not the problem, but something to watch out for because if the variables get to large, you get some strange looking OpenGL momements. [wink]
Advertisement
yes u are right but timing control is not covered before mutch later -for now the key opdate will do :) (as it also is implemented this way for the tilt)
regards a.

This topic is closed to new replies.

Advertisement