This is a topic that interests me greatly. I’ve been posting some results in the Arcade Stick Lag thread, but felt that it was probably appropriate to have its own thread. I’ll try to compile some of the useful sources, and then present some of my results.
Previously several different people/groups have looked at some games to determine how different response times differ.
The PS4 affords several new opportunities to test input lag. I should mention for these tests, I’ve based them mainly on when the first input in command history appears, as this tends to be an obvious mark. I believe for the four games in the next post this occurs prior to the start of the animation. USF4 I’m fairly sure it occurs after the animation has begun.
Although you can only stream at 30fps, the camera is displaying 60fps, I’ve confirmed this watching videos recorded on El Gato HD 60 Pro.
Working with this initially, I was able to determine roughly the input lag for various different PS4 games. I posted these to twitter as an easy place to store images.
The big advantage of this method is that there should be some amount of synchronization between camera image and screen image, given that the PS4 is sending them both out. There is still the disadvantage or relying on watching for when the button is depressed.
The final method that I’ve come up with today involves using a programmable stick. Basically, I initially tested to see if there was a set amount of time between when the share button was pushed to when the screenshot was taken. This seems to be the case, so I was then able to see how many frames after the share button you could input a command and still have it register on screen. The results for this seem consistent with the previous testing.
For example, where share is pushed on F0 (frame 0)
SFV you can push a button on F11 and still have it appear (but not F12).
SkullGirls 2nd encore you can push a button on F12 and still have it appear
GGX Revelator you can push a button on F13 and still have it appear.
BlazBlue CPE you can push a button on F14 and still have it appear.
Inverted, this matches up quite well with the previous test.
The great advantage to this test is you are no longer relying on watching to see when a button is pressed, and then watching the screen and hoping to catch a clearly transitioned frame.
The disadvantage is that it is only for PS4, and that you need a programmable setup.
A similar setup should be achievable on PC though, just using one of the macro programs to press a button then a screen shot button at appropriate intervals. Again, the nice thing about doing it all through the PS4 is that everything should be synced appropriately.
Not entirely sure how your post relates to what I’ve posted.
The final post in particular so far as I’m aware is the only method that has removed the contribution of display and joystick lag as a component of input lag (if you accept that input lag comprises the contributions of the joystick, the console and the display, and many of the articles in the first post accept a similar terminology/approach).
I am thinking if you want to factor in everything, you also want to factor in the lag of your display as well.
Assuming the testing in the videos are done all with the same display, so at least all the tests are consistent. That way you are eliminating the variable of the TV or Monitor from the tests.
I also mention the refresh rate not equaling to display lag not really for you or me but other people who would read this thread, so sorry if that seems to be condescending.
It is just something that always bugs me, especially when the industry will report the Refresh and not the display’s lag.
That makes more sense. To clarify, I’m using the same display with a known amount of lag to avoid issues with the monitor confounding results.
Also worth mentioning, I’ve used the Hayabusa buttons. These have a lower profile than normal buttons, and seem to activate very easily with light touch, hopefully eliminating a lot of the he-said, she-said ambiguity of watching button presses and determining when the button is fully pressed. I’ve encountered relatively few frames where the button is half pressed.
Thanks for the clarification, I assumed you done something to that effect but I did not hear a mention of it in the videos.
Although its possible I just missed it, I did replay the video to try to make sure.
Cool. If you want your test to be a little more accurate, wire up a LED to the button you press. That way, it’s easy to see exactly when the press is active rather than guessing. Not all buttons activate as soon as you press them down, some are mid, some are more towards the end of the press. We also don’t always press buttons at the same speed, so for those times you don’t having the LED light up adds some more consistency and less guess work.
The way it works is, when you push the share button, it seems to take a set number of frames until it takes a screen shot. The number is probably between 15-20 frames. It’s not entirely straight forward to work out how long it takes, but it also probably isn’t that important. The reason being, the method allows you to compare one game to another and seems to be independent of the game. The time taken does seem consistent.
So, the later after that you can press a second “action” button and still have it display on screen the quicker the response.
i.e. Assuming it is F15 on which the screen shot is taken (almost certainly later than this, but it will do for example), then with Guacamelee it takes just one frame to process before the result is seen on screen. Whereas, in SFV you need to push that button 3F earlier in order for something to change on the screen.
Have been trying a similar thing with the PS4/Home button. Works with my setup, but I was hoping it could work without any fancy equipment. Will keep testing.
Basically, when you push the home button, about 20F later it will start fading out to the home screen. So if you push an attack and the home button at the same time, how much animation you can get through before the fade will give you an indication of how quickly the game responds. I’ve done an initial test with games I have checked previously, and the results seem consistent.
I had initially hoped this would be an easy way for people without access to a programmable setup to test input lag for any PS4 game, but on review it seems that the fade happens 20F after the release of the home button, not the initial press (probably to allow for differentiation from a long press to access the shutdown menu). This means that you really do have to push the home button for just one frame to get consistent, meaningful results, meaning once again you probably need a programmable setup.
Only possibility would be if the time to fade with holding it is consistent, in which case anyone with a 60fps capture could get meaningful results (only just though of this as I typed this). Will check this out later tonight. Bets back on?
And with a little bit more testing that seems to be entirely the case. Basically, this is a method to determine the input lag for PS4 games, without the need for a programmable setup, but will need 60fps capture ability.
The way I do it is (this may be too much detail, but you’ll get the idea)
open the PS4 game
press and hold the home button and another button for over 70 frames (with my setup pushing them together is easy enough, with a brook it should be easy to wire two buttons to ground to get a simultaneous push. Wouldn’t want to rely on just pushing them together though, for fear of introducing error).
record this using my game capture pro HD 60
open the file in avidemux (I use version 2.56, I think new versions may have removed the frame timing. Other programs would work fine)
scan until the screen fades, go one more frame forward (second frame of fading to blue)
click the A selection button and delete the following frames
scan back 70F and press the B selection button, delete the prior frames
count until you find the first response
In future I’ll probably change this so to 69F, one because it’s a nice number and two because this should make SF5’s first animation change/input display occur on F8, which is what everyone is familiar with.
Will give digitalfoundry an email and see if this interests them.