Author Topic: SetFramerateLimit does not seem to work correctly (Read 6726 times)

pdinklag · « **on:** January 30, 2012, 06:13:27 pm »

Likely related to https://github.com/SFML/SFML/issues/162 (saw this after I wrote this post, sorry)

I noticed oddities while working on JSFML. I set my window's framerate limit to 60, but in fact my test application runs at about 120 FPS. In fact, it varies. Sometimes, the application also runs at 100, I had times where it would only run at 30 for a while, then all of a sudden go up to 120.

I'm not sure what exactly might be the problem, but here is how I can reproduce it:

Code: [Select]

#include <SFML/Graphics.hpp>

int main(int argc, char **argv) {
	sf::RenderWindow window(sf::VideoMode(640, 480), "FPS Test");
	window.SetFramerateLimit(60);

	int numFrames = 0;
	int msLeft = 1000;

	sf::Event e;
	sf::Clock clock;

	while(window.IsOpen()) {
		while(window.PollEvent(e)) {
			if(e.Type == sf::Event::Closed)
				window.Close();
				break;
		}

		sf::Time delta = clock.Restart();
		
		numFrames++;
		msLeft -= delta.AsMilliseconds();

		if(msLeft <= 0) {
			printf("Frames last second: %d\n", numFrames);

			numFrames = 0;
			msLeft += 1000;
		}

		window.Clear();
		window.Display();
	}

	return 0;
}

This is counting the actual frames within 1000 milliseconds. Unless I'm totally out of my mind this should be a working way to test the FPS. I'm aware this is not perfectly accurate, but it should not be counting 120 frames anyway.

My output of that program a few minutes ago looked as follows (Windows 7 32 bit, Release, latest SFML from github):

Code: [Select]

Frames last second: 115
Frames last second: 124
Frames last second: 114
Frames last second: 115
Frames last second: 121
Frames last second: 117
Frames last second: 115
Frames last second: 120
Frames last second: 119

pdinklag · « **Reply #1 on:** January 30, 2012, 06:22:30 pm »

This does not seem to happen on Ubuntu 10.04, 32 bit (tested inside a VM, but it runs very smoothly and I can increase the FPS at will and it works fine).

Dinocool · « **Reply #2 on:** January 31, 2012, 02:34:08 am »

This problem is also occurring to me on a Windows 7 (x64) computer, running the program in 32 bit mode, haven't tested in 64 bit mode.

EDIT:

this is using the latest git in a c++ program.

Laurent · « **Reply #3 on:** January 31, 2012, 07:55:31 am »

I solved the problem.

Thanks for your feedback.

Contadotempo · « **Reply #4 on:** January 31, 2012, 08:17:42 am »

Hi,

I'm probably being thick here but I was looking at the source code for sf::Time and I curious about what value did "static const Time Zero" on line 85 had. But can't find it's value being assigned anywhere. Am I missing something?

I hope this isn't a stupid question. :wink:

Laurent · « **Reply #5 on:** January 31, 2012, 08:36:25 am »

It's just a default constructed sf::Time instance

But why did you post here? There's a dedicated thread about the new time API.

pdinklag · « **Reply #6 on:** January 31, 2012, 12:32:36 pm »

It definitely changed something, but I got a feeling dealing with microseconds on Windows is extremely inaccurate and should not be done for timing.

Using the above code,
for a limit of 60, my average FPS is 67
for a limit of 80, the average is 67,
for a limit of 30, the average is 23,
for a limit of 200, the average is not saying anything because the FPS jumps wildly between 67, 150 and 250 every second,
for a limit of 0 (none), the FPS is a roughly constant 1000 proving that the jumps at 200 are not a performance problem. Also, the fact that it's almost a constant 1000 looks very suspicious to me.

Laurent · « **Reply #7 on:** January 31, 2012, 12:55:16 pm »

Quote

I got a feeling dealing with microseconds on Windows is extremely inaccurate and should not be done for timing

I'm not dealing more with microsecond than I did before.

The results on my own Windows (7 64 bits) were very accurate after the fix.

pdinklag · « **Reply #8 on:** January 31, 2012, 01:20:58 pm »

Weirdly enough, it's a lot better when I use it out of Java. Maybe let's wait for other people's results.

Laurent · « **Reply #9 on:** January 31, 2012, 01:40:01 pm »

Quote

Weirdly enough, it's a lot better when I use it out of Java

I thought from your C++ code that these results had nothing to do with Java.

pdinklag · « **Reply #10 on:** January 31, 2012, 02:58:02 pm »

Those results I posted here were strictly from that C++ program in my first post, run using MSVC++ 2010 Express. They do indeed not have anything to do with Java.

Laurent · « **Reply #11 on:** January 31, 2012, 03:08:34 pm »

So what does this comment mean?

Quote

Weirdly enough, it's a lot better when I use it out of Java

Does it mean "I get even worse results if I run this code with JSFML" ?

pdinklag · « **Reply #12 on:** January 31, 2012, 03:24:11 pm »

Oh, no, it's the opposite, I get better results in JSFML.

Sorry.

Well, I don't have any explanation for this if this doesn't happen for you. That's why I said we should wait for other peoples' results. Maybe there's still something wrong but only under certain circumstances, but I wouldn't know which.

Nexus · « **Reply #13 on:** January 31, 2012, 07:25:57 pm »

I get always around 66 FPS, although I specify 60. Is that the expected behavior (sleep imprecision or whatever)? If so, the doc should probably mention that the argument passed to SetFramerateLimit() is not a hard, reliable limit.

Laurent · « **Reply #14 on:** January 31, 2012, 07:52:06 pm »

The precision of sf::Sleep can be as low (high?) as 16 ms, so I guess it's ok.

Quote

If so, the doc should probably mention that the argument passed to SetFramerateLimit() is not a hard, reliable limit.

Definitely.