i think its win32 yes, but there has to be a *nix/mac version of it... (there is something in sdl if im not mistaken, and you could always use the performance-timer, which is very precise)

But anyway, if you use a variable framerate, and your OS suddenly requires more power for applications running in the background, some frames will just be skipped, but the game will update as if it never happened.

If you use a static fps-rate though, the game will update less times than it was supposed to. That doesnt have to be a problem, but it might. It can result in things no longer running synchronised.

But hey, its all up to you. Using a static fps-rate is easier to implement though, since you always know how much an animation should increment

A small side question: Is there anybody who knows the performance difference between timeGetTime() & GetTickCount()?

Don''t rely too much on these figures - they come from my timer class and will be a bit inaccurate because the profiling has to be done very quickly. It appears that GetTickCount is better that TimeGetTime because it has a lower execution overhead.

GetTickCount:
include: windows.h
frequency: 1000?
function: GetTickCount()
Timer Profile (GetTickCount):
Frequency: 1000Hz
Resolution: 0.001s
Error: 0s
Speed: 3.52e-08s

TimeGetTime:
include: windows.h
frequency: no easy method?
function: timeGetTime()
Timer Profile (TimeGetTime):
Frequency: 1020Hz
Resolution: 0.000980392s
Error: 0.0872549s
Speed: 1.39124e-07s

Enigma

"and your OS suddenly requires more power for applications running in the background, some frames will just be skipped, but the game will update as if it never happened."

If you do a fps counter function that should never happen, each time it goes though my render loop i have a += to the FPS. So each FPS it gets a accurate count. This way i get a count of how many times a motion is called per second (equil to the frame rate).

Is there somthing i dont know that could cause my FPS count to be wrong? Again I'm not triing to debate, just make sure I'm not setting myself up for big problems


[edited by - skow on June 30, 2003 5:06:04 PM]

Well i finally think i found what he was talking about. Where your framerate will drop suddenly , and for a brief few mili seconds your speeds will be messed up.

I'm deturmined to have a multiplier to adjsut for the frame rate. So this time i based my multiplyer off the time a frame takes to render. I did it where it was based of individual frames, but it was too jump so i used a blend function.

Basicly i have this called every frame

        float gspeed=0; //This one is a global	static float gspeed1 =0;	static float gspeed2 =0;	static float gspeed3 =0;	static float gspeed4 =0;	static float frameTime = 0.0f;				        float currentTime = GetTickCount() * 0.001f;        gspeed1 = currentTime - frameTime;        gspeed = (gspeed+gspeed1+gspeed2+gspeed3+gspeed4)/5;	gspeed4=gspeed3;	gspeed3=gspeed2;	gspeed2=gspeed1;	frameTime = currentTime;

This smooths the frame draw time over 5 frames so it has smooth transitions. This also happens fast enoughwhere if you drop to 1/2 the frames per second it adjust fast enough to where you cant really notice. The multiplyer i would tack on is gspeed. It seems to work pretty good.

Any one have any suggestions or see any problems with this method?


[edited by - skow on June 30, 2003 12:46:36 AM]

My apologies for my poor explanation Im new to this forum, and also Dutch (cant help that )