Input lag for Raphnet GC vs Wiimote adapters?

[Brad251]

I want to use my NES and SNES controllers on my Wii and am going to buy some Raphnet adapters. I have two options. I can buy adapters that plug into the Gamecube ports and adapters that plug into my Wiimote. Raphnet lists the controller to Wiimote adapters as being low latency (less than 3ms) but they don't list what the input latency is for the controller to Gamecube adapters.

Does anyone have any experience with the controller to Gamecube adapters? Which adapter type would you get?

[Ikaruga11]

I would also like to know this.

The amount of lag introduced by the adapter should be the same. But with a wired connection, that is where your input lag ends. The Wii Remote will input lag of its own since it's wireless.

[bigbadboaz]

Yes, exactly. I don't have a definite answer as I don't have the GC adapters, but I can tell you the Wiimote lag (imperceptible on its own) + whatever lag comes with the Wiimote adapter + the lag inherent in my flatscreen = something I can feel in a bad way.

I have single-step wired adapters for other systems and they don't combine with the flatscreen lag into anything noticeable.

Unless someone chimes in with hands-on experience with both, you're safer getting the GC versions.

[Brad251]

Yes, exactly. I don't have a definite answer as I don't have the GC adapters, but I can tell you the Wiimote lag (imperceptible on its own) + whatever lag comes with the Wiimote adapter + the lag inherent in my flatscreen = something I can feel in a bad way.

I have single-step wired adapters for other systems and they don't combine with the flatscreen lag into anything noticeable.

Unless someone chimes in with hands-on experience with both, you're safer getting the GC versions.

Are you using one of the Raphnet controller to Wiimote adapters? Different brands of controller to Wiimote adapters are likely to have differently levels of input lag depending on how quickly the adapter converts the signal. Raphnet Wiimote adapters have input latency of 3ms or less. I use the Classic Controller Pro with my Wiimote on my PC using an LCD monitor via a DVI connection and don't notice much more lag than using a Raphnet USB adapter with my SNES controller. I have to test out using the Classic Controller Pro on my Samsung LCD TV but just using the Wiimote on my Samsung LCD TV has never resulted in much noticeable input lag.

[Xer Xian]

I've just run a few manual lag tests (via Artemio's 240p test suite) of the Raphnet SNES to GC adapter on a CRT monitor. Please be aware that this isn't a 100% reliable method for testing lag (but then again, testing controllers lag is not as straightforward as for displays).

Unfortunately I don't have an original SNES controller right now (I recently sold my childhood PAL SNES and have a 1-CHIP SFC in the mail), so I had to use a 3rd party SNES controller instead (it's called QuickShot I believe). It may or may not be laggier than the official pad. Anyway, I run 10 tests, here are the results in milliseconds and the average:

(20+10+6.67+11.67+11.67+3.33+13.33+5+5+6.67) / 10 = 9.33

The first obs. is clearly an outlier though. Taking it out and averaging over nine, lag goes down to ~8.

I also tested the Konami Hyperbeam wireless controller - a wireless controller made in the nineties? The horror! Well, not really:

(20+13.33+5+15+11.67+13.33+10+15+11.67+8.33) / 10 = 12.33

I tested the official GC controller as well to have a (very rough) idea of the error involved (no lag is impossible even for official controllers though). Results:

(8.33+3.33+3.33+8.33+3.33+0) / 6 = 4.44

Sorry, I stopped when I got a perfect score, blame my ego for this

To OP: Instead of adapters, you might consider the official SNES/SFC controller for Wii as well. It plugs into the Wiimote though, no idea of the lag involved. Anyway, in general I think people are too obsessed with lag. If you stick with CRTs, console (retro)gaming and trusted products (like Raphnet's adaptors), it's unlikely you will ever need to take lag into consideration. Really.

[Ikaruga11]

I've honestly just thought about splicing the Classic Controller Pro with GameCube wiring to plug it directly into a GameCube port.

Also, the manual lag test in 240p Test Suite is worthless. You can get a perfect 0ms with the laggiest setup ever if you adjust your timing.

[Extrems]

GameCube has variable polling rates while Wii Remotes are fixed at 200 Hz.

Most software use the default of 120 or 100 Hz, outliers are the Game Boy Player Start-up Disc and some homebrew.

The raphnet adapter itself polls the SNES controller at 200 Hz.

[Guspaz]

Beyond the normal questions of the accuracy of the manual lag test, any TV-based test is going to be biased by the fact that the screen is only redrawn every ~16.7ms. With the manual lag test having the crossing point at the centre of the screen, that means that you have ~8.3ms of display latency. If you subtract your average latency, you get ~1ms of latency, which is so far below the margin of error in a manual test to essentially be zero.

The firmware is opensource (https://github.com/raphnet). This particular firmware is the "snes2wii" repository, written in AVR assembly. I'm not really familiar with AVR assembly, but it looks like the adapter polls the SNES controller every 5ms, and the gamecube triggers an interrupt when it tries to poll input, with the raphnet adapter feeding the cube the latest known state. Some comments imply that a real gamecube controller takes 6ms to respond to the poll command, so it's entirely possible that the raphnet adapter is on par with the latency of a real GameCube controller.

[Guspaz]

I've honestly just thought about splicing the Classic Controller Pro with GameCube wiring to plug it directly into a GameCube port.

They don't use the same protocol.

[Extrems]

Some comments imply that a real gamecube controller takes 6ms to respond to the poll command, so it's entirely possible that the raphnet adapter is on par with the latency of a real GameCube controller.

Up to 1000 Hz is officially supported, WaveBirds are capped at 500 Hz though. The minimum transfer time is 368 μs.

I'm guessing the official controller is delaying the response until the last moment as to keep the data as fresh as possible.

[Xer Xian]

Also, the manual lag test in 240p Test Suite is worthless. You can get a perfect 0ms with the laggiest setup ever if you adjust your timing.

Sure, considering that "negative lag" inputs are simply discarded without interrupting the current test, you can do that. However, if you're unbiased, you shouldn't. That doesn't mean that the test is accurate of course, that's why I averaged over ten repetitions (of ten tries each, so 100 in total). It's still not 100% accurate of course, and I stated as much already.

Beyond the normal questions of the accuracy of the manual lag test, any TV-based test is going to be biased by the fact that the screen is only redrawn every ~16.7ms. With the manual lag test having the crossing point at the centre of the screen, that means that you have ~8.3ms of display latency. If you subtract your average latency, you get ~1ms of latency, which is so far below the margin of error in a manual test to essentially be zero.

I don't know if that should be taken into account for this test. Because of how it is structured (a star-shaped outline goes up and down the screen, press the button when it overlaps with the still one), you won't be basing your timing on a single-frame event but rather on the up and down motion of the star - the display refresh shouldn't be a critical factor (actually I'd say that not even human reaction time is.. which is good considering that it averages 0.2 seconds).

The raphnet adapter itself polls the SNES controller at 200 Hz.

Thanks Extrems, that's good to know. If I'm not mistaken, that means that the adapter can delay the GC polling window by up to 4.8ms (worst case scenario - it should add little to no lag every time that its polling window entirely falls within the GC's one).

[Guspaz]

I don't know if that should be taken into account for this test. Because of how it is structured (a star-shaped outline goes up and down the screen, press the button when it overlaps with the still one), you won't be basing your timing on a single-frame event but rather on the up and down motion of the star - the display refresh shouldn't be a critical factor (actually I'd say that not even human reaction time is.. which is good considering that it averages 0.2 seconds).

The problem is that the granularity of the display that you're reacting to is larger than the latency you're recording. If you look at your results, you've got such a large variation between your highest and lowest results that margin of error is huge, so any test results should probably be rounded down to the closest whole frame anyhow, which for all of your tests is zero.

Thanks Extrems, that's good to know. If I'm not mistaken, that means that the adapter can delay the GC polling window by up to 4.8ms (worst case scenario - it should add little to no lag every time that its polling window entirely falls within the GC's one).

The worst case would be 5ms, if the GameCube polls for input right before the adapter was about to poll the SNES controller. The best case would be 0ms, if the GameCube polls right after the adapter polled the SNES controller. In practice, the GameCube and Atmega timing isn't synchronized, so it's going to drift and you'll end up ranging between the two, probably with an average latency of 2.5ms.

[Brad251]

What is the input latency of the Wiimote itself? There doesn't seem to be much. Using the Wiimote on a CRT it feels very snappy.

[Xer Xian]

The problem is that the granularity of the display that you're reacting to is larger than the latency you're recording. If you look at your results, you've got such a large variation between your highest and lowest results that margin of error is huge, so any test results should probably be rounded down to the closest whole frame anyhow, which for all of your tests is zero.

Ok, that's a very reasonable criticism - I instintively thought the same when reading about a few arcade sticks' lag tests done here. You can only record lag with a discrete frame precision, sure, but since the probability of each press is uniformly distributed across the frame window (ie from 0 to 16.67 at 60Hz) you can just average it out over different repetitions. Of course, the number of repetitions is crucial here, and while 100 are probably more or less enough to account for this specific factor of variability, they're not nearly enough to account for human error, which spanned across 2-2.5 frames in my case.

The worst case would be 5ms, if the GameCube polls for input right before the adapter was about to poll the SNES controller. The best case would be 0ms, if the GameCube polls right after the adapter polled the SNES controller. In practice, the GameCube and Atmega timing isn't synchronized, so it's going to drift and you'll end up ranging between the two, probably with an average latency of 2.5ms.

Yes, that's pretty much what I figured as well.

[Extrems]

What is the input latency of the Wiimote itself? There doesn't seem to be much. Using the Wiimote on a CRT it feels very snappy.

The only problem really is dropped packets. raphnet's latency figure also include latency inherent to Wiimote extensions.

[Brad251]

I looked at this page and there is a latency table for the Raphnet controller to Wiimote adapter, http://www.raphnet.net/electronique/ext ... dex_en.php. Correct me if I'm wrong but to figure out how much latency you are getting from the combination of controller, adapter and wiimote, are you just adding up all the numbers in the table? If so, this would add up to 12.09ms (2.84ms attributed to Wiimote adapter).

Also, if I understand correctly, the Gamecube port poll time in the table is listed as .4 ms and at worst, the Raphnet controller to Gamecube adapter would add 5ms, so the total latency there would be 5.4ms worst case scenario and closer to 3ms on average? If I am correct, that could be a 9ms decrease in delay on average compared to the Raphnet controller to Wiimote adapter. That seems significant; even on a CRT.

[Ikaruga11]

I looked at this page and there is a latency table for the Raphnet controller to Wiimote adapter, http://www.raphnet.net/electronique/ext ... dex_en.php. Correct me if I'm wrong but to figure out how much latency you are getting from the combination of controller, adapter and wiimote, are you just adding up all the numbers in the table? If so, this would add up to 12.09ms (2.84ms attributed to Wiimote adapter).

Also, if I understand correctly, the Gamecube port poll time in the table is listed as .4 ms and at worst, the Raphnet controller to Gamecube adapter would add 5ms, so the total latency there would be 5.4ms worst case scenario and closer to 3ms on average? If I am correct, that could be a 9ms decrease in delay on average compared to the Raphnet controller to Wiimote adapter. That seems significant; even on a CRT.

So the Wii Remote has under a frame of lag? That's good to hear.

And yeah, that is a pretty significant difference. With a Wii Remote, you have more to worry about than just extra input lag. You have batteries to buy and keep at a good level, and wireless interference. If you're using motion controls, you also have to worry about commands being imprecise or outright not register at all, depending on the circumstances.

[Extrems]

I looked at this page and there is a latency table for the Raphnet controller to Wiimote adapter, http://www.raphnet.net/electronique/ext ... dex_en.php. Correct me if I'm wrong but to figure out how much latency you are getting from the combination of controller, adapter and wiimote, are you just adding up all the numbers in the table? If so, this would add up to 12.09ms (2.84ms attributed to Wiimote adapter).

You read it all wrong, those times are overlapped.

[Brad251]

You read it all wrong, those times are overlapped.

What is the total input latency of the wiimote, controller and adapter combo, then. Do you just add sections D and E and subtract B (adapter added latency)?

[Extrems]

You add A, B and E. I think.

It's complicated when you have BT, USB and IPC involved.