Controlling frame rate

I have a problem in that my graphics tend to execute so fast they're almost a blur, probably because my GPU is pretty new.

I've tried to follow the glutTimer method described in the text book, but I have to set the frame rate *very* low to notice any appreciable difference, and then the image stutters. Is anyone else having issues with frame rate? Any thoughts?

Do all your applications execute fast? Or just the one for assignment 2?

Everything. In assignment 1 I couldn't actually see my man spinning, it was just a blur. Obviously once you freeze it, you see the image.

Id google the problem or ask the lecturer.
Maybe something is wrong with your compiler.

make sure you call glLoadIdentity(); everytime a frame is redrawn. i.e. put it in your display() function.

Just add a for loop that does nothing in your idle func:
for (j, j++, j<1000000);
This will slow it down.

Wondered a bit about this last year too, particularly as you can't be sure what kind of machine your code is going to be tested on by the markers. In general if things are too fast I would say take advantage of it, and use smaller increments for angles, or moves or whatever, which will give you nice smooth animations. Artificially slowing things down has pitfalls for others.

For something like a game that you wanted to distributed you would have to get into controlling actual frame rate with timers and some other nasty stuff, as you need it to run at the same speed everywhere. For the assignments however, I figured it was more sensible to make everything adjustable with keyboard callbacks (or other controls). For the gas particle example, you could just adjust the distance the particle moves at each calculation... if you have a fast machine you can adjust it to be very small, and get a nice smooth path, while a slow machine, you would want big "jumps" so that it at least goes somewhere. Turned out actually to be quite fun to be able to to adjust it anyway.

The worry about putting in dead loops like Bondiridhoo suggests though is that what happens when you are running on a slow machine... it takes ages to do the calculation, and then you make it wait too! So slow becomes ultra slow.

I also try to use the timer routine but because I have the opposite problem. I have an _emulated_ gpu. I like to be able to still use my pc while the examples are running . the times seems to work for me though. post one of your timer apps (like the spinning man) maybe you're doing something wrong...

I think my GPU is just really fast. What I have found out is that overloading models with mathematical calculations slows and smooths the frame rate. For instance, doing recursive subdivision of triangles for the sun and moon in assignment 3 makes the model spin nice and smooth and easy to see, whereas the original model was spinning so fast you couldn't even see the moon.

Why don't you store the time at the begining of the programme and then in each frame update, calculate the elapsed time since the last update.

If you know your objects must rotate x number of degrees per second then you can work out the degrees to rotate for this particular frame.

This should have the effect that the rotation will be normalised no matter how fast your computer is. The only difference is that on faster computers, there will be more frames per second (and hence your degrees rotated per frame will be smaller) and on slower machines, your frame rate will be slower.

Let me give a little example. Say you want your Earth to rotate once a minute, that would convert to 360 degrees every 60000 milliseconds. There is a windows API function that returns the system time (to the nearest millisecond) called timeGetTime() and returns a DWORD (a typedef of unsigned long).

You can call this function at the beginning of the programme and store the start time in a global variable. Each time you update your frame, you calculate the time elapsed since the beginning of the programme and modulate that by 60000 (so your time will always be between 0 and 59999) then divide by 60000 (to get the fraction of a rotation per minute) and then multiply by 360 to get to degrees (or equivalent to get to radians). This will give you a value for the specific rotation amount for that frame.

As you can work out, the faster your computer, the more frequently you will call the frame update and the smaller the elapsed time. The smaller the time, the smaller the angle. All-in-all, fast and slow computers should rotate the Earth once ever minute. Faster computers will just have a smoother feeling of animation.

If your computer is super-fast and can update more than once every millisecond, then unfortunately, you'll be wasting time until windows updates the timer. With this algorithm and the timer function, the maximum number of frame changes you can do is 1000 per second.

Hi guys,

I discovered that when u use

glutSwapBuffers()
glutPostRedisplay()

after

glFlush()


it really smooths out the display. Do not use delay loops any more.
Also make sure that these lines are at the end and appears only ONCE in the display functions. Do no use timers. (don't know ifu need to use double buffering..?)

Hope this helps....