Yes, I’d hate for flames to persuade a contributor away from working on this valuable information.
@“Jazz cat” yes actually, gummo tested a similar setup and one pcb beat the other during throws but then the latter pcb beat the former during normal attacks.
Suppose you have a series of inputs that you know will be distributed evenly along the frame. That you know one will happen at 0, one at 0.001 etc.
You compare two sticks. With this, you can literally just count how many times the slower stick loses to determine by how far it is behind. The more it is behind, the more losses it gets in a steady pattern.
Now, we don’t have the luxury of robotically perfect inputs that way, sadly. However, it’s reasonable to assume that the inputs will randomly hit on different parts of a frame. If we have a few inputs, we can end up with really lopsided distributions like ten near the end, a couple more evenly random ones earlier on. Every single input matters a lot if we only have a few.
If we repeat the test many, many times, that variance begins to smooth out. We have many, many more random chances to hit parts of the frame that haven’t been hit yet, and every individual input matters less and less. Basically, it just becomes more and more unlikely that the distribution of inputs within the frame is heavily biased towards the end of the frame or the beginning or something of the sort if we conduct a ton of repeats. The amount of repeats means small accidental clusters don’t matter that much.
So if we have something that’s very likely to be a lot like an even distribution without much clustering, we can treat it as one and count the losses to get the timing. It obviously isn’t 100% - despite the repeats there’s a small chance that the input distribution is heavily skewed and some test result is invalid afterall.
The results are also tied to a console - you can guess that a stick that’s fast on PS4 is fast on PC, but we can’t say that for certain, as you can see from results like the old PS360+ or new Qanbas. Fast on one console, markedly behind the fastest stuff on another. What the results fundamentally mean is “This stick is the fastest we could find on this platform. This one isn’t behind much, this other one is by a lot”.
That would be ideal, yeah. Would cut down on the reps needed by a good bit.
…
I’ve had enough. Fuck you. Fuck your ignorant loudmouth ass. Please get out because I’ve had enough of your inane dogshit that’s so dense it could probably collapse into a singularity before actually understanding anything while actively trying to tear down people who actually do a service to the community while being a dick to anyone who dares to care. I don’t know what kind of turd-chip you have on your shoulder, but it stinks and pollutes good discussion with an endless tirade of contrarian-just-because diarrhea that serves no constructive purpose whatsoever. Your posts here are a blight of stupidity, bickering and dense unthinking insistence. If I never saw another one in this thread again it’d be great.
What he means with an absolute number, and what anyone working on measurement understands (or should understand, anyway - you don’t seem to be capable of understanding it and maybe do measurements so that’d certainly prove me wrong) it to be, is the raw, total amount of lag. Not in comparison to anything, but a raw value that stands by itself. Drive a car, measure the speed. Obviously, that’s not what Teyah measures - he measures how far behind the measured PCB is from the fastest one he can find - how laggy the measured PCB is RELATIVE to the control PCB which is the fastest one he can find for the system. Measuring absolute lag on a console setup would require some way to isolate the stick’s lag from the rest of the setup which is expensive, troublesome and doesn’t do jack to serve the purpose he set his site up for: Helping people find the fastest products. For that, you don’t need absolutes. Knowing what’s fastest and how far behind others are is enough. And his method gives us that.
Can you show me the test? Were the sticks far away or close to eachother on teyahs table? If they were close then I would expect this could happen easily
LOL
Haven’t had a good laugh in a while here.
Go back a few pages and read his results. Stick distance doesn’t matter. This was gummo not teyah.
Just incase that was misconstrued, I meant distance apart in ranking on the results table
OK so i just read gummos stuff. It sounds like he wasn’t able to come to any certain conclusion. The issue of attack distance brought up the point of the slower attack winning by counterhitting the faster one, this shouldn’t be an issue at point blank range though right? Because the first active frame either wins because it has to score the hit, or trades because both got there…
Yeah, it was a bit weird. The faster pcb should always win when the same move is executed. Counter hits are usually when a move beats the other first. Difficult to tell what was going on without a hit box viewer to see if one was really whiffing or not. If a PCB was beating the other as it whiffed then that would mean the second was seriously lagging by more than a couple of frames when you factor in active frames and recovery frames.
Gotcha, I thought you meant a literal, physical table, lol.
Yeah, Gummo was testing with Sol’s 5K which is a 2 part move. First active part is a short range knee hit for frames 3-4 and 5f onwards it extends into a full kick. So faster Sol’s knee whiffs, extends his hurtbox, slower Sol’s high priority knee counterhits it. At close distance there’s no problem, it’s just a peculiarity of how the move works.
If it’s active for a full 2 frames then the slower pcb has to be seriously lagging to cause a “whiff punish.” No pcb is lagging that bad.
Why would it? It would have to be behind just a frame.
Frame 3: Fast kick’s knee activates, slow is in last frame of startup. First active frame of fast kick whiffs.
Frame 4: Fast kick’s second knee frame. Slow kick’s knee activates. Both whiff.
Frame 5: Fast kick extends into a full kick, hurtbox connects with slow kick’s knee hurtbox and gets counterhit.
The knee has pretty high priority so it’s easy for that to happen at a specific distance.
Basically: http://imgur.com/a/XWSQ7
Ah, in that case they don’t trade or the first knee doesn’t hit the slower one’s start up. Thanks for the detailed explanation and the hit boxes along with it. I thought the boxes would have less priority on them and the faster pcb would simply hit the start up of the slower ones. I’m so used to how new SF had Lame new school layouts with tons of hurt box everywhere. Those GG boxes haves that nice, classic style to them.
Sorry if this has already been covered multiple times, but would someone mind repeating (or pointing me to) how the actual lag number in ms is being calculated? I think I understand the basics of how the test is conducted, but I don’t understand how the results of the head-to-head tests get turned in precise amounts of lag.
Say you have a hundred points along the frame, distributed evenly. You measure two sticks. Because the points are distributed evenly, you can assume an amount of lag and see how many times the slower stick would lose, right? So then you count the times and see what it matches to.
Basically this.
As we move to a later point the slower stick starts lagging. The slower it is, the sooner it starts lagging. If we had that kind of uniform, ordered input we could just see how soon the slower stick starts lagging, perform a couple repeats around that point to confirm and be done with it. Sadly, we can’t do that.
What we CAN do is run through the whole series of inputs and count the number of losses. We can see at what point a stick that is Xms slower would start to lose, see how many losses that would entail and see how many times our test stick lost. This way we don’t even need to know the order of the individual inputs - just that the spread is even within the frame. The more inputs and the tighter the interval, the more accurate we could be.
Sadly, we don’t have a uniform, ordered series of button presses within a frame. We don’t have an unordered one either. But if we just press the button a ton of times, it becomes more and more likely that our input series is a lot like the ideal one: We have more and more chances to hit a place we haven’t previously, and the more presses we do, the less any individual one matters. If you press twenty times, it’s pretty easy to get a cluster of inputs at the end or beginning of a frame. If we press hundreds of times, so many random chance events would have to turn out in a specific way that it becomes very unlikely to have happened. So we are very likely to have chanced upon a distribution of button presses that is a lot like the ideal one. If we have something like that, we can count the losses.
Example:
Toss a dice six times. I asked random.org to do it. Six tosses ended up as:
453345
1
2
3
4__
5__
6__
If our measures ended up like that, yikes. Our ideal spread would be 123456 each once.
What if we toss the die a ton?
20 tosses:
453345355236426
546361643254231
535355636212113
314143364244523
1-------
2--------
3---------------
4-----------
5-----------
6--------
Better, no? Still skewed. Individual random events matter a lot.
180 tosses:
453345355236426
546361643254231
535355636212113
314143364244523
155531564412556
125645256114645
212234112423365
433466151164162
634163366155454
241351411633255
141536356145441
313324666135253
1________________________________
2_____________________
3__________________________________
4_______________________________
5__________________________________
6____________________________
Still low on two, but more repetitions gets us a more even spread.
A little off topic, but some may find it insightful and if you watched already then oh well.
Battle(non)sense lag showdown test on PC. (fighting games)
https://youtube.com/watch?v=kYCW0Dfixv4
I am surprised with SFV results.
The numbers in the lag test are a bit misleading in the sense that USFIV and Mortal Kombat X add input lag based on the connection. Those tests were run in optimal condition.
Also, why would you want to remove v-sync when the tournament edition is v-synced?
I’d be really curious to see these results too