ADAPTATEURS SANS PERTE
Pour obtenir plus de détails sur l'adaptateur, consulter les guides, tutorials, poser des questions et être informés des mises à jour du firmware et nouvelles fonctionnalités, je vous invite à rejoindre le Discord.
Vous pouvez aussi me suivre sur Twitter et Youtube.
​
L'application de mise à jour et configuration peut être téléchargée ici.
​
Les commandes sont ouvertes, le délai de fabrication est de 1 à 2 semaines.
Vidéo de présentation
Le seul périphérique pour Switch qui ne fait pas foirer vos inputs.
Pour une explication et une démo en live, regardez la vidéo ci-dessus.
Latence exceptionnelle, strictement la meilleure dans chaque cas d'utilisation.
Pratique: petit, léger, solide, avec un câble USB-C détachable.
L'adaptateur (sans câble) mesure 89mm x 23mm x 22mm et pèse 35g.
​
Le câble USB-C est détachable et l'adaptateur est compatible câbles C-C, ce qui signifie qu'il est possible de l'utiliser pour jouer sur Switch non dockée (y compris la Switch lite) sans autre équipement qu'un câble C-C.
​
Les vibrations fonctionnent.
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, 1000Hz natif. Pas de drivers, pas d'overclocks, pas de "ports à utiliser". Ca marche, tout simplement.
En utilisant une feature de Windows 8+ dénommée WCID, l'adaptateur signale au PC qu'il veut qu'on lui associe WinUSB. Par conséquent, lui associer le driver en utilisant Zadig ou l'installeur Slippi ne devrait plus être nécessaire.
​
Utiliser HIDUSBF (ou équivalents sur les autres OSs) n'est plus nécessaire non plus. L'adaptateur échantillone nativement à 1000Hz. Cela signifie également qu'il n'est plus question d'avoir l'overclock qui disparaît inopinément, comme c'est parfois le cas avec les mises à jour Windows.
​
Il n'y a plus non plus de délire à la mettre un controlleur inactif dans le port 1 ou 2 et jouer sur l'autre pour avoir un meilleur échantillonage (merci le stagiaire chez Nintendo)
Bref, vous le branchez et vous êtes bons.
​
Ca signifie aussi que vous ne devriez plus avoir de problèmes avec les anticheats, comme celui de Valorant. Vous n'avez même plus besoin de droits d'admin.
Testeur de latence de setup Slippi embarqué. Confirmez que vous êtes en conditions de tournoi en quelques minutes.
En un appui de bouton dans l'application qui va avec l'adaptateur, vous pouvez confirmer le lag de votre setup, mais aussi avoir un rapport de la dite application sur la configuration de votre setup et les potentiels problèmes.
​
Fréquence de rafraîchissement des écrans, configuration de l'émulateur, fréquence d'échantillonnage, stabilité de la latence - l'appli va regarder tout ce qu'elle peut et chercher ce qui pourrait causer un problème; puis enfin juger de si la performance de votre setup a l'air cohérente avec le hardware qui le compose.
​
Pour en voir une démo en live, regardez la 2ème moitié de la vidéo de présentation.
Le mode PC XInput permet une compatibilité native avec Steam et la quasi totalité des jeux PCs se jouant à la manette.
XInput est l'API de Microsoft utilisée par les manettes Xbox.
​
Le mode PC - XInput se fait passer pour des manettes Xbox indistinguables par le PC de vraies manettes Xbox (par contre pour raisons légales elles ne fonctionneront pas sur Xbox).
​
Puisque tout jeu PC censé être utilisé avec une manette accepte les manettes Xbox, ça signifie que vous pouvez utiliser votre manette Gamecube pour jouer à n'importe quel tel jeu, à part qu'il vous manquera des boutons (du coup vous voudrez probablement remap votre dpad à ZL/back dans Steam Input, sauf si votre jeu ne les utilise pas)
Conçu par un contributeur de longue date à la communauté Mêlée, auteur de quasiment tout ce qui attrait aux inputs récemment.
Mon premier projet relatif à Smash date de fin 2017, peu après l'annonce de la Smashbox, et est un adaptateur clavier USB vers manette de Gamecube.
C'est l'une des premières manettes digitales Smash, et utilise un système de conversion digital/analogique unique non basé sur des modifieurs. J'ai juste compétitivement dessus des années, d'ailleurs j'étais 11ème sur le PR français de Mêlée en 2019.
​
C'était marrant à design et construire (et ça a sauvé mon index droit qui mourrait de Peach de Mêlée en claw grip), du coup j'ai continué.
​
Quand Smash Ultimate est sorti, j'ai essayé de construire un TAS-bot pour que les gens puissent l'utiliser pour s'entraîner et explorer les mécaniques du jeu. Je l'ai d'ailleurs démo à certaines Smashfests grenobloise (spoiler il gagne à Mario Party)
L'idée était de pouvoir décrire une séquence d'inputs dans un langage léger (que j'allais nommer Commedia :D ) puis le transpiler vers du code Arduino qui une fois chargé dans un setup approprié, répèterait la séquence (avec des triggers et autres trucs). Ca marchait à base de tenir l'input à faire pendant une frame pendant 16.67ms, ce qui, si vous avez regardé la vidéo de présentation, a évidemment merdé.
​
Une vidéo que j'ai pris à l'époque: https://www.youtube.com/watch?v=K2ckjzrTbbc)
​
Du coup j'ai cherché pourquoi et comment le réparer, mais il me faudrait longtemps avant de trouver.​
​
TODO-
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.
Système de mise à jour de firmware avancé, permettant de résoudre d'éventuels bugs ou d'ajouter de nouvelles fonctionnalités.
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.
Possibilité d'ajouter plusieurs configurations pour utilisation personnelle (remappings, turbos) avec une interface dédiée.
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.
Conçu pour l'utilisation en tournoi par un ancien 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
​
​
