Ok. I have made a small game, and when I run it in 64048032 I get around 200 frames per second and animation runs silky smooth. But when I up the resolution and color depth and I get 150 frames per second the animation runs choppy. WHY?
The animation is simply moving a couple of cubes upwards using glTranslated(), my distance variable is a GLdouble, my speed variable is a GLdouble, and I use a performance counter for the timing (distance += speed*time).
I was thinking that the problem might be that I’m not very zoomed out (the camera is positioned 18 units away from the center of action).
So moving a cube from the lower part of the screen to the upper part is moving it about 20 units. Could that be the problem? Should I move the camera back and just make the cubes bigger?
I have some special case optimizations that take the distance to the camera in mind. So I really don’t want to up the scale of my level-system, but if that’s the problem I guess I have to.
I use a performance counter for the timing (distance = speed*time).
Ok lets just work on some example figures
640x480 100fps render time = 0.01sec
800x600 50fps render time = 0.02sec
1024x768 20fps render time = 0.05sec
speed = 10
so at
640x480 distance = 100.01
== 0.1
800x600 distance = 100.02
== 0.2
1024x768 distance = 10*0.05
== 0.5
ok so at 1024x768 when your object moves it is actually moving futher than it would in 800x600, in this case 0.5 units instead of 0.2 units. Now comparing 1024x768 to 640x480 there is a 5 time difference in the amount your object moves, 0.5 vs 0.1 units.
If you want your movement to be smooth develop at the extpected display resolution then if your timing is correct it will look and run fine in lower resolutions.
You will always get choppyness with a card that is to slow or a resolution that is to high. The timing is what actually causes it in your higher resolutions.
That CAN’T be it!
First of all. The speed isn’t that high. It takes about 1 second for the object (with the intended speed) to move from the bottom of the screen to the top.
So, at 150fps (where I get jirky animation. As in 15 pixels movment at a time) you have 6.6 ms per frame. The speed is 0.01595 units/ms.
That’s 0.106 units. Which is 1/170 of the screen in the Y (it’s about 18 units high from where I’m looking in my scene) which equals 3 pixels per frame. So the block should move 3 pixels per frame. But it’s not anywhere near that smooth!
I would estimate 15-20 pixels per frame. I mean it’s REALLY jirky.
I mean, Quake3 is silky smooth at 60fps, why do I need 200+ frames per second to get smooth animation in my simple little crappy program?
Can’t it be that I don’t get enough precision on my translates because I move to little at a time? It would take me hours to redo the scale of my program so I really don’t want to do it for nothing.
Does it matter if you move 0.001 units or 100 units in terms of precision?
I had a problem similar to this one in a game I was making. It was caused because I was putting my values for the number of clock ticks between frames into a float instead of a long. I don’t know why it screwed everything up, but it did. This probably isn’t the cause of your problem, but you should check just in case.
Only other thing i can think is that your are not using double buffering technique. Ensure you have double buffering enabled. No double buffering is a sure way to get jerky movements.
It doesn´t matter if you have 150 or 200
or 100000 frames per second as long as
the swaping of the buffers is not in sync with your monitor refreshing .
The reazon you are not seeing it in quake is because the kind of motion of this game, tearing and jerkiness is a lot more visible in horizontal & vertical movement.
Try to get in sync with the vertical retrace
of your monitor, for example if your monitor is set to a resolution of 1024x768
75 hz , 75 frames per second is enough as long as it´s in sync with the refresh rate.
glFinish & glFlush have nothing to do with
the vertical retrace, to deal with it, you should install an interrupt routine , this is
something more complicated & very specific on the platform you are working on, on the Mac for example you can look
for sample code obout VBL tasks.
On windows & Unix I have no idea but I am shure OpenGL has no comands to handle interrupts.
WGL_EXT_swap_control doesn’t necessarily enable vertical sync. This may be disabled in the video card’s driver settings (See advanced display properties in Windows)
if your refresh rate is (60htz) 60 refreshes per second = 1 refresh every 0.0016 second. now each time your proggy does 1 cycle it may take it 0.0020 second this means you have missed the vbl at 0.0016 second and must wait for the one at 0.0032 second. Hence a small delay.
oops