1


Joystick PC input lag movie
Left - MadCatz Fightstick TE for XBOX360
Right - HORI RAP VXSA

Joystick PC input lag HRAP VX vs HRAP V3
Left - HORI RAP V3SA
Right - HORI RAP VXSA

2

Here are the videos:

REAL ARCADE Pro.VX?TE???(9) <— TE vs HRAPVX-SA
REAL ARCADE Pro.VX?V3???(9) <— HRAPVX-SA vs HRAPV3-SA

If you do not have a Nico account, you can use the redirector:
Nicovideo Redirector

3

I question the validity of testing input lag for console sticks on a PC. They’re very detailed tests, and I appreciate his method of wiring the buttons for perfect simultaneous presses, but most people will be using them on consoles.

With that said, it is an interesting topic for research. I never imagined the TE would have input lag, or that a VX-SA and V3-SA would be anything but equal.

4

Man, I don’t want to have to worry about lag in my controller on top of lag in my console and lag in my TV. Not that I’m good enough for it to matter, but still…

5

[media=youtube]uuQsxQJl8xQ[/media]
[media=youtube]qjz-nka-M2k[/media]

Joystick PS3 input lag movie
Left - SEGA VirtuaStick High Grade
Right - BUFFALO BSGPAC01BK

6

Always gonna be lag. I was wondering when the forums were going to start bugging each other about this, or who would simply settle for what they have. Like “should I use Al or Cu, what gauge, did I use too much, what about the resistance that quick disconnects add?!? You mean I have to buy a $300 stick for me to have least lag? You mean my $300 DOES have lag?”

Nothing changes that fact that people and pros are playing with the sticks that they have and winning competitions. I am not saying this isn’t a great conversation piece, because like I said, I have been wondering about it.

7

Didn’t Toodles run tests using frame delay or something for his Cthulhu (using VF5 I believe)? Maybe we can apply the same to the TE, HRAP, etc.?

8


http://d.hatena.ne.jp/video/niconico/sm11383433

HRAP3 VLX vs HRAPEX VLX
HRAP V3SA vs HRAP3 VLX
HRAP VXSA vs HRAPEX VLX
HRAPEX VLX vs BUFFALO BSGPAC01BK

9

The testing, at minimum, needs to be re-run with sides and ports switched. Games systems will probably favor one side or the other . I haven’t tested but would be willing to wager that an SNES, for example, will favor one port over the other. USB is host-driven, so the order that the PC/Console requests the input is going to matter.

I didn’t see the experimental set-up. but naively wiring buttons together isn’t necessarily going to give fair results. IIRC the HRAPs are not common ground, and the TEs are, so this may be a more sophisticated set-up that doesn’t have that issue.

In theory, what you want to time is the interval between switching the button/stick direction, and the first time that the change in state is reported back to the console/PC. I’m not sure how you’d do that well without involving USB debugging tools at some level. On older systems - like the SNES or PS1/2 it’s probably possible to do this sort of testing with an oscilloscope.

10

Dang man… The Japanese trying to crap all over anything worthwhile Western made.

11

Actually, all the HRAP in this Thread are Common Ground.
Even the Xbox 360 one.

12

Yeah, I misremembered trying to hack an old Hori stick into a non-common-ground Xbox pad.

13

So according to this guy, the fastest stick around is an HRAP VX-SA. Apparently it trumps everything…on a PC, at least.

That’s pretty messed up if the Premium VLXes have more input lag than the VX/V3-SA!

There are still too many variables here for me to take it as gospel, though.

14

I really could use a good translation of the conclusions and test count (how many tests, how many test did board 1 go a frame faster, how many did board 2 go a frame faster, etc) and also whether he swapped the inputs on the hub and retested. From what I can see, the idea of using a single button with a signal line from each board going to a button is very valid, and testing on a PC is fine.

Some mention about the frequency of checks from each board would be good as well. USB devices like these actually tell the host ‘hey, I need you to check to see how I’m doing every X milliseconds.’ Its part of the ID that all USB devices send when they’re connected.
Sadly, I dont have the budget to recreate all of this.

It’s valid.

15

The diodes should make it clear. In regard to non-common ground boards, that can be done to with a minimal amount of electronics. Non-issue.

Uh, no. This kind of mind set is natural, but lands at the intersection of impossible, wrong, and pointless.

16

Oh, I didn’t mean technically invalid. I’m sure it’s valid for PCs. I’d just like to see him use the same method on consoles, since that information would be a lot more relevant to me.

If someone hasn’t done a summary of his methods by the weekend, I’ll try to devote some time to breaking it down…

17

I’d be much obliged if you could elaborate on this.

If I make a couple of naive, but reasonable, assumptions then the way that the game processes input becomes something that really wants to be controlled for. I haven’t tested SF4, but SSF2T HDR apparently only samples input once per player per 60th of a second. (Presses shorter than 1/60 of a second have roughly the expected chance of being ignored.) Assuming, for a moment, that the button press is longer than 1/60 of a second, then what is perceived as relative lag could be the result of game sampling one player before the other.

If the game processing each frame is something like:



|-5ms-|          |-5ms-|          |-5ms-|
|-----(P1 latches)-----(P2 latches)-----|

Then, even if the sticks are equally fast, evenly distributed random button pushes should produce a ‘faster’ result for P2 about 1/3 of the time.

Now, this is obviously an exaggerated case, and it might not match the experimental results (no Japanese here either), but if the difference always one-sided, and never more than 1 frame…

I suppose the thing to do at this point is to wire up my own setup and do my own tests with a frame-by-frame capable recorder and see what’s going on. :rolleyes:

18

Which I’ve done using the recording in VF5, and the original tester in the articles linked in the OP is doing with recording an emulator session. Totally valid. For some X number of tests, you’ll end up with action being performed dead even Y times, one board a frame faster Z times, other board a frame faster A times, and even occasion two frame differences. No problem, all of which is good and valid, since you’re dealing in frames. The problem is, that has nothing to do with this:

You could do a large batch of tests, and say that out of some percentage of times, one controller was a frame faster than the other. The problem I have is trying to assign a number to it. I know the folks here, and a ton are going to be all ‘Damn dude, you gotta put a XYZ pcb in it, it’s 3 milliseconds faster than what you’re using now.’

If you order multiple packages on Monday to see how long FedEx and USPS take to deliver, and out of thirty tried, 13 from FedEx and 11 from USPS arrive on Wednesday, and the last two from FedEx and 4 from USPS arrive Thursday, it’s perfectly valid to say that 13% percent of the time, FedEx arrived a day earlier. But it seems silly and disingenuous to say the FedEx was an average of 1.2 hours faster.

19

Someone should really write an application to test these sort of things. Should be pretty simple as well. The application startup and run two timers which are configured to stop based on inputs from different joysticks. With that dude’s setup, it would be very easy to quantify the average lag difference (it would simply be the difference of the timers).

20

SFIV4TE vs COOL stick

View My Video