Originally Posted by
Bubba
It's all about samples. There are more samples between time T and time T2 at 60 FPS than at 30 FPS. More samples will yield smoother presentation, more responsive devices, etc, etc.
I understand that. What's happening is there a delay of 15-20 frames from when the drawing routine runs to when the frame makes it onto the display. Consider this:
Code:
glColor4f(0.0f,0.0f,0.0f,1.0f);
if (!(reps%500)) {
printf("NOW\n");
glColor4f(1.0f,0.0f,0.0f,1.0f);
}
printf("*"); fflush(stdout);
reps++;
This is in the routine that draws the frame. The next object to be drawn is black, but once every 500 frames it will flash red, and also during that frame "NOW" should appear on the console in the background.
That does not happen. There is a very clear delay. Every frame an asterisk is printed. I sit with one finger on ctrl and one over the c key. As soon as I see the object flash red, I kill the process:
NOW
****************************************^C
In other words, at my current frame rate, there is a delay of almost a full second between when the code is executed and when the frame is actually rendered on screen.
The issue may be that I need to use a timer. I just went back to look at the OGL stuff I did before and low and behold, there is no such problem there. But in those, I used a one millisecond timer. I read in another forum that this was a bad idea and that you will get a faster frame rate by just allowing the drawing rountine to repeat as often as possible, and since I now want a game, I figured should stick as close as possible to conventional wisdom. Hopefully putting the timer back in will solve the problem.