Teyah great job.
According to the test, the cronusmax is not the best solution … we noticed faults when 2 are used while … then there are 2 solutions, buy a stick to next-generation consoles or use any mod.
I ask if there will be some test with crossbone + PS360 + (new build) will always be present in the input lag but that amount … someone has knowledge about it
Thanks
:’( :’( :’( :’(
Wait so even with chronomax you can’t use qanba q4 on ps4??
Eyup.
Nothing from the PS3 works on the PS4, with the exceptions of games that include drivers for specialize controllers.
For our purposes at SRK the list of games that would work with a PS3 arcade stick is MK X, Ultimate Street Fighter IV and Skull Girls
Sony learned from their lessons with the PS3. The controller interface is locked down.
Nothing scientific as compared to Teyah here but I wired a Hori VX SA Kai and a PDP Mortal Kombat X fightpad (360 mode) to one button and did a couple hundred jabs in SF4 with RYU mirror. PDP would win 2-3 out of 10 times.
The PS4 VLX Kuro is very slow (~15 ms). A big PS4 update is coming in the next couple of weeks which includes results for the VLX, HRAP V, FC4, Xrd pad, and PS360+ V.2.1.
For now I’ll just say that those are listed in order from worst to best.
I have a VLX Kuro and a HRAP V4 for PS4 and i stop playing with VLX because it seem more laggy…
I m very disapointed , i love VLX…i wainting your update to choose a new PCB for my Kuro.
So You going to scrap your XLV because of it?
I don’t even know where to begin whats wrong with all of this.
An extra 1 frame of lag is kind of a big deal. People prefer XBox 360 SF4 over PS3 SF4 for this reason, you know.
If you want the absolute best performance for a legit (no-timeout) PS4 PCB, get your hands on one of the Guilty Gear Xrd PS4 pads. You’ll likely have to buy the Limited Box set from eBay/Amazon, which usually runs ~$75 USD, then either keep/play the game or resell it for ~$30-40.
For the person who disagreed with my results post, is there something out there that shows that I’m wrong on these?
No , i just play with my Hrap V4…time to change PCB in VLX.
And one frame is one frame…try to anti air with a 6 frames move instead of 5 frames…
@Teyah Thank for tips , but i will waiting until they have more fightstick faster.
I afraid i 'm not good to padhack.last recour i will just change PCB from my Hrap4 to my VLX.
I didn’t bother to actually click on ‘Disagree’ but I have no idea if you’re right or wrong and neither do you. Compared to how Toodles ran similar tests and how, for example, DisplayLag.com runs its tests your method allows for too many variables for me to take the results seriously.
I have some sort of idea if I’m right or not regarding the numbers I put up, actually. Here are a few points of evidence which support my methods and results:
The data I pull from the tests is incredibly consistent, regardless of which stick is being used as the control. Fluctuations fall into a standard bell curve; all sticks tested show the same trends.
http://teyah.net/sticklag/rawdata.html
All of my results line up with those of other stick/PCB testers. This includes Toodles, who actually ran the same test as I did as well as a test which split the inputs beforehand; he concluded that the results had a negligible difference. Phreakmods, another Tech Talk modder has also backed up the method I use in my tests. See my overview page for links to other tests done in Japan using the same method as me/Toodles.
The results are also consistent with real-world play - that is, testing it yourself by hand. This is also explained on my site, and the data sets are there for you to view as well. You can even reperform the tests yourself if you like, it’s quite easy.
You can also feel the 1 to 1.5F difference yourself between using a very low lag stick and very high lag stick on consoles with higher variance in PCB lag (PS3, PS4).
By the way, did you know that all of the above information has been available on my site since I launched this thread?
Yes, I was aware of this. My issue is with your methodology and your data reporting/presentation. With the methodology all you’re testing is relative lag. All it proves is that when two specific sticks are paired together that one stick lags more than the other. Re-reading your data I actually take more of an issue here as from your description you’re only able to test the specific intervals of 0f, 1f and 2f lag and yet in your reporting you’re claiming to have measured the lag of the various sticks down to the hundredth of a millisecond. I’m guessing that the various millisecond measurements you reported are the result of converting the 0f, 1f and 2f testing to milliseconds and then taking the average of that(or something like that). Yes? If that is the case then you’re claiming a specificity in your results significantly beyond what you’re testing is capable of explaining.
Oh, I wish you had mentioned that in your first post. You don’t need to guess about my methods, as they’re listed on my Overview page.
It’s essentially the same idea as people who test for “drop rates” of items in certain video games (ie. the % chance that an item will drop after fulfilling some condition). You just take a large enough number of samples to grind down to a meaningful number.
This is further supported when I ran multiple sets (of 1000 trials each) on the same PCB, showing that the results are consistent among different sets of trials. This is also from my Overview page.
I hope the numbers make more sense to you now!
Yes. As I said in another thread one inch equals and will always equal 2.54cm. Thus if I want to convert from inches to centimeters or vice versa there’s no issue in doing so. What you have done in your data processing and presentation is to convert specific increments to the lowest end of the possible range on a different scale (i.e. 0f = 0ms, 1f = 16.67ms, etc.). When in reality 0f can equal 0-16.66ms, 1f = 16.67-33.33ms and 2f+ = 33.34ms+. Here’s the thing though. No volume of testing is going to allow you to say with certainly where on those ranges your test results are occurring. The most certainty that you can say from the testing that you’ve done is with 1000 (or 500) tests of stick A vs. stick B we observed the 0f behavior x% of the time, the 1f behavior y% of the time and the 2f+ behavior z% of the time. That’s it. Anything beyond that is unscientific speculation.
If you’ve read the Methodology section it mentions that I’m assuming there to be a random distribution of inputs throughout the polling window (0~16.66 ms) that favors neither the P1 or P2 side. Going off of that assumption is how I arrive at my numbers.
And there’s nothing that I have found, logically or results-wise, that would indicate that I’m incorrect. Suggesting that each PCB is lagging in exactly 1F/2F increments, X% of the time… is kind of ridiculous. PCBs don’t know or care about the 16.6/33.3 ms thresholds, they’re just all that we’re able to realistically measure in ingame scenarios.
I haven’t mentioned anything about P1 vs. P2 side so I’m not sure why you bothered bringing it up. I’m talking about the fact that because you don’t know the distribution of inputs within the polling window that making a claim to be able to represent the average of those inputs is something that you can’t (or at least shouldn’t) do.
-_-
Suggesting that a PCB lags exactly 1.78ms when all of your measurements are in those 1f increments is also kind of ridiculous. It’s also kind of wrong (or at least unable to be verified off of your data). I am aware that the PCBs don’t care about the specific thresholds. What I’ve been saying and really all I’ve been saying is that you’ve been claiming results that are significantly more precise than what you’re capable of measuring and that, due to the fact that the conversion actually represents a range, you can’t just strait up convert frames to milliseconds. To avoid wasting any more of my own time on this and to avoid falling in the logical fallacy pit of appealing to authority I suggest you find someone who does research or who is an engineer and describe your tools, process and data presentation to them and see what their reaction is. My money is on them telling you something similar to what I’ve been saying and that is that you cannot make the claims you’re making off of the data that you’ve gathered.
I’m assuming the distribution to be random – that is, to not favour either 1P or 2P side. That’s why it was brought up. To be frank… given your failure to grasp my methodology (despite having explained it multiple times here) it really seems that you’re being intentionally obtuse. Or you (still) haven’t read/understood the methodology for some reason.
http://teyah.net/sticklag/overview.html
It’s a good thing that I’ve got 95% confidence intervals included in my results, then? And it’s not really ridiculous when your results are showing that yes, the results of the tests are accurate to within 0.05-0.3 ms upon repeated sets.
Just wanted to point out that this is exactly the same method of averaging as Four Wude, except with fewer variables (his includes actual display lag + game lag, where mine is strictly game lag):
Lowest end? Have you… read the overview? 
Here’s one example of a 0F result. Does this look like 0 ms to you?
0F = -16.66 ms - 16.66 ms. Avg: 0 ms or 0F
1F = 0.01 ms - 33.33 ms. Avg: 16.66 ms or 1F
2F = 16.67 ms - 49.99 ms. Avg: 33.33 ms or 2F
Part of the issue here, if you want to keep all findings as scientific as possible is to allow for cross-examination and criticism of your findings.
And to be free of all bias (which is the one thing Everyone of us Fail on).
The other part of the scientific process is to question EVERYTHING, including other peoples findings.
There is another part that bothers me:
No. In mathematics there is no maybe, there only absolutes. 1+1=2 every single time. Is your math correct or not? If there is any uncertainty it should not be from math but from the statistical collection of data.
It is one thing to admit there is a degree of randomness or uncertainty when it comes to the testing method (which there is to be expected) as there only so much precision one could achieve. You stated your self there is a that there is a undeniable level of uncertainty but you hold your millisecond end values as absolute (even if they are averaged results from statistical survey). If this is a statistical findings you also need to figure out if possible ether a margin of error (example +/- 5% or how ever you want to express it or to at least as close as your testing method allows). If you ask me there is an approx 33.33% margin of error +/- .
Then your final results need to reflect this.
All this, as @Nobus3r1 ver. 2.0 said highly suspect and completely not accurate. Your criteria is asking for more precision than your testing method allows.
As you don’t have your final results displaying this “gap” you have absolutes as your final results.
The truth is if you don’t even know if you are actually right or not, then in the scientific world you aren’t right period.
If you want to present a theory, present a theory. You took your uncertain results and try to present them as absolute facts and values.
That isn’t science and completely invalidates your findings.
Worst thing is people are reporting back anecdotal accounts and you are using to to reinforcing your faulty data.
After viewing your data people are reporting back that they feel a particular stick lag. With results in the hundredths of a millisecond, that should be humanly impossible to notice. As its already impossible for humans to accurately detect events that took 1/30th of a second or 1 frame in a 30 frame per second (baseline animation speed of a current gen video game).
Which is reason to believe these people convinced themselves of your findings and with a effect similar to the placebo effect they convince them selves the stick is lagging, were prior they would never notice.