GithubHelp home page GithubHelp logo

jonnyhaystack / haybox Goto Github PK

View Code? Open in Web Editor NEW
168.0 9.0 173.0 587 KB

Modular cross-platform firmware for digital or mixed analog/digital game controllers

License: GNU General Public License v3.0

C++ 95.71% C 4.21% Python 0.07%

haybox's Introduction

HayBox

HayBox is a modular, cross-platform firmware for digital or mixed analog/digital controllers, primarily targeted at B0XX-style controllers.

GitHub issues GitHub pull requests

Table of Contents

Features

Features include:

  • Cross platform support:
    • RP2040 (e.g. Raspberry Pi Pico)
    • 16MHz AVR MCUs (e.g. ATMega32U4 which several Arduinos are based on)
  • Supports many existing controllers/PCBs, e.g. B0XX, LBX, Smash Box, Crane's GCCPCB/Model S
  • Supports a variety of communication backends which can be used either separately or in conjunction with each other:
    • XInput
    • DInput
    • GameCube console
    • Nintendo 64 console
    • Nintendo Switch console
    • B0XX input viewer
  • Supports a variety of "input sources" which can be used in conjunction to create mixed input controllers:
    • Buttons/switches wired directly to GPIO pins
    • Switch matrix (as typically found in keyboards)
    • Wii Nunchuk
    • GameCube controller
  • Melee mode up to date with B0XX V3 specifications
  • Existing modes for popular games (e.g. Melee, Project M, Ultimate, Rivals of Aether, traditional fighting games)
  • Easy to create new controller modes (or keyboard modes) for different games
  • USB keyboard game modes for games that lack gamepad support
  • Fully customisable SOCD cleaning, allowing you to configure SOCD button pairs (e.g. left/right, up/down) for each controller/keyboard mode, and also easily change the SOCD resolution method for each SOCD pair
  • Switch modes on the fly without unplugging your controller
  • Automatically detects whether plugged into console or USB
  • Game modes and communication backends are independent entities, meaning you can use any game mode with any supported console without extra work
  • Easily switch between different GameCube/N64 polling rates in order to have optimal latency on console, overclocked adapter, etc. (not necessary for Pico/RP2040)

Installation

If you want to simply use a pre-built firmware with default pin mappings and configuration, refer to the pre-built binaries section. If you want to make any changes to the code, refer to the building from source section.

Pre-built binaries

  1. Browse the existing configs to determine which config is appropriate for your hardware
  2. Download the corresponding artifact from either the latest HayBox release, or from a workflow run if you want the latest development version (unstable).
  3. Flash the firmware to your microcontroller in the usual way
    • If you are using a Pico/RP2040 build (.uf2 file), simply put it into bootsel mode while plugging it into your PC, and drag and drop the .uf2 file onto the RPI-RP2 drive that comes up
    • If you are using Arduino/AVR build (.hex file), you can use a program like QMK Toolbox to flash the .hex file to it

Building from source

There are currently three main ways to build HayBox:

  • Locally using PlatformIO IDE for VSCode or PlatformIO CLI
  • In the cloud using GitHub Codespaces
  • In the cloud using GitHub Actions

Both GitHub Actions and GitHub Codespaces require you to create a GitHub account, but do not require you to install any dependencies on your local machine.

Building locally

The following dependencies are required when building locally:

After installing all of the requirements, download and extract the latest HayBox release, or clone the repository if you have git installed (which makes it easier for you to pull updates).

After that:

  1. Open Visual Studio Code
  2. If on Windows and it's your first time building HayBox, run the command git config --global core.longpaths true in any terminal (within VS Code or regular cmd/PowerShell are all fine)
  3. Click File -> Open Folder and choose the HayBox folder (the one containing platformio.ini, not the folder above that)
  4. Choose the appropriate build environment for your controller's PCB by clicking the environment selection button near the bottom left of the window

image image

  1. If your controller has a different pinout than any of the existing configs, you may edit the button mappings and other pins at the top of the config (config/<environment>/config.cpp). Any buttons that your controller doesn't have can simply be deleted from the list.
  2. If you see a message in the bottom bar saying "Rebuilding IntelliSense Index" or "Loading Project Tasks", wait for it to disappear. For Pico especially it may take quite a while the first time because it has to download 2-3GB of dependencies.
  3. Click Build (in the bottom left) and make sure everything compiles without errors
  4. This next step differs depending on the microcontroller used in your controller.
    • For Pico-based controllers: hold the bootsel button while plugging it in (or your Start button if you already have HayBox installed) and then drag and drop the file HayBox/.pio/build/<environment>/firmware.uf2 onto the RPI-RP2 drive that comes up.
    • For Arduino-based controllers: Plug in your controller via USB and click Upload (next to the Build button)

Building using GitHub Codespaces

This is probably the most convenient way to modify and rebuild HayBox, but bear in mind that GitHub's free tier places some limitations on how much you can use Codespaces each month. Because of this, you will want to make sure you shut down your Codespaces when you aren't using them, in order to maximise what you can get from your quota.

First, create a GitHub account or just log in if you already have one, then fork this repository and open your fork in a new Codespace by clicking the green Code button -> Codespaces -> Create codespace on master. This should open VS Code in your browser with all of the necessary extensions and dependencies pre-installed. From here, the process is much the same as building locally, except you can't use the Upload button to flash the firmware. You will instead have to download the compiled binary from HayBox/.pio/build/<environment>/ and flash it manually (see here for more on that).

Building using GitHub Actions

This repository contains a GitHub Actions workflow definition that builds each PlatformIO environment specified in the matrix on every push, and uploads firmware binaries as artifacts which you can download by clicking a specific workflow run from the history. You can create a fork of this repository and enable Actions by clicking Settings -> Actions -> General -> Select "Allow all actions and reusable workflows" -> Save.

The fastest way to make changes if you only want to build via GitHub Actions is to use github.dev. You can do so by simply pressing . on your keyboard while you have your fork of this repository open, and it will open a VS Code editor in your browser. This does not give you the same development capabilities that you'd get in a Codespace, but it does allow you to make changes and commit them directly from your browser. Change whatever you'd like, then use the Source Control tab on the left to add, commit, and push your changes. Finally, go back to the repository and click on the Actions tab, click on your workflow run, and wait for it to build the artifact.

If you are adding a new device config/PlatformIO environment, you will have to add the environment to the matrix in order for it to be built by the GitHub Actions workflow. You can also remove any environments from the matrix that you don't care about in order to reduce resource usage and potentially speed up your builds.

Usage

Default button holds

Pico bootsel mode

To reboot Pico-based controllers into bootsel mode, hold Start on plugin.

Brook board passthrough mode

To switch to Brook board mode on GCCPCB2, GCCMX, B0XX R2, or LBX, hold B on plugin.

Communication backends (console selection)

Communication backends are selected slightly differently depending on the type of microcontroller used in the controller.

On Pico/RP2040, USB vs GameCube vs Nintendo 64 is detected automatically. If not plugged into a console, the default is XInput, which should work plug-and-play with most PC games. Other backends are selected by holding one of the following buttons on plugin:

  • X - Nintendo Switch USB mode (also sets initial game mode to Ultimate mode)
  • Z - DInput mode (only recommended for games which don't support XInput)

On Arduino/AVR, the DInput backend is selected if a USB connection is detected. Otherwise, it defaults to GameCube backend, unless another backend is manually selected by holding one of the following buttons on plugin:

  • A - GameCube backend with polling rate fix disabled (used for GCC adapters)
  • C-Left - Nintendo 64 backend (60Hz polling rate)

Game mode selection

Unlike other similar firmwares, HayBox by default allows you to switch modes on the fly without unplugging your controller. This is mainly useful on PC, as opposed to console where you usually have to restart the console to switch game anyway. It also serves the purpose of reducing the number of buttons you have to hold with one hand while plugging in.

The default controller mode button combinations are:

  • Mod X + Start + L - Melee mode (default)
  • Mod X + Start + Left - Project M/Project+ mode
  • Mod X + Start + Down - Ultimate mode
  • Mod X + Start + Right - FGC mode (Hitbox style fighting game layout)
  • Mod X + Start + B - Rivals of Aether mode

Default keyboard mode button combinations (only available when using DInput backend, not with XInput):

  • Mod Y + Start + L - Default keyboard mode

Dolphin setup

HayBox needs a different Dolphin controller profile than the official B0XX firmware, as it uses different DInput mappings that make more sense for use across multiple games. These can be found in the dolphin folder in the HayBox repo. The profile files are named to indicate what communication backend and operating system they are for:

  • For Windows:
    • HayBox_XInput.ini - For Pico/RP2040-based controllers (e.g. B0XX R4)
    • HayBox_DInput.ini - For Arduino/AVR-based controllers (e.g. B0XX R1-3, LBX)
  • For Linux:
    • HayBox_XInput_Linux.ini - For Pico/RP2040-based controllers (e.g. B0XX R4)
    • HayBox_DInput_Linux.ini - For Arduino/AVR-based controllers (e.g. B0XX R1-3, LBX)
  • For macOS (unsupported*):
    • HayBox_DInput_macOS.ini

To install the profile:

  1. Copy the appropriate .ini file from the dolphin folder within HayBox to the folder <YourDolphinInstallation>\User\Config\Profiles\GCPad\ (create it if it does not exist)
  • For Slippi this should be
    • On Windows: %appdata%\Slippi Launcher\netplay\User\Config\Profiles\GCPad\
    • On Linux: ~/.config/SlippiOnline/Config/Profiles/GCPad/
    • On Mac: Cmd + Shift + G and enter the path /Users/<USER>/Library/Application Support/Slippi Launcher/netplay/Slippi Dolphin.app/Contents/Resources/Sys/Config/Profiles/GCPad
  • For vanilla Dolphin:
    • On Windows: %userprofile%\Documents\Dolphin Emulator\Config\Profiles\GCPad\
    • On Linux: ~/.config/dolphin-emu/Profiles/GCPad/
  1. Plug in your controller, and configure a "Standard Controller" in Dolphin
  2. Click Refresh next to the Device dropdown
  3. Select the HayBox profile from the profile dropdown, and click Load (NOT Save)
  4. Make sure the correct device is selected in the device dropdown
  5. Click Close

* macOS only supports DInput (and not very well), so if using a Pico/RP2040-based controller you will have to force DInput mode by holding Z on plugin, and even then it may not work. I can't really do anything about Apple's poor controller support (which they seem to break with every other update) and I don't own any Apple devices, so this will also be considered unsupported usage of HayBox.

Customisation

Console/gamemode selection bindings

Communication backends (console selection)

The communication backend (e.g. DInput, GameCube, or N64) is selected partly through auto detection and partly based on the buttons held on plugin. This is handled in config/<environment>/config.cpp, in the setup() function. The logic is fairly simple, and even if you don't have programming experience it shouldn't be too hard to see what's going on and change things if you wish.

The config folders corresponding to the Arduino environments are:

  • config/arduino_nativeusb/ for Arduino with native USB support (e.g. Leonardo, Micro)
  • config/arduino/ for Arduino without native USB support (e.g. Uno, Nano, Mega 2560)

For Arduino device configs you may notice that the number 125 is passed into GamecubeBackend(). This lets you change the polling rate e.g. if your DIY doesn't support native USB and you want to use it with an overclocked GameCube controller adapter. In that example, you could pass in 1000 to sync up to the 1000Hz polling rate, or 0 to disable this lag fix completely. Polling rate can be passed into the N64Backend constructor in the same way as this.

You may notice that 1000Hz polling rate works on console as well. Be aware that while this works, it will result in more input lag. The point of setting the polling rate here is so that the GameCube backend can delay until right before the next poll before reading the inputs, so that the inputs are fresh and not outdated.

For Pico/RP2040, it is not necessary to pass in a console polling rate, because the Pico has enough processing power to read/process inputs after receiving the console poll, so there is no need to predict when the poll will arrive and prepare things in advance.

Input modes

To configure the button holds for input modes (controller/keyboard modes), edit the select_mode() function in config/mode_selection.hpp. Each if statement is a button combination to select an input mode.

Most input modes support passing in an SOCD cleaning mode, e.g. socd::2IP_NO_REAC. See here for the other available modes.

Creating custom input modes

For creating new input modes, it helps if you know some C++, or at least have some programming experience. That said, you should be able to get by even without prior experience if you just base your new mode off the existing ones and refer to them as examples.

There are two types of input modes: ControllerMode and KeyboardMode

Keyboard modes

Keyboard modes are a little bit simpler so let's start there.

A KeyboardMode behaves as a standard keyboard and should work with any device that supports keyboards.

You are free to use whatever logic and programming tricks you like in the UpdateKeys() function to decide the outputs based on the input state. You could create input layers (like the D-Pad layer in Melee mode that is activated when holding Mod X and Mod Y), or other types of conditional inputs.

The list of available keycodes can be found here.

Remember that keyboard modes can only be activated when using the DInput communication backend (not XInput).

Controller modes

A ControllerMode takes a digital button input state and transforms it into an output state corresponding to a standard gamepad. Any ControllerMode will work with any CommunicationBackend. A CommunicationBackend simply reads inputs from one or more input sources, uses the current ControllerMode to update the outputs based on those inputs, and handles the sending of the outputs to the console or PC.

To create a ControllerMode, you just need to implement the functions UpdateDigitalOutputs() and UpdateAnalogOutputs().

UpdateDigitalOutputs() is very similar to the UpdateKeys() function in keyboard modes, with the difference that rather than calling a Press() function to immediately send inputs, we are simply setting the output state for this iteration. As the name indicates, we will only deal with the digital outputs in this function.

UpdateAnalogOutputs() is a bit more complicated. Firstly, it has to call UpdateDirections() before doing anything else. This function takes in values indicating whether your left and right sticks are pointing left/right/up/down. You also pass in the minimum, neutral (centre), and maximum stick analog values, so you can configure these on a per-mode basis. All this information is used to automatically set the stick analog values based on the inputs you passed in. This is all you need to do unless you want to implement modifiers.

UpdateDirections() also populates the variable directions with values indicating current stick direction, which can be 1, 0, or -1 for the X and Y axes for both sticks. These values make it much easier to write modifier logic.

After calling UpdateDirections(), add any modifier handling logic that you want. Remember that UpdateDirections() already set the default analog stick values, so when handling modifiers you only need to manually set the values for the axes that are actually being modified. Other than this, I can't teach how to write your modifier logic, so just look at the examples and play around.

Finally, set any analog trigger values that you need.

Note: Analog trigger outputs could just as well be handled in UpdateDigitalOutputs(), but I think it usually looks cleaner to keep them along with the other analog outputs.

Also note: You don't need to worry about resetting the output state or clearing anything from it. This is done automatically at the start of each iteration.

SOCD

In the constructor of each mode (for controller modes and keyboard modes), you can configure pairs of opposing direction inputs to apply SOCD cleaning to.

For example, in src/modes/Melee20Button.cpp:

_socd_pair_count = 4;
_socd_pairs = new socd::SocdPair[_socd_pair_count]{
    socd::SocdPair{&InputState::left,    &InputState::right,   socd_type},
    socd::SocdPair{ &InputState::down,   &InputState::up,      socd_type},
    socd::SocdPair{ &InputState::c_left, &InputState::c_right, socd_type},
    socd::SocdPair{ &InputState::c_down, &InputState::c_up,    socd_type},
};

This sets up left/right, down/up, C-Left/C-Right, and C-Down/C-Up as pairs of opposing cardinal directions for which SOCD cleaning will be applied. The SOCD cleaning is automatically done before UpdateDigitalOutputs() and UpdateAnalogOutputs(), and you do not need to worry about it any further than that.

For each SocdPair you can pass in an SocdType of your choosing. By default for most modes this is passed in as a single constructor parameter, but it is possible to pass in multiple parameters, or simply use a hardcoded value. Both of these approaches are exemplified in src/modes/FgcMode.cpp.

SocdType Description
SOCD_NEUTRAL Left + right = neutral - the default if no SocdType specified in the SocdPair
SOCD_2IP Second input priority - left -> left + right = right, and vice versa. Releasing the second direction gives the original direction
SOCD_2IP_NO_REAC Second input priority without reactivation - same as above, except releasing the second direction results in neutral. The original direction must be physically reactuated.
SOCD_DIR1_PRIORITY The first button in the SocdPair always takes priority over the second
SOCD_DIR2_PRIORITY The second button in the SocdPair always takes priority over the first
SOCD_NONE No SOCD resolution - the game decides

Note that you do not have to implement a HandleSocd() function like in the Melee20Button and Melee18Button modes. It is only overridden in these modes so that we can check if left and right are both held before SOCD cleaning, because when they are both held (without a vertical direction being held) we need to override all modifiers.

Mod X lightshield and R shield tilt

If your controller has no lightshield buttons, you may want to use Mod X for lightshield and put shield tilt on R instead. You can do this by using the Melee18Button mode instead of Melee20Button.

Mode-specific optional features

Melee modes

The Melee20Button and Melee18Button modes provide a choice of which coordinates to use when pressing down + right. By default, holding down + back will allow you to do automatic jab-cancels, which is a useful technique for some characters.

Another popular technique that uses the down + right diagonal is the so-called crouch/walk option-select. This technique involves holding down + forward at a certain angle while crouching, such that after crouch-cancelling an attack you will automatically start walking towards your opponent instead of going back into crouch. This can be very useful for tech-chasing, but the coordinates used for this technique do not allow you to auto jab-cancel.

This can be configured as seen in config/mode_selection.hpp by setting the crouch_walk_os option to true:

new Melee20Button(socd::SOCD_2IP_NO_REAC, { .crouch_walk_os = false })

You will also have to change this in your config/<environment>/config.cpp in order for it to be applied on plugin, as mode_selection.hpp only controls what happens when you switch mode.

Project M/Project+ mode

The ProjectM mode has some extra options to configure certain behaviours. As seen in config/mode_selection.hpp:

new ProjectM(
    socd::SOCD_2IP_NO_REAC,
    { .true_z_press = false, .ledgedash_max_jump_traj = true }
)

Firstly, the ledgedash_max_jump_traj option allows you to enable or disable the behaviour borrowed from Melee mode where holding left and right (and no vertical directions) will give a 1.0 cardinal regardless of modifiers being held.

If you change the SOCD mode to 2IP (with reactivation), you should also change this option to false if you want a smooth gameplay experience.

Secondly, the true_z_press option exists because Project M/Project+ do not handle Z presses the same way Melee does. Melee interprets a Z press as lightshield + A, and thus it can be used for L cancelling without locking you out of techs. In PM/P+, a Z press will trigger a tech and thus cause unwanted tech lockouts if used to L cancel. By default in HayBox, the ProjectM mode is set to use a macro of lightshield + A in order to preserve expected behaviour from Melee. However, this macro does not enable you to use tether/grapple attacks or grab items. To workaround this, you can press Mod X + Z to send a true Z input.

If this bothers you, and you just want to send a true Z input by default when pressing Z, you can set the true_z_press option to true.

Input sources

HayBox supports several input sources that can be read from to update the input state:

  • GpioButtonInput - The most commonly used, for reading switches/buttons connected directly to GPIO pins. The input mappings are defined by an array of GpioButtonMapping as can be seen in almost all existing configs.
  • SwitchMatrixInput - Similar to the above, but scans a keyboard style switch matrix instead of individual switches. A config for Crane's Model C<=53 is included at config/c53/config.cpp which serves as an example of how to define and use a switch matrix input source.
  • NunchukInput - Reads inputs from a Wii Nunchuk using i2c. This can be used for mixed input controllers (e.g. left hand uses a Nunchuk for movement, and right hand uses buttons for other controls)
  • GamecubeControllerInput - Similar to the above, but reads from a GameCube controller. Can be instantiated similarly to GamecubeBackend. Currently only implemented for Pico, and you must either run it on a different pio instance (pio0 or pio1) than any instances of GamecubeBackend, or make sure that both use the same PIO instruction memory offset.

Each input source has a "scan speed" value which indicates roughly how long it takes for it to read inputs. Fast input sources are always read at the last possible moment (at least on Pico), resulting in very low latency. Conversely, slow input sources are typically read quite long before they are needed, as they are too slow to be read in response to poll. Because of this, it is more ideal to be constantly reading those inputs on a separate core. This is not possible on AVR MCUs as they are all single core, but it is possible (and easy) on the Pico/RP2040. The bottom of the default Pico config config/pico/config.cpp illustrates this by using core1 to read Nunchuk inputs while core0 handles everything else. See the next section for more information about using core1.

In each config's setup() function, we build up an array of input sources, and then pass it into a communication backend. The communication backend decides when to read which input sources, because inputs need to be read at different points in time for different backends. We also build an array of communication backends, allowing more than one backend to be used at once. For example, in most configs, the B0XX input viewer backend is used as a secondary backend whenever the DInput backend is used. In each iteration, the main loop tells each of the backends to send their respective reports. In future, there could be more backends for things like writing information to an OLED display.

Using the Pico's second core

In each config, there are the functions setup() and loop(), where setup() runs first, and then loop() runs repeatedly until the device is powered off.

On Pico/RP2040, the setup() and loop() functions execute on core0, and you can add the functions setup1() and loop1() in order to run tasks on core1.

For example, to read GameCube controller inputs on core1:

GamecubeControllerInput *gcc = nullptr;

void setup1() {
    while (backends == nullptr) {
        tight_loop_contents();
    }

    gcc = new GamecubeControllerInput(gcc_pin, 2500, pio1);
}

void loop1() {
    if (backends != nullptr) {
        gcc->UpdateInputs(backends[0]->GetInputs());
    }
}

The while loop makes sure we wait until setup() on core0 has finished setting up the communication backends. We then create a GameCube controller input source with a polling rate of 2500Hz. We also run it on pio1 as an easy way to avoid interfering with any GameCube/N64 backends, which use pio0 unless otherwise specified. In loop1() we make the assumption that the primary backend is the first element of the backends array (which is configured in the same file anyway, so we aren't truly assuming anything we don't know) and directly scan the GameCube controller inputs into the backend's input state.

As a slightly crazier hypothetical example, one could even power all the controls for a two person arcade cabinet using a single Pico by creating two switch matrix input sources using say 10 pins each, and two GameCube backends, both on separate cores. The possibilities are endless.

Troubleshooting

Controller not working with console or GameCube adapter

If you are using an official adapter with an Arduino-based controller you will likely have to hold A on plugin which disables the polling latency optimisation by passing in a polling rate of 0 to the GamecubeBackend constructor.

If you are using an Arduino-based controller without a boost circuit, you will need 5V power so for Mayflash adapter you need both USB cables plugged in, and on console the rumble line needs to be intact. Pico works natively with 3.3V power so this isn't an issue.

Contributing

I welcome contributions and if you make an input mode that you want to share, feel free to make a pull request. Please install the clang-format plugin for VS Code and use it to format any code you want added.

Versioning

We use SemVer for versioning. For the versions available, see the tags on this repository.

Built With

Contributors

  • Jonathan Haylett - Creator - @JonnyHaystack
  • Crane - Creator of the DIYB0XX firmware, which served as a great reference/starting point - @Crane1195

See also the list of contributors who participated in this project.

Acknowledgments

  • The B0XX team, for designing and creating an incredible controller
  • @Crane1195 - for his DIYB0XX and GCCPCB projects, and for hours of answering my questions when I was first writing this
  • @MHeironimus - for the Arduino Joystick library
  • @NicoHood - for the Nintendo library
  • @GabrielBianconi - for the Arduino Nunchuk library
  • @earlephilhower - for the arduino-pico core
  • @maxgerhardt - for adding PlatformIO support for arduino-pico
  • The Arduino project and the Raspberry Pi Foundation - for all their open-source hardware and software

License

This project is licensed under the GNU GPL Version 3 - see the LICENSE file for details

haybox's People

Contributors

alto-27 avatar colonket avatar jonnyhaystack avatar manniefesto avatar neverdoubttheworm avatar ribbanya avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

haybox's Issues

Spams buttons when swapping to a Keyboard mode on a Pico

When inputting the button combination for a Keyboard mode on a Pico, the device will rapidly spam those same 3 keys for maybe a second. For example, when inputing the Default Keyboard mode, it will spit out A, F, and H repeatedly in a long sequence. The sequence is variable, and appears to be related to how long all 3 buttons where held down after the button combination was inputed.

Is it possible to send a button hold on boot on GameCube?

I have a GameCube running Picoboot and I've configured it so that if you hold B on a controller when turning it on, it will go straight to Game Boy Interface instead of Swiss. I can't seem to get this to work with my Open-Frame1 running HayBox. Also, even when Swiss loads, I find that I can't move through the menu until I unplug the cable and plug it back in. Does the GameCube have to already be on and do you then have to plug in the controller for it to work normally?
In my case the controller is already plugged in on both ends, I hold the B button, then I press the GameCube's power button.
Am I perhaps just running into a conflict? I see in the readme that holding B on plugin goes into Brook board mode. So if the controller isn't receiving power until the console turns on, maybe that's when it counts as a plug-in, and then because I'm holding B it goes into that mode.
It seems like I also can't move through the menus if I boot while not holding anything until I replug the cable. Do I have a wonky cable/port or is this expected behavior? Once it's working, it keeps working fine, but I think I have been running into these sorts of initialization issues now and then.

Default FGC mode has likely-unintended mixed L/R and LT/RT layout

So the standard 8-button layout found in something like Street Fighter is:

X  Y  *R*   _L_
A  B  *RT*  _LT_

However, some folks (myself included) prefer having the *R*s and _L_s swapped like so:

X  Y  _L_   *R*
A  B  _LT_  *RT*

Though I personally prefer the latter, I understand that the former is industry standard.

Here's the issue: neither of these layouts are implemented in the current release. Instead, we have:

X  Y  _L_   *R*
A  B  *RT*  _LT_

...which I presume is unintended.

Please add location for slippi controller .ini files for mac to the ReadMe

Please add instructions for the .ini files for Mac into the ReadMe

The location is

/Users/USER/Library/Application Support/Slippi Launcher/netplay/Slippi Dolphin.app/Contents/Resources/Sys/Config/Profiles/GCPad

To get into to it, you have to first go to /Users/USER/Library/Application\ Support/Slippi\ Launcher/netplay/Slippi\ Dolphin.app/, right click on Dolphin.app, and click "open contents", then you have to navigate to Contents/Resources/Sys/Config/Profiles/GCPad and put the .ini files there.

two mod_x buttons?

Want two mod_x buttons but only one of them works :( Maybe there's a way and I'm just dumb.

image

Sonic Superstars (Switch) - can't select Chaos Emerald ability

They want you to use the right stick flicked in one of 8 directions in a radial menu to select an ability. For some reason with my Open-Frame1 running HayBox it won't select the ability using the c-stick buttons. I can change where the arrow points, but the menu stays stuck open, similar to if you keep the stick held on a regular controller. I figured maybe it was a stick angle issue, but I don't notice any different behavior when using the Mod X/Y buttons. I was using Ultimate mode, but I don't notice a major difference with the other platform fighter modes. Maybe it expects the stick to return to center slightly more gradually instead of jumping back to no stick input. Using a more traditional controller (8bitdo Ultimate controller) the menu closes after I flick the stick in a direction and it then selects that ability.
Could c-stick behavior be altered so that it emulates the stick returning to center with stick values the whole way as if you'd quickly flicked it? I imagine if it worked that way, it would still be able to work the same in Smash as well.
This game is almost completely playable even in FGC mode except for this weird right stick requirement, it's a real shame I can't find a way to make it work. From what I've seen the PC version lets you bind buttons to changing the abilities left/right around the menus, but I couldn't find a way to configure the controls on the Switch version, so I think you're forced to just use the defaults, including right stick for that ability menu.

Inability to compile with fewer buttons

I'm attempting to use this firmware on my Smashbox, which lacks a select and home button. If I set these to NULL in the pinout file, it throws errors. If I delete the lines they throw errors.

HID issues on Linux, macOS

On Linux, some of the coordinates (mostly higher magnitude ones it seems) are off by 1. E.g. cardinals are 0.9875 (79) instead of 1.0 (80)

On macOS, there have been reports from users that it isn't showing up as a HID gamepad at all, but keyboard mode is working fine.

Probably going to have to compare against other HID report descriptors again (e.g. Arduino HID) to figure out a solution. Linux issue possibly fixable through Dolphin profile change though?

b0xx R2 with HayBox wakes Linux from suspend/sleep

I have a b0xx revision 2 that I recently flashed HayBox onto. Which has been great, thank you. I normally leave my b0xx plugged in with usb-c to my pc running Debian Linux. Something I've noticed after flashing HayBox is that with the b0xx plugged in, if I put the pc into suspend/sleep, the pc will wake up again after a couple seconds. I did not observe this behavior when I had stock b0xx firmware. My current solution is to unplug the b0xx before entering suspend.

One solution I tried to circumvent this was preventing the specific device from being able to wakeup the pc.

/etc/udev/rules.d/90-usb-wakeup.rules

# Disable waking up from b0xx
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="8036", ATTR{power/wakeup}="disabled"

# Disable waking up from Logitech mouse usb receiver
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"

I got the vendor & product ids from the output of lsusb:

Bus 001 Device 011: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 001 Device 013: ID 2341:8036 Arduino SA Leonardo (CDC ACM, HID)
...

The rule to disable wakeup appears to be working for my Logitech mouse, but not the b0xx unfortunately. The wakeup of the pc after a couple seconds of entering suspend persists.

Let me know if there's logs or any additional info I could provide.

twoIP Edge Case Clarification

I was looking through this firmware's SOCD resolution and making some modification and noticed that the twoIP function seems to output a neutral if both socd_state.was_dir1 and socd_state.was_dir2 are false and both of the SOCD inputs are true. Is this intended behavior?

[Discussion]: Possible improvements, code and stick value questions

I have been editing code for the Ultimate mode to change/fix a few things:

Queuing dash into ftilt using modY + cstick results in a dash attack

This means the leftStickX value is too high. By reducing the multiplier by 1, it started working properly.

But, this piqued my interest in the values, the differences between HayBox and the stock B0XX firmware, and how these values work. It seems that directly assigning a value to outputs.leftStickX does not work as I would expect; the value ends up being different at runtime (NOTE: I am testing these values using SDL). I'm curious why this is, and if there's a way to set a value I'd expect directly (e.g. 9680)

The default values for the B0XX firmware for left/right while holding modY are -9681 and 9680 respectively, while HayBox's values are -13435 and 13434.

From B0XX's Smash Ultimate manual, "Modifier Y contains the slowest walk in the game." I'm not sure if this is actually true, as with some testing I've been able to walk with lower values, although I'm not sure if the walking speed was actually slower. This does beg the question though; with HayBox's mod Y, are we walking as slow as the game will allow? Or, is this even a goal of using mod Y with HayBox?

Also, leftStickX values without any modifiers are much higher, akin to an actual gcc.


I'm more than happy to test out differences between the firmware, an official gcc that I own, etc. if you'd like more data.

Windows not recognizing LBX / Startup Help

Hi, I am buying a friends LBX and they had someone else configure it for them. This LBX currently has crane's flashed onto it and I am trying to use it on my Windows 11 PC. I figured a good first step would be to upgrade to HayBox. I don't have much experience with VSC. I used GIT to clone the repository and followed the steps on the main page. After searching and trying different things I still had no change and would get the following error.
fail
I went to device manager and changed the COM port being used to make sure it wasn't being used elsewhere. I am stumped. The LBX shows up as Arduino Leonardo in devices, but will not show up as a gamepad. Any help would be much appreciated.

'home' button mapping on pico (GPIO11) is the same pin as the rumble pin on Arte's rectangle FW. [Pico]

Hello, Rumble Enjoyer Mr. Potatobread here.

One of my rumble-box users was experiencing some issues after switching to this FW from Arte's: Dpad-right seemed to always be held down on both PC and console.
After some investigation, I found that the "home" button results in a Dpad-right output, and the pin 'home' is mapped to (GPIO11) is the same as the rumble signal pin on Arte's FW.

This is obviously not a life-or-death issue, and my friend here is likely the only person to ever experience this very specific issue - but I figured I would post it here in case people in the future had this problem or if there were plans to add rumble to this FW.

For now I just changed 'home' to GPIO9 to solve the issue.

Cheers!

Default "DefaultKeyboardMode" not working with LBX

Hello,
I am using a LBX plugged to a Windows 10 PC via USB (so Dinput should be default). I can switch between input modes just fine, and I managed to remap buttons successfully (thank you!)
However the Keyboard mode that comes with the latest build doesn't seem to fulfil its purpose - no keys actuate.
The latest build seem to have assigned the keyboard key "A" to "L", "B" to "Left" etc... But maybe some extra modifications are needed to get it to work. I'm sorry I can't figure it out by myself (lack of programmation skills), the documentation does say that the <UpdateKeys()> is where things need to be changed, but it's unclear to me what needs to be done.
Thanks for your help

Stick angles makes DI not work correclty in MultiVersus

In the advanced tutorial for DI, it is not possible to finish it because the stick seems to not be able to go to the correct angle and/or depth. It asks you to hold down left until you're able to survive the hit, but it's not possible.

I don't know what a good fix for this would be, but it would be nice if there was a way to finish the tutorial with a box.

[Pico/Open-Frame1] D-pad does not work in any Mode on the Steam Deck

I'm playing on a Steam Deck (in a dock) if it matters. I can move around and stuff in Melee Mode but then the attack buttons aren't in the right places for this kind of game. When I switch to FGC mode the attack buttons are all in the right spots (according to the inputs shown in training mode) but I can't move anymore.
Also, are the default layouts for the modes displayed anywhere? I'm not even entirely sure what each button is bound to. What is normally C-Down opens up the menu as if I'd hit the Steam button. (Maybe like a Home or something?)
If I'm in FGC mode when I start Skullgirls I can't even seem to get past the menu where you select which controller is used by which player. When I started up in another mode I was able to get past this. It seems to want me to use left/right here.
Do I need to rebind keys for this to work or have I hit a bug? I don't usually play traditional fighters so I haven't tested this mode with other games. I mostly play Smash and Rivals.
edit: in the controls screen when trying to rebind movements it doesn't detect any press from the left side's four buttons at all.
edit2: Using Open-Frame1 PCB, so I have 20 buttons.

Not working for b0xx

EDIT: Solution is to hold the A button while plugging in via a Gamecube Controller Adapter

I have a b0xx that I use for smash ultimate, and was told to give HayBox a try in order to fix the SOCD lockout issue.

  • I have tried both b0xx_r1 and b0xx_r2 profiles with an official gamecube adapter (connected to a nintendo switch)
  • I have tried holding x or a while plugging in
  • I have tried pressing Mod X + Down + Start while plugged in

None of the buttons seem to do anything, I can't leave the switch's home menu.

Any thoughts on debugging, or some step I may have missed?


NOTE: I tried this both on Linux and Windows 10 with the same results, using the most recent commit 9fb52af

Logs

Build

 *  Executing task: platformio run --environment b0xx_r2 

Processing b0xx_r2 (board: leonardo; platform: atmelavr; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/leonardo.html
PLATFORM: Atmel AVR (4.0.0) > Arduino Leonardo
HARDWARE: ATMEGA32U4 16MHz, 2.50KB RAM, 28KB Flash
DEBUG: Current (simavr) On-board (simavr)
PACKAGES: 
 - framework-arduino-avr @ 5.1.0 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain+, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Nintendo @ 1.4.0
|-- Wire @ 1.0
|-- arduino-nunchuk @ 0.0.0+20220924193459
|   |-- Wire @ 1.0
|-- Joystick @ 2.1.1
|-- Keyboard @ 1.0.4
|   |-- HID @ 1.0
|-- HID @ 1.0
Building in release mode
Compiling .pio/build/b0xx_r2/src/config/b0xx_r2/config.cpp.o
Linking .pio/build/b0xx_r2/firmware.elf
Checking size .pio/build/b0xx_r2/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  32.1% (used 823 bytes from 2560 bytes)
Flash: [========  ]  84.4% (used 24204 bytes from 28672 bytes)
Building .pio/build/b0xx_r2/firmware.hex
============================================================================== [SUCCESS] Took 1.07 seconds ==============================================================================

Environment    Status    Duration
-------------  --------  ------------
b0xx_r2        SUCCESS   00:00:01.069
============================================================================== 1 succeeded in 00:00:01.069 ==============================================================================
 *  Terminal will be reused by tasks, press any key to close it. 

Upload

 *  Executing task: platformio run --target upload --environment b0xx_r2 

Processing b0xx_r2 (board: leonardo; platform: atmelavr; framework: arduino)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/leonardo.html
PLATFORM: Atmel AVR (4.0.0) > Arduino Leonardo
HARDWARE: ATMEGA32U4 16MHz, 2.50KB RAM, 28KB Flash
DEBUG: Current (simavr) On-board (simavr)
PACKAGES: 
 - framework-arduino-avr @ 5.1.0 
 - tool-avrdude @ 1.60300.200527 (6.3.0) 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain+, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Nintendo @ 1.4.0
|-- Wire @ 1.0
|-- arduino-nunchuk @ 0.0.0+20220924193459
|   |-- Wire @ 1.0
|-- Joystick @ 2.1.1
|-- Keyboard @ 1.0.4
|   |-- HID @ 1.0
|-- HID @ 1.0
Building in release mode
Checking size .pio/build/b0xx_r2/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  32.1% (used 823 bytes from 2560 bytes)
Flash: [========  ]  84.4% (used 24204 bytes from 28672 bytes)
Configuring upload protocol...
AVAILABLE: avr109
CURRENT: upload_protocol = avr109
Looking for upload port...
Auto-detected: /dev/ttyACM0
Forcing reset using 1200bps open/close on port /dev/ttyACM0
Waiting for the new upload port...
Uploading .pio/build/b0xx_r2/firmware.hex

Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: reading input file ".pio/build/b0xx_r2/firmware.hex"
avrdude: writing flash (24204 bytes):

Writing | ################################################## | 100% 1.83s

avrdude: 24204 bytes of flash written
avrdude: verifying flash memory against .pio/build/b0xx_r2/firmware.hex:
avrdude: load data flash data from input file .pio/build/b0xx_r2/firmware.hex:
avrdude: input file .pio/build/b0xx_r2/firmware.hex contains 24204 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.18s

avrdude: verifying ...
avrdude: 24204 bytes of flash verified

avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)

avrdude done.  Thank you.

============================================================================== [SUCCESS] Took 4.93 seconds ==============================================================================

Environment    Status    Duration
-------------  --------  ------------
b0xx_r2        SUCCESS   00:00:04.926
============================================================================== 1 succeeded in 00:00:04.926 ==============================================================================
 *  Terminal will be reused by tasks, press any key to close it. 

Mode Memory (on unplug)

The GP2040-CE firmware remembers your last mode when you unplug the controller, which I find to be pretty handy. I personally use Melee Mode less than the other modes, so if I could have it remember Ultimate/Rivals mode, it would save me a lot of trouble. This would probably matter even more in a tournament setting where you may be re-plugging the controller a lot as you change who's playing at a setup and when. For people who primarily play Melee, it would just remember they last used the Melee Mode and should work basically the same for them, so I don't think there's much to lose here.

Getting compilation errors when targeting Smash Box

Errors

In file included from X:\HayB0XX\HayB0XX\DInputBackend.cpp:1:0:
X:\HayB0XX\HayB0XX\src\ArduinoJoystickLibrary\src\Joystick.h:32:2: error: #error The Joystick library can only be used with a USB MCU (e.g. Arduino Leonardo, Arduino Micro, etc.).
 #error The Joystick library can only be used with a USB MCU (e.g. Arduino Leonardo, Arduino Micro, etc.).
  ^~~~~
In file included from X:\HayB0XX\HayB0XX\DInputBackend.cpp:4:0:
DInputBackend.h:16:3: error: 'Joystick_' does not name a type
   Joystick_ *mpJoystick;
   ^~~~~~~~~
X:\HayB0XX\HayB0XX\DInputBackend.cpp: In constructor 'DInputBackend::DInputBackend()':
DInputBackend.cpp:8:3: error: 'mpJoystick' was not declared in this scope
   mpJoystick = new Joystick_(JOYSTICK_DEFAULT_REPORT_ID, JOYSTICK_TYPE_GAMEPAD,
   ^~~~~~~~~~
DInputBackend.cpp:8:20: error: expected type-specifier before 'Joystick_'
   mpJoystick = new Joystick_(JOYSTICK_DEFAULT_REPORT_ID, JOYSTICK_TYPE_GAMEPAD,
                    ^~~~~~~~~
X:\HayB0XX\HayB0XX\DInputBackend.cpp: In destructor 'virtual DInputBackend::~DInputBackend()':
DInputBackend.cpp:26:3: error: 'mpJoystick' was not declared in this scope
   mpJoystick->end();
   ^~~~~~~~~~
X:\HayB0XX\HayB0XX\KeyboardMode.cpp: In constructor 'KeyboardMode::KeyboardMode(socd::SocdType, state::InputState&)':
KeyboardMode.cpp:9:3: error: 'Keyboard' not found. Does your sketch include the line '#include <Keyboard.h>'?
   Keyboard.begin();
   ^~~~~~~~
X:\HayB0XX\HayB0XX\KeyboardMode.cpp:9:3: note: suggested alternative: 'KeyboardMode'
   Keyboard.begin();
   ^~~~~~~~
   KeyboardMode
X:\HayB0XX\HayB0XX\KeyboardMode.cpp: In destructor 'virtual KeyboardMode::~KeyboardMode()':
KeyboardMode.cpp:13:5: error: 'Keyboard' not found. Does your sketch include the line '#include <Keyboard.h>'?
     Keyboard.releaseAll();
     ^~~~~~~~
DInputBackend.cpp:27:10: error: type '<type error>' argument given to 'delete', expected pointer
   delete mpJoystick;
          ^~~~~~~~~~
X:\HayB0XX\HayB0XX\DInputBackend.cpp: In member function 'virtual void DInputBackend::SendOutputs(state::OutputState)':
DInputBackend.cpp:32:3: error: 'mpJoystick' was not declared in this scope
   mpJoystick->setButton(0, outputState.b);
   ^~~~~~~~~~
X:\HayB0XX\HayB0XX\KeyboardMode.cpp:13:5: note: suggested alternative: 'KeyboardMode'
     Keyboard.releaseAll();
     ^~~~~~~~
     KeyboardMode
X:\HayB0XX\HayB0XX\KeyboardMode.cpp: In member function 'void KeyboardMode::Press(char, bool)':
KeyboardMode.cpp:24:9: error: 'Keyboard' not found. Does your sketch include the line '#include <Keyboard.h>'?
         Keyboard.press(key);
         ^~~~~~~~
X:\HayB0XX\HayB0XX\KeyboardMode.cpp:24:9: note: suggested alternative: 'KeyboardMode'
         Keyboard.press(key);
         ^~~~~~~~
         KeyboardMode
KeyboardMode.cpp:26:9: error: 'Keyboard' not found. Does your sketch include the line '#include <Keyboard.h>'?
         Keyboard.release(key);
         ^~~~~~~~
X:\HayB0XX\HayB0XX\KeyboardMode.cpp:26:9: note: suggested alternative: 'KeyboardMode'
         Keyboard.release(key);
         ^~~~~~~~
         KeyboardMode
exit status 1
'Joystick_' does not name a type

Differences from master (7620248)

diff --git a/HayB0XX/HayB0XX.ino b/HayB0XX/HayB0XX.ino
index d5be178..2e03ae1 100644
--- a/HayB0XX/HayB0XX.ino
+++ b/HayB0XX/HayB0XX.ino
@@ -10,7 +10,7 @@
     Zac Staples' Arduino_Vector library
 */
 
-#include "setup_gccpcb2.h"
+#include "setup_smashbox.h"
 
 #include "DefaultKeyboardMode.h"
 #include "FgcMode.h"
@@ -75,8 +75,8 @@ void readInputs() {
   gInputState.mod_x = (digitalRead(pinout::MODX) == LOW);
   gInputState.mod_y = (digitalRead(pinout::MODY) == LOW);
   gInputState.start = (digitalRead(pinout::START) == LOW);
-  gInputState.select = (digitalRead(pinout::SELECT) == LOW);
-  gInputState.home = (digitalRead(pinout::HOME) == LOW);
+  // gInputState.select = (digitalRead(pinout::SELECT) == LOW);
+  // gInputState.home = (digitalRead(pinout::HOME) == LOW);
   gInputState.b = (digitalRead(pinout::B) == LOW);
   gInputState.x = (digitalRead(pinout::X) == LOW);
   gInputState.z = (digitalRead(pinout::Z) == LOW);
@@ -114,8 +114,8 @@ void setup() {
   pinMode(pinout::MODX, INPUT_PULLUP);
   pinMode(pinout::MODY, INPUT_PULLUP);
   pinMode(pinout::START, INPUT_PULLUP);
-  pinMode(pinout::SELECT, INPUT_PULLUP);
-  pinMode(pinout::HOME, INPUT_PULLUP);
+  // pinMode(pinout::SELECT, INPUT_PULLUP);
+  // pinMode(pinout::HOME, INPUT_PULLUP);
   pinMode(pinout::B, INPUT_PULLUP);
   pinMode(pinout::X, INPUT_PULLUP);
   pinMode(pinout::Z, INPUT_PULLUP);

Arduino settings

image

Other notes

I'm on Windows 10 and using the git clone --recursive method.

Configurator Branch - Inputs for mode change / default mode

I've been trying to make my own modes using the configurator branch, but I can't seem to find where to change the default modes when plugging into switch / pc (it used to be in config.cpp in setup () )... and I also can't find where to change the button inputs to change modes on the fly... There is no "mode_selection.hpp" in config... and the one in core (both src and include) doesn't seem to have this.. Any help would be appreciated!!

Create a macro to enable training mode restart

Currently I don't think it is possible to restart training mode, since the hardcoded shortcut for that is L+R+A. At least when using Ultimate mode via usb.
Since there is no actual L button on most controllers. So currently I have created this macro for myself (AtomToast/HayBox@f3000f2), where I can press mx+my+z to also trigger buttonL and a.

Do you think something like this would make sense in the main firmware too?
Are there any legality concerns?
Alternative implementation/buttons?

[Pico] Taunt / D-pad

I'm playing Rivals of Aether and the tutorials requires you to hit a taunt button to repeat the instructions. Is that possible with HayBox? I mashed around a bit wondering if one of the modifier buttons would turn something into a d-pad, but I didn't figure anything out.

XInput not working with pico (but all other backends do)

I am able to get the controller to register on my pc by holding Z as a DInput Controller. It also works on my switch by holding X plugged into the dock, and as a GCC controller by plugging into the adapter.

However, if I simply plug the usb into my computer without holding anything (which should use XInput backend), nothing happens. The USB device is unidentified ("Unknown USB Device (Invalid Configuration Descriptor)"). I have tried reinstalling my drivers, and I have also tried it on different PC's, all giving the exact same error... I am kind of at a loss of what to do next.. Any help would be greatly appreciated!

Smash 64 Layout

There doesn't seem to be a good control layout for Smash 64. X to jump does nothing. If you jump with the C buttons it's harder to hit A to attack since it's all with the thumb. If you use tap jump it makes it difficult to jump and use your neutral special without doing your up special.

Open-Frame 1 support, building questions

For use on an Open-Frame1 (Pi Pico + Open-Frame1 PCB), would I just build the Pico version? How does it know how many buttons I have and such?
I'm also curious if it's possible to build this without VSCode/VSCodium, both because I'd rather not install an extra editor I don't want to use, and because Guix dosen't have VSCodium packaged, so it would be difficult to get it on my main PC. If necessary I'll either have a trusted friend build the firmware for me or have to use a different computer for setup I suppose.
Is there a reason that prebuilt firmware is not provided at all, by the way? I see in the screenshots in the readme that you can build for a few different controllers, but then I wonder why you couldn't put the firmware for them all in the releases. Maybe you expect people to tweak some things before building, but if any of the builds would be usable by default, I think it'd be worth providing binaries.

BTW, thank you very much for releasing this project as free (as in freedom) software.

SwitchBackend analog offset

Seems all stick inputs are shifted about 1 left, 1 up. This also affects the stick in neutral.

For example:

  • MY Walk leftwards minimum = 25.
  • MY Walk rightwards minimum = 26.

Not the biggest issue since I can round up, but the issue exists.

Example 2:

  • C-UpRight = Up Smash/Tilt.
  • C-UpLeft = Upward angled Forward Smash/Tilt.

This can easily be worked around with modifiers, but the issue exists.

...

Also, because the stick cannot fully progress from Neutral to Up, scrolling up is not possible in certain Switch System Settings.

Release schedule

I'm curious if there's a rough plan for when the next release will be, and how often you intend to make future releases. I understand there are some big changes in the works like correcting values in Ultimate Mode that you may want to wait on before releasing. Changes like the controller identifier that was used changing to fix the dpad issue on Linux would be great to have in a release. I unfortunately don't find building with PlatformIO to be very accessible, so I feel kind of stuck on the last stable release for now. (I should probably try to figure out building HayBox someday, as I think that's the only way to add a new mode, and it would be cool to make a new mode for rhythm games like Taiko no Tatsujin.)

PS3 DInput bindings, FGC + other modes

Are there any plans to add PlayStation support? Would that be possible? I'm not sure if I can have one controller that does it all or if I need at least 2 with different firmware on each.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.