Since I enjoy watching competitive fighting game matches, I might one day dare to make a competitive fighting game.
So, does anyone know whether input lag is a big issue for Blender BGE?
i.e. if I press a button on my keyboard/gamepad, how many milliseconds does it take for my computer to know I pressed the button?
And then how many milliseconds does it take for my computer to tell the Blender game that I pressed the button?
Does it depend on my computer? Version of Blender? How optimized my Blender game is?
This is probably relevant to other competitive games, too.
Eye ball it or if you want to do something a little more complicated, do the following:
Make an optimized C or C++ (preferably C) program that runs in the background and logs the timestamp when you press a key (prints it in a console or puts it into a file). Make a similar program in the BGE using Python. Run the C++ program and the BGE at the same time, press a key, and see the difference in time between the two.
It needs to exactly determine when you pressed the key (that it counts as pressed).
It needs to exactly determine when an according output appears on the scree.
Your software can’t do that. Your OS will tell the software: you pressed the key exactly now (how should the softwer know there is a delay?).
You computer can only tell when it got informed about the keyboard press and when it send out data to the GPU for display. It will not know about any delay when the GPU finished rendering nor when your Monitor refreshed the screen.
You could record an high-speed video that shows the key press and the monitor output. This way you can measure the real-time reaction time.
Now back to something more practical:
The BGE with default settings runs with 60FPS (logic and render).
This means anything within the 16ms gets processed. You can fairly assume your game needs 16ms reaction time (not counting the non-game delay effects as mentioned above).
This assumes your game’s logic reacts within the same logical frame.
Be aware this does not discuss lags (unexpected exceeding of the available processing time). It discusses normal game processing.
So I’m gonna record a video of me pressing a button for a simple blender game, to help measure input lag.
Two questions:
Will a 60fps camera for a 60fps game be a problem?
I don’t have a high speed camera, and I’m hoping this is okay as long as I take the average of a lot of trials.
Should I use an in-game timer?
Or a real life stopwatch?
Or does it even matter?
Something tells me it doesn’t,
as long as I understand what’s going on, which numbers to subtract, etc.
Just looking for confirmation.
One thing to avoid is thinking about over-precise accuracy: Your game tics run at 60Hz by default, which corresponds to the 16ms between tics mentionned by Monster above.
In many combat games, there is a notion of “frame perfect” actions, this is because of the exact Hertz thingy: Game run in frames that have a time-size (~16ms at 60Hz).
Now, when you press a button, lets say on frame 12 to be silly, what should happen ?
The best approach is to assume that the input will be processed on the next tic (13th), because well, this 12th tic already started, is being processed, and you can fairly say that the user missed his frame. Sure he pressed during the 12h frame, but it was already being processed, so he was in fact too late ! His press will be processed on frame 13th. Period.
In terms of input lag, there is only as much lag as your frames do.
You need to think how to slice time, from what I’ve seen you do not need to measure input lag as it should not be a problem… Maybe a fun experience, if you really need to do it… It may be harder to try and record any pseudo-input-lag than just playing with the frame slicing.
One thing to avoid is thinking about over-precise accuracy: Your game tics run at 60Hz by default, which corresponds to the 16ms between tics mentionned by Monster above.
In many combat games, there is a notion of “frame perfect” actions, this is because of the exact Hertz thingy: Game run in frames that have a time-size (~16ms at 60Hz).
Now, when you press a button, lets say on frame 12 to be silly, what should happen ?
The best approach is to assume that the input will be processed on the next tic (13th), because well, this 12th tic already started, is being processed, and you can fairly say that the user missed his frame. Sure he pressed during the 12h frame, but it was already being processed, so he was in fact too late ! His press will be processed on frame 13th. Period.
In terms of input lag, there is only as much lag as your frames do.
You need to think how to slice time, from what I’ve seen you do not need to measure input lag as it should not be a problem… Maybe a fun experience, if you really need to do it… It may be harder to try and record any pseudo-input-lag than just playing with the frame slicing.
Have fun with your project, keep your head cool !
(this is a test message, idk if the other one got thru)
@WKnight02 I’d be more than happy with only 1 frame of lag!
What do you mean by slicing time?
@Daedalus_MDW
I was hoping 60fps could get “workable results”, e.g. the average has a +/- 1-3 frames margin of error. Which… yeah… 2 or more frames sounds like a big margin of error…
Rough estimate from using a 60fps camera:
when running at a full 60fps, my game had 5 +/- 2 frames of lag, which includes an Apple usb keyboard and an Intel iMac screen.
Sources of error include:
some frames displayed two numbers “ghosted on top of each other”
the next frame displaying a time that was two frames later.
…lol… yeah.
But would a 240fps or 480fps camera suffice? And are such cameras cheap?
I’m hoping Blender is 5 frames or less!
So I welcome any suggestions for high or medium speed cameras,
ways to reduce input lag,
discussions on input lag,
etc.