Skip to content
This repository was archived by the owner on Mar 18, 2022. It is now read-only.

Commit 06922da

Browse files
committed
Added info about tests
1 parent bf0fdc2 commit 06922da

1 file changed

Lines changed: 50 additions & 0 deletions

File tree

TESTS.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
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

Comments
 (0)