I’m trying to build a rythm game and would like to have the measured time at wich an input occured or a gamethread/tick independent function with a more stable update time.
I’d try to work with “get accurate real time” function since the partial seconds seem to be very accurate. The full seconds don’t seem to be so on every system WTF Is? Get Accurate Real Time in Unreal Engine 4 ( UE4 ) - YouTube Best would be a build in timer ofcourse ^^
My problem with the unreals inputsystem is its perfomance orientated solution. It updates with the tick time, wich I’d like to avoid, because I don’t like to force the user to have the best hardware to get compairable results.
By now I’m using Fmod as a sound engine. The “Get Timeline Position” function seems to be accurate down to a millisecond. I can’t tell how accurat that position is to what the user is hearing, but it has an easy interface.
I learned alot in blueprints and now I’m trying to learn c++. Asynchronous functions or multithreading sounded like a good idea, but I’m far from getting that from running. But before I burn my time trying to achiev something that might has an easy solution, it seemed like a good idea to ask here
I’m not entirely understanding exactly what your goal is, but using any built-in functionality, the fastest way for you to know of an input is to check it on tick, and get a timestamp for it from there. I suspect I’d probably try something like this for a first iteration on the idea
as each input is expected, put it into a list of expected inputs, with the timestamp it was expected. when you receive an input in tick, compare that to the list of expected inputs. purge that list of any inputs that are considered “missed” or “hit” when they are considered as such. So you should have a very short list of recently expected inputs to compare “did the user hit this input in time”.
Thx for the response. And Sorry for my Late response.
The problem I’m facing is the time when I can check for an input. My update cycle is bound to the same timing as the event tick. Every Input Event executes with the game thread (tick event). I’d guess AActors in c++ are not different from blueprints in the way they update/execute.
I recorded the sound of my mouse clicks with a test sound in the background and found that (to me) pressing <20ms off the actual sound signal still feels like I pressed synchron to the sound signal. To test that in the game I would need to do a test at least twice as often (every 10 ms). I don’t want to demand that every user needs good enough hardware to run the game at least at 100 fps.
Today I found that unreals “Playback Percent” value from the “On Audio Playback Percent” event, has 10ms as the shortest updated cycle. printing the value with higher framerates just give duplicates of the last updated value.
by the way: Fmod updates every 23/24ms, according to my test.
You will not be able to program that to work the same for every different device configurations out there.
Screen refresh rates get into account, gamepads input latency, gpu, cpu stalls, etc.
That’s why Guitar Hero / RockBand games have a calibration system for input delay, if you want to build a game like that you’ll probably have to build the same calibration system for your own game.
I’m already working on a calibration interface
But I still would like to determine how good/close the player hit the beat (with offset calibarion) and the feeling of fairness will vary by the granularity of my measurement cycle.
