Originally Posted By: EvilSOB
Only reason (that I can think of) that fraps may affect it is to lower the 3DGS framerate cause
fraps is using horsepower.
Try putting fps_max = 60; at the start of main to see if anything changes.


Awesome, a fps max of 60, the animation was normal for about 180 seconds. Then I set the max 40 and it remained normal for 270 seconds. At 30 I was able to have the animation remain normal for the whole duration of the trial engine. Woot! Though it got me a little confused because I always thought the higher the fps the better. Until I read the section on frame rate in the manual..

Why would you want to decrease the frame rate? There are three reasons. Your movement functions might only work properly within a certain frame rate range, and fail at 1000 fps. You won't want your application to consume all the CPU cycles. And most important, you want to avoid stuttering. Stuttering means a camera and actor movement that appears unsteady. It won't be noticeable in a game with complex levels and medium frame rate, but mostly in games with almost empty levels, little content, and consequently very high frame rate that is then capped by fps_max.

The main reason for stuttering is a coarse PC scheduler resolution that leads to inaccurate task start times, especially when many tasks are running on a particular PC. This problem can be avoided by limiting the frame rate not only with fps_max that just gives task time back to the Windows task scheduler, but by really burning CPU cycles in some or the other way. Fortunately, this is easily done. If your game experiences stuttering, just place some more details in your levels for avoiding a too-high frame rate.


So I assume this could be happening because my project and the workshops are, as of now, too simple and when I add more things to the level then I may not have to limit the fps. Thanks very much Evil!