LOSSLESS ADAPTERS

To get more details on the adapter, consult guides and tutorials, ask questions and get notified of firmware updates and new features, consider joining the Discord.

You may also follow me on Twitter or Youtube.

The companion app can be downloaded here.

Orders are open !

Current lead time is 1 to 2 weeks.

We temporarily can't ship to UK and Norway.

Aside from that, we ship everywhere mail reaches.

Video presentation

The only Switch peripheral that doesn't mess with your inputs.

For a live demonstration and explanation, check the video above.

Outstanding latency, the untied best for every use case.

Melee with overclock input lag comparison

Handy: small, light, sturdy, with a detachable USB-C cable. Home button on the adapter.

The adapter (without a cable) measures 89mm x 23mm x 22mm (~ 3.5" x 0.9" x 0.9").

It weights < 35g.

The USB-C cable is detachable and the adapter is C-to-C compatible, meaning you can use it to play with a Gamecube Controller on an undocked Switch (including the Switch Lite) with no other equipment than a C-to-C cable.

Rumble still works.

When playing, a short press of the button on the adapter opens the Switch Home menu.

It's also used to control lag tests, and change modes.

Plug-and-play, native 1000Hz. No drivers, no overclocks, no ports bullshit. It just works.

Using a Windows 8+ feature known as WCID, the adapter tells the PC it wants to use WinUSB. Pairing the driver in Zadig or at Slippi installation should no longer be necessary.

Using HIDUSBF (or equivalents on other OSes) isn't necessary either. The adapter naturally reports at 1000Hz. This means no unexpected reset of the polling rate can happen (as is wont to happen with Windows updates)

There are also no ports bullshit like plugging an idle controller into P1 or P2 and using the other on the official to get a faster polling rate (still not over this...)

In other words, plug it in and you're good to go.

This also means anticheats (like Valorant's) will leave you alone, and that you don't even need admin rights to get the best experience.

Integrated, easy-to-use Slippi latency tester embedded: confirm your setup matches competition settings in minutes.

With the click of a button in the companion app, you can not only test the lag of your Slippi setup, but also get a report from said app on the configuration of your setup.

Monitor refresh rates, emulator configurations, polling rate, latency stability - the app will look into everything it can check and search for potential issues, and comment on whether your results seem in line with what your hardware should afford.

It will contextualize the results by breaking down which parts of the latency can be safely attributed to some element of your setup (refresh rate, response time...) and computing what remains, the 'unattributed lag', a measure of how well your setup performs compared to how it can be expected to.

The adapter also reports the grey-to-grey data of your screen in great detail, in fact it will report the light intensity response of your setup to a black-white transition, in nits at a granularity of 0.1ms. This is useful to diagnose and measure advanced characteristics of your monitor, such as the presence of flicker, automatic brightness limiters, etc. Finally, lag test results and contexts are saved for later access, to make it easy to compare how different settings affect your setup.

XInput PC mode enables native support by Steam and virtually every PC game.

XInput is the Microsoft API used by Xbox controllers.

The PC - XInput mode spoofs Xbox controllers, that is to say they're indistinguishable from Xbox controllers from the PC's perspective (tbh that's not true, they only implement part of it because of legal reasons, which is why they won't work on Xbox consoles)

Since any PC game meant to be used with a controller supports Xbox controller, this means you can use your gamecube controller with all these games - except for the fact you have fewer buttons, which will probably cause you to remap Dpads in Steam Input to back or ZL, for instance, unless your game doesn't use these.

Made by a veteran contributor to the Melee technical ecosystem, responsible for most controller performance related things.

My first Smash related software work dates from late 2017, shortly after the Smashbox announced, and is a USB keyboard to Gamecube controller.

It was one of the first digital controller for Smash to exist, and used a unique, non-modifier based way of converting key presses to game controller states, though that's a story for another time. I played competitively on it for years, in fact I got PRd in my country in 2019.

Designing and building this was a lot of fun (and saved me from the index finger-pain I had from using claw grip on Melee Peach), so I figured I'd keep going.

When Smash Ultimate released, I tried building a TAS-bot for people to train and explore mechanics with. You'd define input sequences (with randomness, rumble triggers..) in a custom lightweight language (that I was going to call Commedia !) that would get transpiled to Arduino code to upload to an Arduino for it to spoof a Gamecube controller and run that, by holding each input it's supposed to do a frame, for 16.67ms.

That didn't work out (a video I took back then: https://www.youtube.com/watch?v=K2ckjzrTbbc) due to the input integrity problems mentionned previously.

I long searched why and how to fix it, but it would take a lot longer for me to figure that out.

First, I quickly realized Melee emulation had the same kind of issues, which, aside from making the game feel bad, also meant player learning on PC would be fed wrong feedback during training i.e, be told they're too late when they're too early or vice versa, be told they're too early or late when they had the right timing, be told they had the right timing when they were more than a frame length off...

This kinda ended my already dwindling will to compete and I set out to fix this. After learning the intricacies of USB, I looked into writing a driver that would oversample USB adapters. As I inquired online about driver specifics, Sweetlow found my questions and reached out to me about HIDUSBF, which was precisely what I was trying to build.

This, along with my studies on what adapters (and adapter ports...) resulted in my writing the Adapter overclocking guide, which is now a setup step in all Slippi installation guides.

Unfortunately, the input integrity on emulated Melee was still not as good as my models said it should be. Adapter OC only did 90% or so of the improvement it should've done - which is already a lot, but I wouldn't be satisfied with reaching anything but what could be proven to be unimprovable on.

The main culprit was the fact that emulator frames don't actually last 1/59.94s. Windows is not a real time OS, and so asking to be woken up every 1/59.94s results in you being woken up approximately at that frequency. This, combined with possibly variable time taken between the emulator "waking up" and reading the controller state results in this:

Of course having frames that are 15 or 18ms long is a problem, as inputs done 16.67ms apart are no longer guaranteed to end up 1 frame apart.
This led to the Timing Dispersion Reduction developments, enhancements to Slippi (development started for Faster Melee - Slippi wasn't a thing yet) that fixed this, by adding a middleman between the game engine and the polling thread that fed the game engine inputs cherry-picked to be 16.67ms apart.

Of course, doing anything but always sending the latest controller state you know about adds lag. This added 1.6ms.
And that annoyed me a lot. Using slightly old inputs on your end is one thing, sending slightly old inputs to your opponent is another: it's stupid.
If we know, on average, 1.6ms before the next frame occurs what we're going to use for the next frame, then how about just sending it right now ? But that wasn't an option with the architecture in place: the game engine and netcode were tightly coupled, so that messages were only sent when a frame was built, with the inputs for that frame (and recent frames too).

So I thought, why not change this ? And while we're at it, why not send important inputs that happen at any time between one frame and the next, so that if this input makes it in time, but the state of the next frame wouldn't have, this input doesn't wait an extra frame to be shown on the opponent's screen ?

This is what led to Kristal, a fork of Slippi optimized for long-distance netplay, using this netcode variation I just described, that I dubbed "subframe rollback netcode".

I made a video explaining it more in details:

There's a catch to the current implementation though: since the detection of major changes in controller state is done in response to a change in the stage, it works naturally well with devices that use a USB driver for which the mode of operation is to be notified a communication happened. This is the case of WinUSB (& libusbK), the driver used for Gamecube to USB adapters.
Unfortunately this is not the case of HidUSB, the driver used with "HID" USB devices, typically mouse, keyboards, and well, standard controllers.

At that point in time, the digital controllers for Melee all worked using HID, meaning they were not compatible with Kristal.

Also, digital controllers were not in a very good spot: Frame1s were (and are still) impossible to obtain i.e one batch of 1000 per year that sells out in 3 minutes, and B0XX had poor firmware, cost $390 to match the physical quality of a F1 light ($120) and is stolen IP anyway. The only credible alternative was building a DIY with Crane's firmware on an Arduino Micro. But even that could be difficult as there was a chip shortage.
The RP2040/Raspberry Pi Pico just released, seemingly unaffected by the chip shortage, 4 times less expensive than an Arduino Micro, and >10 times more powerful.
I decided I should make a firmware for the Raspberry Pi Pico for DIY digital controllers for Smash, and I should make it spoof a Gamecube to USB adapter, so that it works with Kristal.

This came to be Pico-rectangle, and is currently used by >500, being the main firmware for DIY Smash digital controllers (the main for non-Smash would be GP2040 !) such as the OpenFrame1.

I had kept searching for a way to fix my TAS bot in parallel all along, and by now I had found a way.

The final kick starter for the Lossless Adapters to happen came from my local community.

The local Melee Paris TOs (love you guys) found a gaming venue down to run a Melee bi-weekly - on their PCs.

By now people only wanted to play on overclocked adapters, and, well, these particular PCs required Secure Boot off run HIDUSBF. Of course, the idea of accessing the BIOS of computers rented from the gaming venue to disable Secure Boot (however unharmful that may actually be) is worthy of a fit of laughter.

So they reached out to me, how to avoid doing that ? I didn't know of a way then, but I told them, having already done Pico-rectangle that pretends to be an adapter - what if I build adapters that are native 1000Hzs ?

And thus I began building adapters.

These chunky things were the controllers are plugged in vertically and the port is Micro USB were the first adapters that made it to tournaments, in September 2021 ! They weren't pretty, but hey, they worked. Also, don't leave them in the sun.

I've put virtually all my free time since then on the Lossless Adapters (not that I was doing much other than Melee stuff the 3 years prior either). Here we are now in March 2023, 18 months later.

I guess going from a prototype that works "well enough" to a professional product you're proud to put on the market just takes that much time.

Of course I've only discussed the big projects. There were other, smaller contributions, such as adapter hotswapping on Slippi, an adapter IO logger for Phobos, an open source lag tester prototype on Github, a Gamecube spoofing library for the RP2040 (The Phob 2 is built on that one btw) or projects that never saw the light of day because I forbid myself from seriously working on other things than the adapter until I was done or I'd never finish them (like an analog all-button controller)

Pretty bummed about that one. The premise was hella cool.

Inchallah I fix Kristal now.

Advanced firmware updater built-in, allowing for bugs or new features to be fixed/added down the line.

The Lossless Adapter Manager app is a cross-platform application used to update, extend and configure your adapter.

As of writing, it looks like this. To talk to your adapter, the app needs it to be in configuration mode. To enter it, plug it in while holding the button on the adapter. Or, if it's in a compatible (Switch/Dolphin or Slippi lag test) mode, click "Pull into configuration mode" after plugging it in normally.

The "Save to device / Update and save" button will, aside from saving your configuration, update your programs.

Support for multiple configurations for personal use (remapping, deadzone modifications...) with a dedicated UI.

There's no physical mode switch on the lossless adapter, as you may find on other adapters.

This is because it may support a lot more than 2 modes. It embeds a whole mode management system, and is organized as follows: a mode (a line in "Modes" in the app) is the combination of a program, and a profile, and optionally, an access code.

A program is kind of like WiiU/NS vs PC on the Mayflash: it makes the adapter transform into something else in the eyes of whatever communicates with it. The mode available at launch are Switch/Dolphin mode, Slippi lag test and the 2 PC modes, XInput (recommended) and DInput.

A profile is a way to alter the behaviour of a program, for programs that support it. For instance, the "WiiU/NS" mode supports configuring remappings. There's always a "<Default>" profile available to any program (renamed <Tournament> for Switch/Dolphin mode).

So say you want to play most games with the default GCC mappings but for a particular game (that doesn't have built-in remapping) you really want to have a A and B remapped. You would configure a profile for that program and configure a mode with the WiiU/NS program, and that profile. And after saving and entering it, there you go !

A live demo of that is done during the presentation video, by the way.

This brings me to loading modes, there are two ways, the simple, and the get-out-of-jail card.

The simple is to open the app, ensure the adapter is in sync with the app (load or save), and then clicking "Launch" next to the mode of your choice. You're now in that mode until new directives happen.

The 2nd is here in case you end up at an Ultimate tournament with your adapter in PC mode or in a custom, illegal mode (with turbos). You have a way to put it into the "Tournament mode" which is, WiiU/NS with the default profile. To do this, enter configuration mode by powering the adapter while pressing its button (plugging to anything, for ex a Switch dock, is fine). Then enter the "access code" you see on the right of the app window, in morse code.

For the tournament mode, that's ".", i.e one short press. You may not change it.

In time (after the companion app is available on Mac/Linux) there should be little use for other access codes, but I put them in the initial adapter configuration anyway (PC = - ) in case someone, for any reason, can't seem to use the app to change mode anymore.

Designed for competitive Smash by a former TO.

You may use custom profiles at home, but not at tournaments. But, if using your personal adapter, no one may take notice. This is why the Lossless adapter makes it very obvious whether you're in tournament mode (ie no profile) or not: the led will either be green or red. If it's green, you're good to go. If it's red, you might not be.

Note a red light doesn't necessarily mean unfitness for tournaments as some profile options are benign (e.g changing what a long press of the adapter button does), but a green light means things are on default for sure.

By the way I used to TO these. much falco