That is a question for the Aki shop PS360+ thread.
98% of this thread reminds of audiophile sites/threads, most of it is very subjective.
@Cloudstrifer if you don’t like it that much then donate it to me and I’ll find a good home for it.
if someone’s really passionate about proving that they can tell the difference, it should be reasonably easy to set up a blind test if you have two sticks that look the same and two PCBs of differing latency. just have a friend install the different pcbs in both sticks (bonus points if he sets it up so he doesn’t know which is which when he hands it to you) and then have you decide which pcb you’re playing on each time. then find out how often you were correct afterwards. would be a good exercise for anyone. it’s bad to judge latency once you’ve already been told which one lags more, because you’re likely going to experience a serious case of confirmation bias. it has to be blind to mean anything.
If you really want the nitty gritty, write a windows program that emits ETW events when it sees a button press, record a trace with both controllers plugged in, and look at the timestamps.
But how that helps with console sticks that lack PC compatibility?
Except that the USB protocol is negotiated between the device and the host. So it’s not clear that the performance on PC is comparable to the performance on a console. (It’s documented that you can change the effective response of devices on PC by changing the sampling rate.)
Also sampling rate on all devices are not polled equally on a Windows PC.
but all xinput devices use the same driver, so if all you’re doing is measuring relative lag between two sticks it doesn’t matter that the USB host delay may be different from a console as long as both devices are plugged into the same host. Direct input may be different but I would imagine that it’s a similar case.
all wired xbox360 controllers are PC compatible. PS3 controllers can be converted to xinput using the SCP drivers. Again if you’re only looking at relative time between two sticks it doesn’t matter if you have other layers introducing lag as long as it’s uniform.
How accurately can you determine lag via video camera pointed at a monitor?
You could wire up a LED to the button in addition to its normal function, put the LED in the same shot as the monitor, video the character on screen and count the frames between the LED and the action starting.
This would accomplish what OP wants, to determine values of X stick in X environment.
edit: obviously you would need to know the value of the monitor latency.
Thats all I have to contribute. Possibly a shit contribution but I am no expert.
-n
In order to get down to the ms you’d need a camera that shoots more than 60 fps. I’m talking like 300 to 1000 fps. Which is insane. It’s why Undamned’s method so far is the best method.
that’s what we did to test 3s various versions for input lag vs each other. it works but you have a high margin of error if you record at any sane fps (we couldn’t claim more than being within half a frame of precision). for stuff like what we were testing it’s probably fine. PS2 and Dreamcast have enough delay vs arcade that you can say with confidence that it’s true even with the margin of error. but with something like this where the amounts differ to a lesser degree, you need to be precise.
also it’s not that fun counting frames in slow motion. and yeah the more fps you’re recording at, the more accurate you can be. but also the more unpleasant the resulting video file is to work with.
tl;dr version I don’t think it’s a good method for testing where you need precision because it will make you want to kill yourself
@niku13 The video camera method also works, but introduces more variables. Besides the extra hardware in the chain, you also now have additional floating windows that are potentially out of sync; the polling window of the controller, and the combination of shutter speed and frame rate of the camera. The camera method is better used to determine how much a specific game lags compared to other games, and naturally you have to minimize all other sources of input and display lag to get the most accurate result. The method Teyah is using lets the game logic call the shots so it eliminates a lot of the other variables.
FWIW, you can get accuracy down to the ms with these frame-based PCB tests using averaging, which is essentially what Teyah is doing. I’ve heard doubt expressed from a handful of people that it is not possible to get this level of precision from averaging, but we do this all the time in other fields. I can provide a quick example if anyone is curious.
What Teyah’s results are currently missing is an accurate and precise measurement of the control PCB. Add that number to each of the results, then round up to the next ms (since 1ms is our accuracy limit), and the results should be decent.
True, but If all your equipment is running at the same rate (say the game and the camera both running at 59.94 fps), you can easily get sample bias.
@Rufus Sorry, I should’ve clarified. I meant these PCB tests as in the thread subject, the ones Teyah is doing. With the camera tests I think it simplifies things to just keep the results in frames if possible.
1 day we’ll get repeated test results from other people than teyah
Any new testing prospects for sticks? Padhacks? I also want to see how the SFxTekken stick does. A LOT of people (pros) use it so it would be interesting to see the results.
The results have already been published, dude. It uses the same pcb as the MadCatz TE-S.
That’s why, once again, I say it is important that the stick’s pcb is listed not just the model.
Gotcha. I didn’t realize it was fight stick vs. I should have looked more closely.
Yeah, probably a lot of people here can help populate those lists of which sticks use which PCBs. Would be a valuable addition.
-ud