2
\$\begingroup\$

I'm working on a simple game with SFML, and the only way to make the game reasonably smooth is to allow it the highest framerate my machine can handle (that is, giving it no limit). 60 FPS in my game looks like 5 FPS in most games.

I've made sure it wasn't any weird timing issue with sf::Clock by making my delta variable constant, and I've made a simple moving square with the default SFML template to make sure it wasn't anything else in my code.

Limiting framerate using window.setFramerateLimit(80), window.setVerticalSync(true), or by placing usleep(1000 * 15), a 15-millisecond pause (~67 FPS, in theory) in the game loop, cause the terribly glitchy, asymmetric animation.

I think the problem is my Mac. I hesitate to blame anything other than my code, but I just can't explain the problem otherwise. I'm running OS X Mavericks on a 15-inch MacBook Pro with a Retina display (2.4 GHz i7, Nvidia, 8GB RAM).

Is it the Retina display, or some issue with the sleep() system calls? Any thoughts are welcome. Thanks!

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ Hard to answer with no code to look at. First, these two window.setFramerateLimit(80), window.setVerticalSync(true) dont make sense together. Try to use some frame counting software external to your program. If you are getting more than 30 fps in your program, it is bad logic and a problem in your state update. If you are getting really low fps the problem may come from a few places. \$\endgroup\$
    – Grimshaw
    Dec 12, 2013 at 6:16
  • \$\begingroup\$ Grimshaw: If you read the question, you would know that logic is not an issue, so code is not necessary. Any working SFML code will have the same issues on my machine, as far as I'm aware. \$\endgroup\$
    – ICoffeeConsumer
    Dec 12, 2013 at 6:20
  • 1
    \$\begingroup\$ If it is your Mac, this is not really the right place to ask. I'm still willing to bet it's your code. Have you tried running a different SFML game? \$\endgroup\$
    – craftworkgames
    Dec 12, 2013 at 6:23

1 Answer 1

Reset to default
10
\$\begingroup\$

Sleep calls are an extremely bad way of controlling framerate. Use them to reduce CPU usage for sure, but don't use them to control framerate.

usleep(1000 * 15), a 15-millisecond pause (~67 FPS, in theory)

No, it's not.

First of all, see the documentation for usleep:

The actual time slept may be longer, due to system latencies and possible limitations in the timer resolution of the hardware.

Secondly, realise that the sleep time is in addition to the time taken to run a frame, which may be longer. So if frame 1 takes 3ms, frame 2 takes 5ms, frame 3 takes 1ms, frame 4 takes 7ms, then when you add the sleep time (and assume that you actually do sleep for 15ms exact - which is unlikely) you're looking at frame times of 18ms, 20ms, 16ms, 22ms.

That's why you should never use sleep to control framerate.

The standard reference page for this topic is Glenn Fiedler's Fix your Timestep so I'm going to finish up by pointing you at that.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ Sleep used to be used back in the bad old days of the 90's, but in today's preemptive multitasking os's it's a total no-no. Upvote for you mr shelter! \$\endgroup\$
    – Matt D
    Dec 12, 2013 at 7:31
  • \$\begingroup\$ Thanks for the answer, but I only used the sleep calls to see if that was the underlying problem. I think it is. I thought the built-in vsync and framerate limit functions would deal with the inconsistencies in sleep, but apparently they don't. I can't be the only Mac + SFML user with this probem, can I? It's not like something is wrong with my system. Any SFML-specific suggestions? Am I doing something wrong by calling window.setFramerateLimit(60)? \$\endgroup\$
    – ICoffeeConsumer
    Dec 12, 2013 at 21:41
  • 1
    \$\begingroup\$ To be moe specific, sleep() yields the CPU to other threads/processes. So, you call sleep for 20, then the antivirus might run for 60ms or something. When the OS checks again (at the next timer interrupt), it sees that 20ms have passed, so schedules your game back. But calling sleep() leaves all this up to the OS scheduler. \$\endgroup\$
    – Robert Fraser
    Dec 12, 2013 at 23:14
  • \$\begingroup\$ I'd love to accept this answer, but it doesn't answer the question or solve the problem. I don't care about sleep; SFML is supposed to take care of that for me, but it's not. window.setFramerateLimit() and window.setVerticalSyncEnabled() cause stuttering and sprites that literally jiggle when they move slowly -- they are not drawn at the same time. As my title states, the only way to run my game (or any animation on my machine with SFML) smoothly is to give framerate free reign. \$\endgroup\$
    – ICoffeeConsumer
    Dec 15, 2013 at 17:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .