We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1411 - Timer is too inaccurate
Summary: Timer is too inaccurate
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: timer (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-06 06:05 UTC by Sik
Modified: 2013-04-17 04:29 UTC (History)
0 users

See Also:

Attachments
Source code for a small test program showing the issue. Put in the public domain. (1.33 KB, application/octet-stream)
2012-02-06 06:05 UTC, Sik 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sik 2012-02-06 06:05:31 UTC 
Created attachment 814 [details]
Source code for a small test program showing the issue. Put in the public domain.

I'm trying to implement a framerate system in my game using SDL timers (both SDL_GetTicks and the performance counter), but I get at most 30 FPS for some reason. I even stripped down the program to the most minimum instance (so only that was running) and still ended up with 30 FPS (with frameskip).

I checked what value SDL_GetPerformanceFrequency returned and it was 1000000, meaning it was using gettimeofday. Had to hack SDL_config.h to make it use clock_gettime instead, which for some reason wasn't detected. It still was stuck at 30 FPS.

(On that note, I'd get a linker error if I tried to use the resulting library, I'd need to pass -lrt to GCC when building my program to get it to work. May want to check that too, also may be why configure didn't detect clock_gettime)

Using Ubuntu 11.04 x86-64 with the February 3 snapshot of the SDL 2.0 Mercurial (the latest one as I write this). Any ideas?

PS: attaching the source code of a minimal program showing the issue. Waits for 5 seconds, then shows how many times it called the framerate control function (when working fine it should show around 300). Just build everything together :P Put in the public domain.
Comment 1 Sik 2012-02-07 22:54:25 UTC 
Ugh, forget that, was an error on my side after all.

That still doesn't explain why configure doesn't notice the presence of clock_gettime, which I think is important to fix since it's definitely much more accurate than gettimeofday (especially if the current date changes for some reason). While testing I noticed that using -std=c99 makes time.h not provide clock_gettime nor anything related, is that relevant?
Comment 2 Ben Swick 2013-04-16 15:03:03 UTC 
Pass the flag --enable-clock_gettime to configure to have it check if clock_gettime is available (off by default).