# Frame Rates for beginners!

## Recommended Posts

##### Share on other sites
Thanks for that ToohrVyk - that's really quite interesting.

If that is what's limiting my 'frame rate', I guess I need to introduce something to my code that does this:

1) Turns off 'Vsync'
2) Executes the main loop as often as it possibly can
but
3) Only uses render_frame() at the correct time

i.e. the main loop runs v fast (thus the physics becomes more accurate), but the rendering only happens say 85 times per second (if that's my refresh rate) to ensure there's no tearing.

This sounds really good - I'll research how to do this;

Out of interest does anyone else think it's a different issue?

thanks again!

Joe

##### Share on other sites
Are you using GetTickCount to measure fps? On average it's only accurate to ~10ms, which means it can't measure framerates > 100 or so. You'll have to use a different timing function, like QueryPerformanceCounter/QueryPerformanceFrequency or timeGetTime.

##### Share on other sites
Also one other thing...

This line here:
PostMessage(hWnd, WM_DESTROY, 0, 0);

It's not really a big deal for a simple program with one window, but this isn't how you destroy a window. You use the DestroyWindow function. That function actually cleans up resources created for the window, which won't happen if you just send yourself a WM_DESTROY message.

##### Share on other sites
Thanks MJP,

yes, I measure the 'loop rate' using QueryPerformanceCounter/QueryPerformanceFrequency , and (I should have posted that code here, but I'm at work at the moment!) just before the render_frame() I use counter++, and work out the fps (or lps!) by comparing the counter int to the results of the 'realtime' counter above.

In fact, I have gone as far as displaying how many microseconds each loop takes - its about 13,333 - and as mentioned doesn't change significantly no matter how many polys & objects I throw at it; this is why I reckon something is 'holding up' each loop?

perhaps I'm just being obsessive!

thanks for all the help so far,

cheers,

joe

##### Share on other sites
Quote:
 Original post by Beginner_Joe1) Turns off 'Vsync'2) Executes the main loop as often as it possibly canbut3) Only uses render_frame() at the correct time

This is a possibility. However, what's wrong with:

1) Gets the current time
2) Computes the world state for the current time
3) Renders the frame using the world state and with VSync

Regardless of VSync, you'll still get a framerate that's reasonable enough for collecting input, and you can avoid VSync problems entirely by using triple buffering if it really annoys you.

The physics loop doesn't have to run in real-time—it only has to run as if it happened in real-time.

##### Share on other sites
Quote:
 Original post by Beginner_Joe#define SCREEN_WIDTH 640#define SCREEN_HEIGHT 480#define KEY_DOWN(vk_code) ((GetAsyncKeyState(vk_code) & 0x8000) ? 1 : 0)#define KEY_UP(vk_code) ((GetAsyncKeyState(vk_code) & 0x8000) ? 0 : 1)

Is this still how C++ is taught? C++ has had const and inline functions since 1983 or something.

##### Share on other sites
Thanks ToohrVyk that's of course a good point. Actually that's how my prog works at the moment (e.g. for the ball position it works out what the accel would be at the point in time the function is called, from that the velocity and from that the world position).

And in 99.9% of circumstances this is fine (although for collisions I 'back-engineer' to the time of collision, and update before and after etc.)

however in some circumstances I want to figure out changes smaller than the current delta ( approx 13ms),

Plus I'm thinking there must be a way to do it cos other progs I've used don't seem to have this 'limit' (i.e. played severance the other day and it runs at 400fps...!)

DevFred - I'm sure there are 100 better ways to do things than how I'm learning! let's just say the tutorials that I'm doing are about the right level for me (I did used to program the speccy in hex dumps, but I was 10 at the time, and for some reason things seemed easier then...?!!)

##### Share on other sites
If you just want to disable VSYNC then, use D3DPRESENT_IMMEDIATE as the value for PresentationInterval in the D3DPRESENT_PARAMETERS struct you pass to CreateDevice.

##### Share on other sites
Quote:
 Original post by Beginner_Joehowever in some circumstances I want to figure out changes smaller than the current delta ( approx 13ms),
You're limiting yourself to thinking in terms of "one update step per frame". Suppose for a minute that you want your physics (very simple and easy to compute) to update every 2 milliseconds, but your frames are only rendered every 14 milliseconds. What do you do? You just run seven updates before every frame!

In short:
int updates = 0;float start_time = time();while (running){  int expected_updates = (time() - start_time) * UPDATES_PER_SECOND;  while (updates < expected_updates)     { run_update(); ++updates; }  render_frame();}

This guarantees time-independence, a great update frequency for your physics, and is still simple.

Quote:
 Plus I'm thinking there must be a way to do it cos other progs I've used don't seem to have this 'limit' (i.e. played severance the other day and it runs at 400fps...!)
To do what? Display a very high value followed by "FPS" ? Unless it has a very clear impact on the gameplay (and at 85FPS, chances are that it won't), don't bother with it.

Quote:
 DevFred - I'm sure there are 100 better ways to do things than how I'm learning! let's just say the tutorials that I'm doing are about the right level for me
The issue is with them being outdated. The correct version of those lines would be:

const int SCREEN_WIDTH = 640;const int SCREEN_HEIGHT = 480;inline bool KEY_DOWN(int vk_code) { return GetAsyncKeyState(vk_code) & 0x8000; }inline bool KEY_UP(int vk_code) { return GetAsyncKeyState(vk_code) & 0x8000; }

##### Share on other sites
hahaha - genius, yes of course ToohrVyk that makes perfect sense! I have to get used to not thinking 'step-by-step'.

Comment noted re fps of >100 fps etc. - you're right, what impact does it have?! The solution you suggest is exactly what I need; the fps doesn't matter, but I want the time delta for calculating motion to be as small as possible.

And thanks for the corrections re #define / const. I'm getting my head round what the difference is (with a little assistance from 'C++ for dummies'). I've only been learning C++ for 3 weeks, so I've had a lot to take in! I only understood what the point of pointers was about 5 days ago.... ;)

Thanks again for your time & help, I'm really grateful for you assisting this rookie!

Now I'd better get back to my day job (which is recruiting IT people!).

And one of the reasons why I'm learning C++? I've been asked by games companies to recruit coders & artists for them, been out to meet a few studios, and thought 'that is a job that I want'. I don't care what the entry level pays, I'm imagining working in a job that I really enjoy.

One day, one day!

##### Share on other sites
Excellent -

Of course, once I disabled VSync in the code (and after a bit of puzzlement, in my graphics card driver global settings as well!) the app runs at 2000fps. Which I don't need obviously.

This means that you guys were right it's the Vsync.

So the aim is now to follow the advice, and run a loop until the monitor is ready to refresh. I don't want to guestimate the number of loops, and I want to squeeze as many loops as I can between frames

Bit of research has shown up D3DRASTER_STATUS and GETRASTERSTATUS as possible ways of timing this right.

Would any one be kind enough to show me a bit of code that would allow me to check the raster status each loop so I can call the frame rendering at exactly the right time? I've looked at the MSDN but I'm getting confused, and can't understand how to get anything meaningful!

Hope you don't mind me asking this,

cheers,

Joe

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628346
• Total Posts
2982201

• 10
• 9
• 24
• 10
• 9