SFML community forums
Help => General => Topic started by: 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:
#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):
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
-
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).
-
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.
-
I solved the problem.
Thanks for your feedback.
-
Hi,
I'm probably being thick here but I was looking at the source code for sf::Time (https://github.com/SFML/SFML/blob/master/include/SFML/System/Time.hpp) 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:
-
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.
-
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.
-
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.
-
Weirdly enough, it's a lot better when I use it out of Java. Maybe let's wait for other people's results.
-
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.
-
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.
-
So what does this comment mean?
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" ?
-
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.
-
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.
-
The precision of sf::Sleep can be as low (high?) as 16 ms, so I guess it's ok.
If so, the doc should probably mention that the argument passed to SetFramerateLimit() is not a hard, reliable limit.
Definitely.
-
I get this too. I got the latest SFML build today, and this is what happens:
//stays fairly constant at 60fps but very visibly stutters every few frames
EnableVerticalSync(true);
SetFramerateLimit(60);
//stays very loosely around 60fps (around 50-80), but runs smoothly
EnableVerticalSync(false);
SetFramerateLimit(60);
oh and also, the first bit of code works perfectly in Ubuntu 11.10 without stuttering.
-
I'm having a strange issue with this new commit however should I post this on the sf::Time thread? But since it's somewhat related, I think I'll post here.
When I open an SFML application it starts with 66FPS but after a while they drop to 32FPS and it stays there. Even if I restart the application the FPS doesn't change, I have to restart the computer.
What could be causing this? Driver issue?
I have an ATI Radeon 4870, latest drivers, using Windows 7.
Compiled with both debug and release, static library.
-
When I open an SFML application
Any SFML application?
-
When I open an SFML application
Any SFML application?
Yeah, compiled with the new commit I mean.
I think it might not be SFML's problem though. I just found that this happens only after I play the game Portal 2. So I'm going to guess a driver problem. I'll try a full driver cleanup and reinstall.
EDIT: I just remember I had this problem before:
http://www.sfml-dev.org/forum/viewtopic.php?t=5802&highlight=
Shame on me! Although I'm not using vsync this time.