ok i've looked at form code and i cant find a way to make something that draws on my form with a certain FPS, i dont know where to make a loop and i dont know how to make a good loop, i've searched the board but couldnt find anything usefull or sources to look at :(

so, how do i make a loop that does some calculations and then redraws on my form with a certain FPS?

Thnx, Scorpie
Posted on 2004-12-19 13:29:03 by Scorpie
Try to draw it as fast as you can, then add some code to find out how fast that is :) Don't get so hung up on semantics man.. the goal is the draw it as quickly as possible, thus achieving a high framerate...
Posted on 2004-12-19 13:41:21 by Homer
but where do i put this code? and how make it redraw the window then?
Posted on 2004-12-19 14:09:37 by Scorpie
you can use a frame limiter: (easiest)

while(1) //gameloop
{
time_a=currenttime()
draw a lot of stuff
wait until (currenttime()-time_a > some_hardcoded_delay)
}

where some_hardcoded_delay = 1/desired_updatespeed_in_hz

or you can keep track of the elapsed time as kind of "delta time" and make all your movements and calculations depending on this.

for getting accurate time you should use QueryPerformanceCounter together with QueryPerformanceFrequency.
Posted on 2004-12-19 15:21:35 by lifewire
In order to get the current fps, you need to introduce two things: a way of getting the "machine time" in the lowest possible resolution, and then add a couple of variables to keep the start time and current time in, and also a counter to count the frames.
You should render the scene, then get the time that has elapsed and if it is less than one second, increment the fps counter, otherwise, if it is above one second, the fps counter holds the result, note it, reset your counter(s) and continue.

Framelimiting is what I call hard-limiting or capping.
It assumes that the mean fps remains above the cap value.
Supposing you check the full framerate and find its around 330 fps,
but you want to hard-limit it to 30fps, you could do it the lazy (glitchy) way by rendering 30 frames (counting them) then waiting until the next Second of time, or you could be more clever and grab the time either side of your Render code (and Update?) code (thus timing a single Frame worth of computation) and then calculate the delay necessary to wait until 1/desiredFPS has elapsed, while still watching the overall FPS for the reset condition.. this way the frames are spaced out over the denominational timeslice, and this will matter when you start messing with physics, ie collision detections of moving objects etc.
Posted on 2004-12-19 22:00:17 by Homer
IMHO there is no need for the FPS to exceed 30. The human eye can distinguish only about 16 FPS.

If all your computations can be done well within some 30 ms, I would suggest the following:
1- Get the base time (in ms) at the start of the program with GetTickCount, add 33 to it and save it as your target time.
2- Perform all your computations and display in a double buffer.
3- Peek at the message loop and dispatch relevant messages, looping back to (3) until no more messages.
4- Get the current time with GetTickCount and check if it exceeds the target time. If FALSE, loop back to (3). If TRUE, add 33 to this new time and save it as your target time, BitBlt from the double buffer to the screen, and loop to (2). Any input from the user during those last 33 ms would be applied to the next set of computations (human reaction is not mush better than 300 ms).

If your computations take more than 30 ms, you should look at optimizing your code, or live with the slower FPS. If you want a different FPS for whatever reason, adjust the 30 ms delay accordingly (1000/FPS).

Raymond
Posted on 2004-12-19 23:03:48 by Raymond
Afternoon, Raymond.

I'd imagine that would only work with simple GDI animations.

3D games require a more precise measurement of elapsed time and there's no point keeping two completely different forms of time calculations.

Cheers,
Scronty
Posted on 2004-12-20 06:22:16 by Scronty
Look my BSP loader, It has a FPS counter, in Camera.inc
CalculateFrameRate

http://www.hot.ee/valk777/ProbnikGL_0_06.rar
http://www.hot.ee/valk777/ProbnikGL_libs.rar
Posted on 2004-12-20 10:21:25 by zabnik
3D games require a more precise measurement of elapsed time and there's no point keeping two completely different forms of time calculations.

Afternoon Scronty,

Would you be kind enough to elaborate on the reason(s) for the necessity of measuring elapsed time more precisely than 0.001 second between frames in any type of animation.

Raymond
Posted on 2004-12-20 10:57:20 by Raymond
IMHO there is no need for the FPS to exceed 30. The human eye can distinguish only about 16 FPS.


Raymond, that may not be true in all cases. If you look into the psychological literature on "priming", you will find that researchers often use stimulus (prime) presentation times of 16 or 17 milliseconds. That stimulus duration is not chosen because it would best fit the human eye, but because it bests fits the "usual hardware equipment" (60 Hz monitors). If you look into the literature on "subliminal priming", these people even need to pre- and postmask their stimuli with some random pattern, in order to prevent participants from clearly seeing the 16ms primes.

I'm not sure about movie-like smooth transitions, but for short flashes of optical information, temporal resolutions of more than 16 (or 30) FPS do not exceed the capability of the visual system.
Posted on 2004-12-20 15:55:50 by Frank
I do not dispute the "subliminal" perception of images lasting less than 30 milliseconds. The main goal in this thread is to provide a smooth animation and 30 FPS should generally be sufficient.

And I can't see the need of measuring elapsed time more precisely than 0.001 second between frames unless someone provides undisputable reasons.

Raymond.
Posted on 2004-12-20 22:05:58 by Raymond
Afternoon, Raymond.

"0.001 second between frames" is 1000 FPS, not 33 FPS.

If timeGetTime is used to obtain the current time the default precision on NT-based machines (NT/2k/etc) can be 5 milliseconds or more.
If you're throttling the FPS down to about 33 FPS then that'd be about a 16% error deviation on the actual elapsed time.
This means you'd see jittery animations and movement would nolonger be smooth all of the time (it looks as if the object you're trying to fly gets stuck intermittently).

Using the Performance Counter usually eliminates this problem.

When testing a program it's usual to have the thing rendering as fast as possible so that you can easily see which pieces of code affect the FPS the most. Otherwise the speed is kept at the default screen refresh rate (i.e. 60Hz/75Hz/etc).

30/30 FPS is pretty much the minimum FPS for games, and you always try to have it as high as possible so that animations and movement is smooth.
As mentioned above, the lower the FPS, the higher the error deviation for elapsed time.

Cheers,
Scronty
Posted on 2004-12-21 04:25:27 by Scronty
sorry for a really late reply, im trying out some FPS limiting now (in C++ though since im learning OpenGL in it a bit, think ill change to asm soon).
Maybe i didnt explain myself correctly, frame drawing can be as fast as it can be that doesnt matter but its more about limiting the gameloop else the player with the fastest pc would walk/run/shoot/reload/etc faster than the other players so i need to limit the gameloop at a certain fps so that people dont get advantages when the got faster computers.

i got the following code now (in C++) can anyone tell me if i can improve it more and if its a good way to limit the frames?

	if (QueryPerformanceFrequency( (LARGE_INTEGER*) &Frequency)){

TimeScale = 1.0/Frequency;
QueryPerformanceCounter( (LARGE_INTEGER*) &LastTime);
}
else{
MessageBox(NULL, "No Timer", "No Timer", MB_OK);
}


		QueryPerformanceCounter((LARGE_INTEGER*) &CurrentTime);

TimeElapsed += (CurrentTime - LastTime)*TimeScale;
LastTime = CurrentTime;

if (TimeElapsed >= 0.01){
GameLoop();
TimeElapsed -= 0.01;
}


edit: this should limit it at about 100fps if im correct
Posted on 2005-02-14 13:10:32 by Scorpie
I've just posted the second OpenGL tutorial in a series.
This one shows the implementation of Scronty's HighPerformance Timer code in an OpenGL framework, but you can use it in any win32 app.
Basically its one single procedure called Timer, with a single parameter that decides which of a number of defined functions will be performed.
The parameter has defined values like TIMER_START, TIMER_GETELAPSEDTIME, TIMER_GETABSOLUTETIME,TIMER_STOP etc, and returns the time on the fpu. Check it out.
http://homer.ultrano.com Beginners section.
Posted on 2005-02-15 01:30:26 by Homer
If you simply want to cap the framerate, please reread previous postings.

You must calculate the current fps, and if the current fps exceeds your threshold fps (eg 60) then you simply do not call your render proc, but you should still call update procs that move things over time, just not try to draw the frame onscreen.
Posted on 2005-02-15 01:36:50 by Homer
Maybe the DSOUND9 "IReferenceClock Interface" is an option.

You have two methods: (both in 100-nanosecond units)

1.) AdviseTime creates a one-shot advise request.
2.) AdvisePeriodic creates a periodic advise request.

So you can create a thread and use this timer to get an "acurate" timer-interrupt so your game will have the framerate that you want.
Posted on 2005-02-15 05:23:09 by Siekmanski
If you simply want to cap the framerate, please reread previous postings.

You must calculate the current fps, and if the current fps exceeds your threshold fps (eg 60) then you simply do not call your render proc, but you should still call update procs that move things over time, just not try to draw the frame onscreen.


hmm i see i made a little mistake in my code, the frames draw as fast as they can, they are in the main loop that does peekmessage and checks for the counter, i only limit some code that should limit the speed at which you go forward, etc etc
Posted on 2005-02-15 10:57:20 by Scorpie
haha, raymond, another way to decide if its worth getting more FPS is just to fuckin TEST it! if you ve played games (3d and 2d) you can SEE that 60 FPS is sooo much better than 30 fps (maybe it needs some training), no matter what the theory says. period. and a GUI is nothing more than a 2D game.
Posted on 2005-02-15 16:30:02 by HeLLoWorld
Afternoon, Scorpie.

All movement/rotation/etc in the game is based upon Elapsed Time.
Meaning:
If you're moving an aircraft at 55 metres/ second (~200k/h), then it doesn't matter how fast a PC is: the aircraft would still be seen to move the same distance onscreen.

FPS is only used as an indicator to how fast the frames are being rendered. It is never used to actually control the movement/rotation of objects.

Obtain the Elapsed Time and use it to:
1) Calculate FPS for displaying what the FPS is.
2) Multiply with any and all movement/rotation of objects

The Elapsed Time is "how much has an object moved/rotated since the last frame was rendered?".

Cheers,
Scronty
Posted on 2005-02-16 06:14:03 by Scronty
thanks for the reply Scronty and i agree that my topic title is a bit wrong since i dont want to limit the frames per sec :)
and im working with Elapsed time now you can move a certain distence every .... sec and framerate is much higher

HelloWorld, true i've noticed that also in all games i played (with adjustable max fps) by theory it shouldnt make any difference but sometimes it even looks bad when its running at 70 fps instead of 100 or so.

Scorpie
Posted on 2005-02-16 15:25:02 by Scorpie