I like when he sometimes counts the frames faster and sometimes slower.
He shouldve used an on screen timer.
It wouldve also been nice if he tested the PS360+ without the adapter also. I believe he used some random stick for the adapterless test.
To play Devil’s advocate, every testing method so far is heavily flawed.
The only way to really get to true results of each stick is to bust out a data bus probe and a oscilloscope, don’t even bother looking at the TV screen.
Look at the data packets recorded on the Oscilloscope coming out compared to the electrical pulses from the button inputs.
Although you can’t deny having a indicator light in the video shows when the button activated compared to when the animation starts.
The Light represents a known value to measure frames against. In our level of perception the light appears to be instantaneous, but in actual science not even light is truly instant.
(the speed of light is actually 299,792,458 m/s or 671 million miles per hour).
I don’t expect anyone actually do this as the equipment is quite expensive for this level of testing.
And those who have a modern oscilloscope than can display binary and hex information are probably busy with other things.
I don’t like that test at all, that’s why I’m interested in Teyah’s results with the converter.
That test you posted is only rounded to the nearest 16.67ms, and it’s turning me off from the converter because according to the video, it’s sometimes 1 frame of delay, sometimes 2 frames of delay. I can not accept a frame of delay.
I have read all of your opinions on this subject, and I respect them, I do not need to hear them again. I simply would like to see Teyah’s results with the Brook ps3-ps4 converter, to see how it compares.
I’d agree with Darksakul about the fact that the shown test method is flawed, but then again his suggestion wouldn’t really cover reality either.
In order to rule out all other problems (not just damn slow lcd displays) three (or actually four in case of a converter) probes would be needed, testing
A: the moment a given pcb starts sending data packages
optional B: the moment a given daisy chained pcb such as the brook starts sending it’s data packages
C: the moment the target system sends out the refresh for the screen
against X: the moment the switch closes it’s circuit.
Given the fact that C is pretty much always a blackbox environment, I can’t even imagine what level of reverse engineering would be required for such a scenario, but a least to me, it often feels that the very same game varies in responsiveness, depending on which platform it’s running on and I’d like to get rid of this variable as well.
edit:
Essentially, it comes down to whether we’re interested in the speed (or slowpoke-ness) of the peripheral itself, or a combination of it along with the platform + game.
If it’s the former we’re looking at, pressing the button will make things happen; and it wouldn’t even matter, if that took a microsecond, a millisecond, a second, an hour or a decade - eventually the small guy would beat the big guy on the screen. However, since it’s games we’re talking about (i.e. something interactive), what we’re dealing with is a situation where eventually, the big guy will get annoyed enough to fight back, and this specifically is why we’re interested in the >overall< time it’ll take for our small guy to react, once we react.
Ergo, it doesn’t make a whole lot of sense to perform these checks with a randomly chosen game either, cuz chances are there might be a different application (“hello world” anyone?) that may show less delay.
Alas, the flashing LED method compared against the target LCD has been “industry standard” for quite a while, as shown by the fact, that ben heckendorn has been selling kits with led-bar gamepads for this very purpose ever since the last console generation and still does with the current one.
C assuming it is a black box environment isn’t feasible.
If were doing just straight PCBs I say A, B only works for converters and we can only sniff the USB data lines, I doubt we can find other test points. Maybe the chip on the encoder if the pin out on that chip is known.
My suggestion is to look at the input/out put at the logic level of the board. That doesn’t give you a whole picture but it gives you a larger picture than seeing who can punch who first in street fighter.
We also have to factor in things such as the console, game engine, ect… Those are all unknown values. Without analysis the logic of each board all we can do is do a comparative survey of how each board rates against each other with our only known values are the frame rate and knowing how long each frame takes. We also identify exact timing not possible as as long as a input is received during that frame, all inputs in that frame happens simultaneously at the next frame of animation.
If you can’t accept 1 frame of delay, you are really apart of the wrong scene, its a huge part of whats wrong with the FGC. We need to be realistic here, no human alive can with their own senses detect events happening in 16.67ms time frames. Not even the greatest of Olympic athletes ever demonstrated that level of perception, not in practice and not in competition. Were talking super human levels of timing, sight and spacial awareness.
If 1 or 2 frames discourages you, you need a reality check. Also No matter how good the converter is, you always have some additional lag introduced. You just introduce another process to the chain of events, and nothing is instantaneous, not even light.
I’m not concerned about detecting events happening in 16.67ms time frames. I’m concerned about being 1-2 frames behind my opponent. That’s called a disadvantage. I play offline on the same monitor as my opponent. If you don’t understand what’s wrong with being 1-2 frames laggier than your opponent, you are really a part of the wrong scene :).
I will not accept that delay. I am posting because I am interested in Teyah’s results with the Brook converter.
If you want the absolute lowest lag then you shouldn’t be looking at any converters.
Look at last Evo winners, many of them played on some “lagging” sticks. Your biggest disadvantage or your best advantage is 12 inches behind your shades (Ansel Adams) not your stick and not it’s PCB.
Also @Tensho is right, if you are so concern about lag you would never touch a converter. Although the Brook converter is the first converter in a long time that almost impress me.
You guys are jumping to conclusions lol. I’ve been around a looooong time, I’ve never seen a converter that didn’t lag. That should be common sense. I plan to pad hack a Horizon FC4 to put in my SAC stick.
However, I’m just insanely curious how much or how little the converter lags.
Also, idk about you guys, but 1 frame of lag has a huge effect on me. I can tell right away and it throws me off. Don’t know why I’m so sensitive to lag, maybe it’s the autism.
(Not a joke to offend anyone there. I am literally autistic.)
This is 100% the only way to know for sure and until this is done calling a stick “laggy” seems kind of bogus.
Wondering if any testing of retro consoles has been done? Maybe this isn’t the point of this thread, but I’ve got a couple custom fights sticks, both MC Cthulhu dual-modded with 360 pad hack. The sticks work flawlessly on all systems I have (DC, PS3, Xbox 360, Xbox, PS1, PS2), but not on the Sega Saturn. It’s hard to tell if it’s input lag or something more like dropped input detection. When playing any fighters on Sega Saturn, it feels like playing the original (1987) Street Fighter…very difficult to pull off specials and supers.
Anyway, wondering of the Sega Saturn has been tested with this particular setup, as part of your testing?
Retro consoles, depending on which one you look at is a moot point.
Something like the Atari 2600 and other consoles that has similar DB 9 controllers would offer zero lag as their no electronics in the controller. Its just wires and switches/ button contacts.
The same goes with the Neo Geo consoles, there no actual hardware electronics inside its all just wires and switches. Older Sega consoles like the Sega Master System also fits in this boat.
Consoles like the NES and SNES are also really fast when it comes to input delay. They use a 4021 parallel to serial shift register (a off the shelf part then and now), they have no buffers, and there zero processing. You only get raw byte values with each button press.
The Sega Genesis/ Mega Drive is weird how it fits in, it uses the same pins and signals as the Sega Master System controller, So one pad can work on the other. It also why a Sega Genesis controller can be used on a Atari 2600. The Start, A and B buttons on a 3 Button controller works on High/Low Logic. There is a Select line (not a button) when held high allows for certain button presses, and when low switches to the others.
The Directional and B button are not dependent on the Select line, only Start, A and C buttons. The 6 button pad is a different can of worms and I need to look into it more.
Its only when controllers get more complicated when the issue arrives, when the on board encoder has a degree of processing is when you start to see actual lag.
Good information. So, specifically for the sega saturn, should zero input lag be expected?
the Saturn, I am little foggy on. I say it should be very low if not zero.
@Teyah, any plans on testing the Chun-Li TE2? Or has it been confirmed to have the same fast PCB as the older ones?
Yeah, @Teyah, there are some new controllers I would be interested to see you test.
TES+, TE2+, FightStick Alpha, and FightPad PRO
HRAP.4 Kai Silent
http://www.amazon.com/Arcade-Silent-Fight-Stick-PlayStation-4/dp/B015PRGF06
The new HRAP.V Hayabusa and Fighting Commander 4
Fighting Stick Mini 4
Hello there…
I’d like to ask, @teyah if did you test the BROOK PCB.
Does anyone have any opinion about it?
Lag sensitivity is contextual:
For example, there’s some magic threshold (IIRC around 100ms or 6 “frames”) where the delay of game reactions to button presses becomes noticeable, and, in terms of experience that’s a huge difference. Everyone notices the frame of delay that puts them over the threshold.
Audio timing acuity is better than visual timing acuity.
Visual timing is worse in low-light conditions.
And so on.
I’m super curious about the TES+ and TE2+, myself. General consensus is that the HORIs with the touchpads have problems likely because of the touchpad, right? Wondering if these would suffer the same issue.
It’s not because of the touchpad