Jump to content
  • Advertisement
Sign in to follow this  
LGAB

Substitute for ctime ?

This topic is 4867 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I've been incorporating time-based movement in my engine, and it works pretty ok, at least it's mathematically correct. But ctime returns miliseconds, and it seems a bit to coarse and unpredictable, before I had the time-based movement it would just go slower when I put a high load on it, but now I get irratic jumps when load increases, and the delta-time I get from ctime seems to flicker back and forth between two values when load is constant. So I was wondering if there is any other library that can return microseconds or something so I can have more preciese movements, and hopefully more predictable behaviour? Lastly, I'd like to stay clear of Windows-specific code, but I know it would help, and I might surrender to it if it really is the only choice, but I hope not. Using Glut and MinGW/gcc.

Share this post


Link to post
Share on other sites
Advertisement
The only comment I have is that going from miliseconds to microseconds isn't going to help you. Are you aiming for fps > 1000?

The whole point of doing you calculations in real-time is to avoid slowing 'time' down. ie the More load you have the slower your movement is.

If you are having large computation loads then you should expect jerky movement, as the animation will be in real-time. The more time between each frame increases jerkiness.

Increasing your precision, more precisely knowing how much time occured between frames, will not decrease the amount of time which occured between frames.

There is no way around this, as you can't see into the future...

Thats why people shoot for FPS somewhere between 30 and 60. As it produces smooth animation.

Share this post


Link to post
Share on other sites
HAM:
Yes, well it was an extreme case, I wanted to see that it works as it should, the game isn't inteded to run at just a few fps =)

The system invariably returns a fps of either exactly 66.6667 or 62.5 (flickering between them and never goes above) when there's little or no load at all, likewise on other computers of various GHz. It just seems so coarse, and I can't explain the flickering of the numbers.

xor:
Will that be an improvement over ctime?

Share this post


Link to post
Share on other sites
My ctime() function does something totally different, so I can't speak for *your* ctime() function.

There isn't a platform-independent way of getting the time to better accuracy than 1s. This is because the Windows C library doesn't implement gettimeofday(), which is available on most other platforms, and has up to 1us (1 microsecond) accuracy.

So on Windows, use QueryPerformanceCounter, as previously suggested. This is pretty accurate.

GLUT is not really a very good choice for a OpenGL context-creation library - it's extremely limited - its input routines aren't good enough for games, generally speaking.

If you were to switch to SDL or GLFW, those already have platform-indepdent high-res time routines (which of course just wrap QueryPerformanceCounter or gettimeofday)

Mark

Share this post


Link to post
Share on other sites
Thanks, SDL may be the way to go, I've been a bit worried about Glut's limitations in this application actually. It's the embryo of a 2D dynamics engine I'm working on, so far I've been mostly caught up in the vector maths, probably better to switch to SDL now that later. :)

Share this post


Link to post
Share on other sites
having the fps constantly around the 60-65 range sounds like your framerate is locked to the monitor refresh rate. if you're using opengl, i believe that is the default. disabling it in code requires using an os-specific extension (i think). you might try seeing if you can turn it off in your gfx card's driver config and checking your framerate then.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!