Direct N64 controller access plugins for mupen64plus and Project64

What is it for?

Everything shown works!



So, what does this do for you? Many things! Here are the key advantages:

No calibration required . As the game talks to the controller directly, it reads exactly the same axis values it would in a non-emulated setup. In other words, the controller works, responds and feels exactly as it would in real life.

. As the game talks to the controller directly, it reads exactly the same axis values it would in a non-emulated setup. In other words, the controller works, responds and feels exactly as it would in real life. Low latency . When the game must read the controller, the request is forwarded directly to the controller by the adapter. The later immediately returns the controller's answer to the game.

. When the game must read the controller, the request is forwarded directly to the controller by the adapter. The later immediately returns the controller's answer to the game. Potential support for any expansion accessory without any intervention nor device-specific functionality required on the part of the emulator, of the plugin or of the adapter (except for the direct access feature), which means: Rumble pack support (tested) Memory pack support (tested) Transfer pack support (confirmed) Bio sensor support (tested) And just like with a real N64 system, you simply need to insert the accessory you wish to use and the game will take care of everything else. No emulator configuration required to switch accessory...

without any intervention nor device-specific functionality required on the part of the emulator, of the plugin or of the adapter (except for the direct access feature), which means: And just like with a real N64 system, you wish to use and the game will take care of everything else. required to switch accessory... Support for peripherals other than controllers. N64 mouse (tested) VRU (confirmed, requires special ports1_4 version of the plugin) N64 Keyboard (not confirmed [1] )

[1] I cannot test accessories I do not own yet. But the nice thing about this plugin is that it probably already works. Please contact me if you get the chance to test.



Warning: This project is experimental and still in development . While it is already usable, some of the features above, especially the ones that are unconfirmed, may be found not to work at all. There can (and will) be bugs, and there are still many missing features such as multi adapter support. Your help and patience in testing as well as your constructive feedback are welcomed.

These mupen64plus and Project 64 plugins use the direct controller access feature offered by my N64 to USB adapters (versions 3 and up) to let the emulated game communicate with the controllers directly.So, what does this do for you? Many things! Here are the key advantages:I cannot test accessories I do not own yet. But the nice thing about this plugin is that it probably already works. Please contact me if you get the chance to test.

Screenshots

START before running the emulator) is usable despite a few visual glitches. Then once in the game, we can see ghost data exists (saved in a previous session. The emulator had been restarted since). Later (and on a different machine, in this screenshot on a Linux system) the data written by MK64 can be accessed with

MK64 built-in manager Ghost Ghost Adapter manager



Note: For now at least, it is better not to run the adapter manager and a game (with this plugin) at the same time. Contributions:

Controller, Transfer and Tremor paks Transfer Pak and a Tremor Pak Plus (Third party Rumble Pak equivalent) and reports it works fine. The games he tested with the Transfer Pak are Pokemon Statium and Pokemon Statium 2, using Project 64 version 2.3.0.216 under Windows 10. He mentions however that the emulator crashes with a blank screen when he goes to the Gameboy Tower...



Here are a few screenshots of the Pokemon games:



Pokemon Stadium Pokemon Stadium Pokemon Stadium Pokemon Stadium Pokemon Stadium 2 Pokemon Stadium 2 Pokemon Stadium 2

MaMaLuigi9001 also confirmed the VRU works, but the ports1_4 version of the plugin where adapter port 2 acts as N64 port 4 is required. This version will be included in release 1.0.0.

VRU



Here are a few screenshots taken with a memory card present in the N64 controller. The Mario Kart 64 built-in mempak manager (hold thebefore running the emulator) is usable despite a few visual glitches. Then once in the game, we can see ghost data exists (saved in a previous session. The emulator had been restarted since). Later (and on a different machine, in this screenshot on a Linux system) the data written by MK64 can be accessed with the adapter management tool For now at least, it is betterto run the adapter manager and a game (with this plugin) at the same time. MaMaLuigi9001 tested theand a(Third partyequivalent) and reports it works fine. The games he tested with the Transfer Pak are Pokemon Statium and Pokemon Statium 2, using Project 64 version 2.3.0.216 under Windows 10. He mentions however that the emulator crashes with a blank screen when he goes to the Gameboy Tower...Here are a few screenshots of the Pokemon games:MaMaLuigi9001 also confirmed the VRU works, but the ports1_4 version of the plugin where adapter port 2 acts as N64 port 4 is required. This version will be included in release 1.0.0.

Supported adapters

How it works











The normal event chain is more or less the following: (written with mupen64plus in mind, but also applies to project64) The adapter polls the controller and stores the answer containing button and axis status data in RAM. The host PC polls the adapter over USB and receives the most recently read data. This newly received data makes its way through a few software layers including the HID driver, the DirectX (DirectInput) or joystick driver and the SDL library. (The data is in fact stored in a buffer somewhere) When the game being emulated requests a controller status update, an answer is built using the most recent data returned by the SDL library. Pros Cons The emulator does not need to wait. Relatively fresh data is always available immediately (the SDL library returns it without delay) so the emulator only needs to reformat the data to make it look like what a real controller would answer.

This approach works with almost all controllers and adapters usable through SDL. The exact axis value are often lost (calibration, dead-zone, assumptions on the exact axis range from the part of the emulator that are not met by the adapter-driver stack, etc) and restoring the original feel can require a lot of subjective tweaking.

The emulator needs to know what kind of pack to emulate (i.e. mempak or rumble a pack?). This means the user must configure this depending on the game. While rumble packs can work mostly as intended (through HID PID) mempack emulation is almost always virtual (i.e. file-backed).

The "direct access" event chain is more or less the following: The emulated game requests a controller status update. The plugin forwards the request as-is to the adapter through USB. The adapter in turn forwards it to the actual controller (or other peripheral). The controller (or peripheral) answers the request. The adapter receives the answer and retransmits it through USB. The input plugin receives it and serves it unmodified to the game. Pros Cons The game actually communicates with the controller. Accessoires such as memory packs and rumble packs (and potentially others) are therefore supported natively.

The answer from the controller does not undergo any transformation. The axis values received by the game are exactly what they would be on a non-emulated setup. No unknowns and no tweaking! Since the request has to do a round-trip to the controller, the action of reading the controller status takes a bit more time. When there are a lot of exchanges (especially when writing and reading mempacks) this can cause a temporary slow down of the emulator.

the controller status takes a bit more time. When there are a lot of exchanges (especially when writing and reading mempacks) this can cause a temporary slow down of the emulator. Only possible on adapters offering a way to communicate with the controllers directly. (For me of course that's a pro)

Here is a diagram outlining the main differences between the usual architecture (input-sdl) and this plugin.is more or less the following: (written with mupen64plus in mind, but also applies to project64)is more or less the following:

Special builds





Name Filename Purpose and description Standard pj64raphnetraw.dll The standard version. Supports up to 4 players through any combination of 1 and 2 player adapters. Single player pj64raphnetraw_1player.dll Special version supporting only one controller, regardless of how many ports your adapter has. Meant for use with dual-controller adapters where there can be, depending on the game, a small performance penalty caused by polling the second (unused or absent) controller.



If you mostly play alone, you should use this version. When playing with friends, you should use the above (Standard) version. Ports 1 and 3 pj64raphnetraw_ports1and3.dll Special build where the first two adapter ports are mapped to ports 1 and 3 on the emulated N64 console. Intended to be used with Densha de GO! where the game expects a special controller in port 3. Ports 1 and 4 pj64raphnetraw_ports1and4.dll Special build where the first two adapter ports are mapped to ports 1 and 4 on the emulated N64 console. Intended to use with the VRU which must be connected to port 4. Net pj64raphnetraw_net.dll There are some (currently) unexplained compatiblity issues for netplay with Project64k. It does not work unless a very old adapter firmware (v3.3.2) is used. A feature was introduced in firmware version 3.4.0 to boost performance, and raphnetraw v0.9.4 make use of it, but when this feature is used, it breaks netplay...



As a temporary solution, this version disables the use of the offending feature and hopefully fixes netplay.

The .zip files for Project 64 (see the download section) contains several raphnetraw DLLs. Here's a summary of what those are and what they are for:

Download

Usage (Project64 under Windows)





1: Copy the following file to "your PJ64 installation directory"/Plugin/Input: pj64raphnetraw.dll (for older PJ64 versions (such as v1.4), place the file directly in the Plugin directory as there are no subdirectories per plugin type).



2: You must also copy the following file to your PJ64 installation base directory (i.e. The directory where the .EXE is): libhidapi-0.dll Then in the settings dialog, select "raphnetraw for Project64 version xx.xx" in the Input plugin list.



Installing the plugin (pj64raphnetraw.dll) Installing the support file (libhidapi-0.dll) Input plugin selection (PJ64 v2.3)

Note: The current version of the plugin will create a log file named raphnetraw.log in your home directory.

To install and use the PJ64 plugin, there are two files to place at specific locations.Copy the following file to "your PJ64 installation directory"/Plugin/Input:You must also copy the following file to your PJ64 installation base directory (i.e. The directory where the .EXE is):Then in the settings dialog, select "raphnetraw for Project64 version xx.xx" in the Input plugin list.The current version of the plugin will create a log file namedin your home directory.

Usage (1964 under Windows)





Installation for use with 1964 is as follows: Copy the raphnetraw_net.dll file to the plugin/ directory in the 1964 folder. Copy the libhidapi-0.dll file to the 1964 directory (not the plugin directory) Select the raphnetraw plugin from the list in the Change Plugins dialog. raphnetraw_net.dll in plugin/ libhidapi-0.dll in the 1964 folder Plugin selection



Only the "net" version (see Special versions ) of this plugin is compatible with 1964. This is due to a performance hack that only works with Project64. (This hack was also found to break net play).Installation for use with 1964 is as follows:

Usage (mupen64plus under Windows)

mupen64plus-input-raphnetraw-windows-0.9/ mupen64plus-input-raphnetraw-windows-0.9/README.md mupen64plus-input-raphnetraw-windows-0.9/dist_win64/ mupen64plus-input-raphnetraw-windows-0.9/dist_win64/libhidapi-0.dll mupen64plus-input-raphnetraw-windows-0.9/dist_win64/mupen64plus-input-raphnetraw.dll mupen64plus-input-raphnetraw-windows-0.9/dist_win32/ mupen64plus-input-raphnetraw-windows-0.9/dist_win32/libhidapi-0.dll mupen64plus-input-raphnetraw-windows-0.9/dist_win32/mupen64plus-input-raphnetraw.dll If you use a 64-bit version of mupen64plus, copy the files from the dist_win64 directory. For the 32-bit version, copy the files from the dist_win32 directory.



Copy the appropriate plugin (.dll files) to the directory your mupen64plus installation uses for plugins (eg: Along with the main executable and other plugin .DLL files). Then run the emulator like this: $ mupen64plus --input mupen64plus-input-raphnetraw (of course you will add other arguments such as the rom file...)

The .zip version of the plugin available from the downloads section above contains the 32 and 64 bit versions of the plugin files. The .zip contents will look like this:If you use a 64-bit version of mupen64plus, copy the files from thedirectory. For the 32-bit version, copy the files from thedirectory.Copy the appropriate plugin (.dll files) to the directory your mupen64plus installation uses for plugins (eg: Along with the main executable and other plugin .DLL files). Then run the emulator like this:(of course you will add other arguments such as the rom file...)

Usage (mupen64plus under Linux)

$ mupen64plus --input mupen64plus-input-raphnetraw (of course you will add other arguments such as the rom file...)

Copy the plugin (.so file) to the directory your mupen64plus installation uses for plugins. Then run the emulator like this:(of course you will add other arguments such as the rom file...)

Confirming that it works (mupen64plus)







If you are not sure if you were able to enable, have a look to the emulator output:

Disclaimer