Hi devs,
I am at the initial stages of developing my shmup, but I want to start thinking about input lag early rather than late in the dev cycle. I am using Unity. I have heard Unity is a bit of a lag monster, but it is the engine I know the best so I think it is my best bet to create a decent game (I use Unity at work in the medical imaging field).
What method are you folks using to measure input lag. I have seen the Electric Underground videos (looks like there is a high-speed camera that films the game with the controller/light in view). Is there another recommended method? what methods have given you good sucess?
I am currently using the built in Unity inputs, but if someone knows of a good library, please let me know.
The game feels snappy enough to me, but I imagine there is some lag.
how do you measure input lag
-
Sumez
- Posts: 9118
- Joined: Fri Feb 18, 2011 10:11 am
- Location: Denmarku
- Contact:
Re: how do you measure input lag
The traditional way is by measuring the delay between button press and visible reaction on the screen, yes.
But this also implies a lot of other things - it's testing the inherent lag of hardware such as the monitor or controller, as well as OS-specific driver software that you may or may not have much influence over as a developer. Also, the mere timing of the button press within the duration of one frame can typically cause randomly varied measurements between 0-1 additional frame.
It can be very hard to filter out such factors though, without also filtering out things you *do* want to affect, so I think a high-speed camera would still be ideal for your purpose.
The things you want to look out for is when (and how) you poll player input compared to when you are actually utilizing that information, and how soon after that the resulting frame gets rendered into the backbuffer - and when that buffer is actually displayed by the GPU (vsync).
If your game isn't too graphically demanding, you can probably get away with a relatively tiny frame-logic duration, but I don't really know how much control you have over that in Unity... Ideally you probably want to override a lot of the things Unity typically offers to do for you. I'm sure there's plenty of resources out there on low-lag programming with Unity!
But this also implies a lot of other things - it's testing the inherent lag of hardware such as the monitor or controller, as well as OS-specific driver software that you may or may not have much influence over as a developer. Also, the mere timing of the button press within the duration of one frame can typically cause randomly varied measurements between 0-1 additional frame.
It can be very hard to filter out such factors though, without also filtering out things you *do* want to affect, so I think a high-speed camera would still be ideal for your purpose.
The things you want to look out for is when (and how) you poll player input compared to when you are actually utilizing that information, and how soon after that the resulting frame gets rendered into the backbuffer - and when that buffer is actually displayed by the GPU (vsync).
If your game isn't too graphically demanding, you can probably get away with a relatively tiny frame-logic duration, but I don't really know how much control you have over that in Unity... Ideally you probably want to override a lot of the things Unity typically offers to do for you. I'm sure there's plenty of resources out there on low-lag programming with Unity!