Is there a good way to get accurate timing data for inputs?

Question

Hi, I am thinking of writing a rhythm game in Godot, and I want it to be possible to get the times of the user's inputs at high accuracy, more than frame-interval resolution.

The best possible case for my specific use case I think would be if Godot already has a high input polling frequency and will handle inputs immediately after they are received. All I would have to do to get timing information is have an input handler that gets the music playback position and uses that time.

Another usable case would be for Godot to provide timing information to input handlers, but I don't think it does this, as far as I can see from the docs.

Maybe Godot provides this functionality some other way?

Answer 1

You can't get timing data more accurately than it is currently, by getting OS.get_ticks_msec() the frame you receive it. You can improve that precision by increasing the framerate of your game (default is 60, increase to 120?), but I'm not aware of a better way to get a super-high accuracy at event timing without diving into low-level.

If such a thing existed at OS level, it would need to modify the engine. On Windows, I see there is this https://msdn.microsoft.com/en-us/library/windows/desktop/ms646302(v=vs.85).aspx, which gets an object containing time info, but not sure how accurate it is (or when to call it). It needs experimentation, If you are brave enough to try :)

Comments

Alright. So inputs are only processed on each frame?

---

If that's the case I think I will just try increasing fixed_fps, rather than attempt using platform-specific APIs. 200fps would give 5ms resolution, which is probably enough unless I am trying to make the next hardcore elite rhythm gamer game or a beatmania simulator.

---

Higher FPS is Ok as long as you don't have graphics or CPU bottlenecks. Also physics could be affected, but I never tried. In fact, you may want to increase the FPS, not fixed FPS (which is for physics).

---

I want to increase fixed_fps since the engine aims to hold the calls of fixed process callbacks to the fps specified, which makes it more likely that I will achieve the resolution I want. Ordinary process callbacks don't have any guarantees about being called often.