Testing was done using my standard methods, with millisecond long inputs at the same time as a component signal is “watermarked” to give a clear visual indication of when the input occurred.*
So, having tested various difference sticks/pads on five different systems, I don’t think I’ve ever seen BB take less than two frames to respond. I don’t know if there’s going to be a way to breakdown how much is the joystick and how much is the game using this method.
The variation in terms of how sticks respond is far greater than I had expected. I would be very interested to hear other people’s ideas on how this works, but I wonder if there is a significant different in how inputs are read. As you can see from the TE2 testing, it can take between 2-18ms to respond, i.e. anywhere within the frame. This would certainly go towards explaining why a stick can usually lose to another stick but occasionally win.
Another thing to mention is that this method is quite effective for testing when it works, however just does not work on certain sticks. For example, on the Pokken pad unless the input is at least 3ms long the pad will not acknowledge it, and on trying to test the Venom PS4 stick today, even inputs of 5ms are not acknowledged.
Incidentally, I have down a test of 150 repetitions to ensure that the HDMI --> component converter is not adding too much lag. My findings would suggest that a native 720P component output (BBCP on PS3), a 720P HDMI output converted to component and a 1080p HDMI output converted to component differ by at most 0.12msec. I am therefore happy enough to continue using the HDMI->component converter.
First of all that setup’s really cool noodalls! Looking forward to seeing more of your results.
I really have no idea how the variation works (whether it’s from the console, the game or the controller, etc), but I suggested in my post earlier on this page that I think it might be helpful to include something like a standard deviation value for the sets of delay measurements rather than just a straight average latency value when evaluating PCBs, because even the evaluation method from the OP (determining an “average” from "Yes"s and "No"s) occasionally suggested significant latency variance in how some controllers’ inputs are read.
I think this certainly makes comparing controllers more complicated. Like if controller A has an average latency of 8ms and a very small standard deviation, and controller B has an average latency of 5ms but a huge standard deviation, it would be difficult for me to say which one I’d call “preferable” in terms of lag. I think I’d prefer the one that looks cooler or feels comfier.
I have a feeling that some games vary with regards to timing a lot more than others. Blazblue seems very consistent and that’s why I’m using that predominantly.
I have a new idea of how to generate larger volumes of meaningful data quickly and easily, and will try to do a trial run soon.
This shows how inputs will be accepted all across the frame using a TE2, but only at certain times with the UFB.
Note, I do need to go back and make the data a bit clearer. Some of the results at the end of the frame for the TE2 (16 and 2/3) are actually from a frame earlier, so should read as 17 and 18 to make things clearer.
So pretty much this. If I had to guess, and I’d be happy to be proven wrong, perhaps the TE2 is polling less than once per frame, but can take less time than the UFB to process the information, whereas the UFB is polling more than once per frame (hence the more frequent results closer to 2msec, and fewer further out) but does take a touch longer to process (based on the fastest result).
Just got back from overseas. New test to prove that the results are valid with inputs for the full frame (16.66msec) and not just 1msec. Looks like they are. Also supports my impression that the polling window for TE2 is longer than UFB.
Got around to testing PS4. Had been waiting until I got a PS360+ Ver 2.10.
The UFB did come out on top, but what was surprising to me is the number of results. The other sticks gave about the expected number of results (~6000 frames of data, every 6th frame an input occurs, but only lasts for 1msec, i.e. 1/16.66 of a frame. Therefore for ~6000 frames you would expect ~60 successful inputs) in the 60s and 70s. The UFB had 240 results.
Looking at the Hori vs the Akishop boards. What I think may be obtainable from this data is 1. how quickly the controller polls for changed inputs and 2. how quickly it can convey that data to the PS4.
Let’s pretend we had the perfect stick. If it took the absolute least amount of time to poll (or conversely polled at the highest rate), and transferred that information to the PS4 in the least amount of time, it would have 100% of values in the 1msec range (assuming that is the fastest possible, thus far it has been the fastest observed).
Now, none of the sticks here meet that goal. One time only the Aki achieved 1msec results. On average it is 2msec. However there is a spread of results. This suggests to me that the polling rate is less than once per millisecond. This applies to all sticks. And if you go back to my Xbox TE2 the results were spread across almost the entire frame.
The other thing to comment on, the way this test works is every sixth frame I turn the button on for 1msec. Now, for the HRAP and Aki tests this resulted in about the right number of results. e.g. for the Aki 2.10 the test lasted for 6367 frames (time for the input to scroll all the way to the starting point). If we divide this by 16.66 and again by 6 the results is, 64, so we would expect 64 inputs over this period of time. We actually got 71, which is within just over 10% of the expected result. For the PS360+ old version we expected 133, got 139. For the HRAP V4 we expected 61 got 63. For the HRAPV we expected 61 got 75, so still somewhat close.
For the UFB we expected 62 results. We got 240! So almost four times as many as expected. This to me suggests there is something fundamentally different about the way that the UFB is reading inputs to the other controllers.