I’d love to test all of these sticks you guys are suggesting, but since I’m done buying sticks for the most part, I’m limited to what’s available in my area. I mean I guess I could borrow some sticks and do it at Evo, but I don’t want to be spending my Evo trip sitting in my hotel room doing this sort of thing, ya know?
No? the reaction time vs individual frame doesn’t matter. you’re adding a frame to input. which will have another however many frames added by console, then specific port, then specific port runs faster than normal meaning you have even less time to visually see what’s happening on top of all that, then maybe you add network lag, etc.
I know it’s hard for you to imagine but it’s easy to tell when something doesn’t feel right. I can tell you really have no idea what you’re talking about by your reasoning.
1 frame and reaction time isn’t a comparison that makes even the remotest bit of sense. it’s looking at how long you have in total, then reducing that by so many small amounts. so instead of having plenty of time to see it, you now have to be REALLY on your shit to catch it. so let’s say you include everything i’m talking about and add this input lag due to stick pcb/interface. suddenly a 15 frame super cancel or link is more like 13-12 frames. that is HUGE. i can easily confirm 15 frame cancels on 360/crt, 13f i have trouble, 12 is pretty much impossible for me. and that’s with an ‘ideal’ current gen port setup. now i know my stick is contributing in a bad way.
so no, not nuts at all. aware? yeah. it sucks.
the HRAP VX SE (kai) should perform the same as the VX SA correct?
It’s possible, but we won’t know for sure until the Kai gets tested. After what I saw with the Q4RAF testing confusion, I wouldn’t assume that a slightly different model of the same stick will use the same PCB.
Also, great writeup Tebbo, and Preppy too. I hope people who downplay the effects of input lag will read your posts and come out with a better understanding of why some people take it so seriously.
Also, would these results be the same on a UD-CPS2? I’m stricly an ST player so latency is very important to me.
lol people really need to start seeing the bigger picture here that its not just sf4 players but theres people who play all of these different games, some that demand extremely precise execution that want a reliable product.
in reality, am i going to care that much if i play on a madcatz stick and all my character requires is landing a st.mp buffered into shoulder cancel into red focus and i win the round? probably not. if i’m going to play someone like i-no in guilty gear where my main pressure tool is a single just frame, do sako dash lp combos with bulletta, etc, you bet your ass im going to care.
and these modern sticks are going to play a larger role in most of the gaming communities, especially with the ud-cps2, the ud jamma encoders, now a bunch of the old school purists are going to have to get a new stick, because lugging a super gun with specialized sticks isn’t feasable anymore.
AFAIK @undamned has forced the code to request updates every 1ms (frame in USB terms) from a USB device to alleviate lag as much as possible for HID. Note that for USB HID, 1ms requests are as fast as it can go per USB spec for interrupt based endpoints.
@Teyah - if you’ll be at EVO swing by the booth. I’d love to get a cerb in your hands to add to the testing, see where my hellhound stacks up 
Would be interesting seeing which has the least lag for PC out of the ps360+, Cerberus and Cthulhu
Adjusting to small differences in lag relates more to things like combo or jump-in timing, where you are able to take in a wide span of motion (think sampling many frames) and make a timing prediction. You can hit a tiny 1-frame window on purpose this way because you are predicting the timing based on a wider set of data.
For opponent reaction, even fast human reactions to a sudden event are pretty slow comparatively, so minute levels of lag are less of a factor. But it’s not like any additional delay is helping there either.
I don’t understand your Cthulhu results. I tested Cthulhu with my USB host interface a while back on an oscilloscope (yes) and it was consistently 2ms from the time the button input signal to the Cthulhu changed to the time that my host output signal changed. And it’s been so long, I might not have even been polling it every 1ms (could have been 2ms). Please re-test Cthulhu with latest firmware. If you were testing with latest firmware, I don’t know what to say other than point out that your results were grossly different than mine.
-ud
I can probably answer this actually.
Your host specifically calls the Cthulu every 1 or 2ms. However, on enumeration I’m pretty sure that the Cthulu reports to the PS3 that it’s endpoint IN bInterval isn’t actually 0x01 (1ms), but 0x10(10ms).
Essentially, you are ignoring what the device states and simply requesting it anyway, which the board can handle obviously but the PS3 itself slows the transactions down per the device’s request.
Hey I can definitely try to swing that. The Cerberus is a PS3/PC PCB, right? If you have room (and a PS3) in the booth, I can test it right there on the spot, should take maybe 20 min. I do need a new PCB for a Mad Catz shell I have laying around, so I’m hoping the Cerberus does well.
Just promise that you won’t downplay my results and make snide comments over twitter, if things happen to not turn out in your favour.
It would be interesting to see direct timing results. Something like a device that hooks up to a PCB/button input on one end, and the output of a UD-USB on the other end, and measures the elapsed time. I don’t know how feasible this is or if the UD-USB behaves the same way as a console (e.g. honoring endpoint bInterval).
IMO as consumers we should at least be informed about potential differences in performance. Otherwise things like that hdtv lag database would not have popped up. Citing top players’ performance is a weak argument and not an excuse to simply accept deficiencies of what is fairly expensive equipment. As an old school fighting game player, there was nothing more frustrating than shift to hd displays. I could not stand not knowing how laggy a set up would be come tournament time. Too many variables resulting in disgustingly inconsistent setups. Having this information is a step in the right direction. Thanks for the research.
So basically on PC I want to use my Hitbox on PS3 mode? Or is it different because it’s on PC you think?
I’m more concerned with real world, actual results on consoles (PS3 and 360) since these have the largest player base, and offer very strict controls over hardware configuration. So I don’t think I will be measuring any PC or other non-console setups for now.
Edit: Thanks Pablo. I’m in 100% agreement with you there.
I didn’t mean to suggest that you should do this, since you have already observed so many results with a different method. But if there were such a device, and its results did correlate with real-world consoles, it would be easy for anyone to test the latency of a stick.
I dunno what the room situation will be at the booth or what setups will be available but I can get you a Cerb regardless to use on whatever setup you can find.
I may take issue with people blaming their terribad gameplay on a frame of lag, but results are results and some people need that performance to eek every inch from their gameplay. If somehow my board manages to stack up really badly then it’s on me to fix and make proper. I don’t make stuff that underperforms on purpose :p.
I think based on what your current results are from other stuff, and my own understandings, the hellhound will perform in the top tier area and will juuuuust fine in your shell.
what is the delay on eightarc fusion. i know it’s the same as one of the q4rafs but which one?
Sounds good Phreak, I’ll catch you at your booth this weekend.
fakeakagi - The early Eightarc Fusions used the original Q4RAF Black board, but I’m not sure if this changed later. If you look at your PCB, if it looks like the one on my overview page (first picture of the two sticks, the PCB on the left) then it’s the low lag early Q4 PCB, otherwise it’s probably considerably slower.