|
| 1 | +The tests branch of gca-node are initial tests that prove that communication with the Wii U GameCube™ Adapter is possible on most computer machines that support NodeJS. |
| 2 | +These tests also provide tools for polling data read from the GameCube. |
| 3 | + |
| 4 | +## LibUSB tests |
| 5 | +LibUSB tests provide testing of status of communication on Visual C++ with LibUSB. |
| 6 | + |
| 7 | +### Building |
| 8 | + |
| 9 | +## NodeBridge tests |
| 10 | +As the name suggests, these tests provide the bridge interface between NodeJS and the Wii U™ GameCube Adapter. |
| 11 | + |
| 12 | +NodeBridge 1 test sends a test interrupt transfer to start communicating with the adapter. |
| 13 | +NodeBridge 2 test sends an interrupt transfer to read raw data from the adapter. |
| 14 | + |
| 15 | +### Building |
| 16 | +Building NodeBridge tests work pretty much like building addons for Nodejs. On your command prompt, type in: |
| 17 | + 1. `npm install node-gyp -g` to install node-gyp to your PATH. |
| 18 | + 2. `npm install nan --save` to install NAN, a supplementary utility to build the tests. |
| 19 | + 3. `node-gyp rebuild` to configure the source code and build the addon from it. |
| 20 | + |
| 21 | +### Raw data info |
| 22 | +The raw data obtained from the Adapter in NodeBridge Test 3 should be an array of chars of length 37. The structure should be the following: |
| 23 | +`[Header] [Status] [Buttons1] [Buttons2] [Left stick X] [Left stick Y] [C stick X] [C stick Y] [L axis] [R axis]` |
| 24 | +Except for the first element, all of these elements appear four times in the array, one for each port of the adapter, thus one for each controller. |
| 25 | +(4 controllers * 9 chars + 1 header = 37 elements) |
| 26 | + |
| 27 | + * [Header] seems to be a header char for the entire adapter itself. |
| 28 | + * [Status] seems to be a boolean for checking if a controller is connected on the designed port. |
| 29 | + * [Buttons1] contains information about the status of 8 buttons, determined by bits written from left to right: |
| 30 | + * Bit 1: D-Pad UP button |
| 31 | + * Bit 2: D-Pad DOWN button |
| 32 | + * Bit 3: D-Pad RIGHT button |
| 33 | + * Bit 4: D-Pad LEFT button |
| 34 | + * Bit 5: Y button |
| 35 | + * Bit 6: X button |
| 36 | + * Bit 7: B button |
| 37 | + * Bit 8: A button |
| 38 | + * [Buttons2] contains information about the status of the remaining 4 buttons, determined by the least significant nibble, from left to right: |
| 39 | + * Bit 5: L trigger button |
| 40 | + * Bit 6: R trigger button |
| 41 | + * Bit 7: Z button |
| 42 | + * Bit 8: START button |
| 43 | +* [Left stick X] represents the horizontal axis of the left stick. It could actually be a short or even a float. |
| 44 | +* [Left stick Y] represents the vertical axis of the left stick. It could actually be a short or even a float. |
| 45 | +* [C stick X] represents the horizontal axis of the C-Stick. It could actually be a short or even a float. |
| 46 | +* [C stick Y] represents the vertical axis of the C-Stick. It could actually be a short or even a float. |
| 47 | +* [L axis] represents the analog input axis of the L trigger. It could be a short. |
| 48 | +* [R axis] represents the analog input axis of the R trigger. It could be a short. |
| 49 | + |
| 50 | +Rumble data is not obtained from here. Rather, it seems to be a command data. |
0 commit comments