Emulating a GameCube controller joystick with arcade buttons?

Status
Not open for further replies.
Actually, both buttons pushed will happen very frequently for super short intervals on the x-axis of the left stick. There is a technique in Super Smash Bros. Melee called Dash Dancing, where you can run back and forth very quickly, and it is done a lot to trick out your opponent. The way this circuit works, I will have to let go of the other button for it to work, but there will most likely be very short periods of time where I am holding both down.

When I removed the joystick from the GC board, I tested it and saw that both pots on it had a resistance of about 36k ohms. If I increased the values of all resistors, it would make the circuit safer right? It is actually beneficial for me to do it because it puts the modifier resistors in a better selection range for my trimpots.

Here is a version with high resistances:

Code: 
$ 1 0.000005 19.867427341514983 61 5 43
r 752 384 864 384 0 47000
r 864 384 976 384 0 47000
r 624 336 720 336 0 2200
r 1008 336 1104 336 0 2200
s 752 352 864 352 0 1 false
s 864 352 976 352 0 1 false
R 1104 336 1136 336 0 0 40 5 0 0 0.5
g 624 336 608 336 0
r 864 320 976 320 0 3500
s 752 320 864 320 0 1 false
s 752 288 864 288 0 1 false
r 864 288 976 288 0 1000
w 752 288 720 336 0
w 752 320 720 336 0
w 752 352 720 336 0
w 720 336 752 384 0
w 1008 336 976 384 0
w 1008 336 976 352 0
w 1008 336 976 320 0
w 1008 336 976 288 0
w 864 352 864 384 0
w 864 416 864 384 0
 
Bumping up the values won't do any harm as long as you don't head much beyond maybe 36k*2 as the peak resistance (all buttons up in current design) since you would start to get noise issues and things jittering around. Otherwise current draw will be lower and things generally less exciting which is all to the good.
 
Interesting, I had no idea that was even a factor. Well with my current design all buttons up gives 100k, which is a decent margin about 36k*2, so maybe I should go down a bit. What is that number based off of out of curiosity?

Another question I have is, how do I determine the safety of sharing grounds between elements on the board? The c-stick is ultimately connected to 4 points, which means that the x and y axis share grounds. In my testing, I found that sharing the grounds for the x and y axis of the left stick works too. But also in my testing, I found that I could connect a button to any ground I could find (potentiometer or another button), and it would still function.

So what do you think I can get away with? Can I simply daisy-chain all of the grounds to one point on the controller, or is that a bit extreme? I figure I can get away with that with the buttons, but I'm worried about the pots.
 
Number comes from various guidance on which pots to use in things like midi controllers where they generally recommend 5 or 10k, and as you get up past 100k the current through the electronics reading the pot starts to approach that producing your signal and life gets interesting, and the amount of current from interference starts to approach that from your signal.

Gnds wise you are good, as long as you don't actually have any PCB components between two points that you thought were ground, since that will add an unexpected series resistance that might complicate life.

As a general principle thing you would keep signal grounds away from power grounds and radio frequency stuff has rules all of it's own but for this case anything that keeps it neat and tidy is fine since they are all basically low current DC signals.

If you were using more than one power source or have a battery in the system it's different but for this case where you have a single power source and a single chip it's all good.
 
Well I did some extensive testing, and I found that there are problems the circuit I made. The circuit works right, but sometimes the x and y axis seem to crosstalk a little somehow. Like if you push up, it will go up and slightly left when it was stationary when no buttons were pushed. Also, there is a technique in SSBM called shield dropping, which requires a stick movement of around 41% downward. It is a pretty precise technique, and when I would try it, it would only happen some of the time. So it seems there is noise too, and that is even with around 10k ohms net resistance.

I tried to use the digital pots that I had ordered before, and I actually got them working. However, I am having multiple problems with them. My biggest problem is that one of the pots seems to get stuck, even though I am setting it every cycle of the Teensy. I thought one of the pots might have been broken, but when I replaced it it gave the same problem. The strange thing is, it only seems to happen sometimes, and it is only happening to one pot so far. Sometimes it works fine, and then it will go through a period of time where it gets stuck every button press. My theory is that it might have something to do with setting the digipot's resistance every clock cycle. Maybe that is overloading it somehow? I know it isn't a problem with the logic part in my code, because the problem doesn't happen when I monitor with serial.

The other problem I am having is that the axis crosstalk I had with my resistor circuit happens here too, but only when I power it from the 3.3V from the GameCube controller. When I power the Teensy with USB and simply read from the pots, it works perfectly.

I think the GameCube controller has a 5V pin somewhere, so I might try powering the Teensy from that and see if it fixes it.


This is all very confusing and I'm not quite sure where to troubleshoot. If anyone can provide any help or suggestions I would greatly appreciate it!

Here is my Teensy code for reference:

Code: 
#include <SPI.h>

void writeToDigitalPot (int writePin, int inputValue);
int getPotValue (int potLowPin, int potHighPin, int &potPressOrder, int inputPotResolution);
int applyPotModifiers (int potFullValue, int mod1Pin, int mod2Pin, int inputPotResolution);

const int masterPotResolution = 128;

const byte potWriteAddress = 0x00;

// Slave Select Pins:
const int lsXOutPin = 20;
const int lsYOutPin = 21;

// Buttons:
const int lsLeft = 0;
const int lsRight = 1;
const int lsDown = 2;
const int lsUp = 3;
const int xMod1 = 4;
const int xMod2 = 5;
const int yMod1 = 6;
const int yMod2 = 7;
const int cLeft = 8;
const int cRight = 9;
const int cDown = 10;
const int cUp = 12;

//Potentiometer low/high press-order states:
//0 means low was pressed first.
//1 means high was pressed first.
//-1 means neither was pressed first.
int lsXOrder = -1;
int lsYOrder = -1;
int cXOrder = -1;
int cYOrder = -1;

void setup()
{
    pinMode (lsLeft, INPUT_PULLUP);
    pinMode (lsRight, INPUT_PULLUP);
    pinMode (lsDown, INPUT_PULLUP);
    pinMode (lsUp, INPUT_PULLUP);
    pinMode (xMod1, INPUT_PULLUP);
    pinMode (xMod2, INPUT_PULLUP);
    pinMode (yMod1, INPUT_PULLUP);
    pinMode (yMod2, INPUT_PULLUP);
    pinMode (cLeft, INPUT_PULLUP);
    pinMode (cRight, INPUT_PULLUP);
    pinMode (cDown, INPUT_PULLUP);
    pinMode (cUp, INPUT_PULLUP);

    pinMode (lsXOutPin, OUTPUT);
    pinMode (lsYOutPin, OUTPUT);

    SPI.begin();
}

void loop()
{
    //---------Left Stick X-Axis----------   
    int lsXValue = getPotValue (lsLeft, lsRight, lsXOrder, masterPotResolution);

    lsXValue = applyPotModifiers (lsXValue, xMod1, xMod2, masterPotResolution);

    writeToDigitalPot (lsXOutPin, lsXValue);

    //---------Left Stick Y-Axis----------    
    int lsYValue = getPotValue (lsDown, lsUp, lsYOrder, masterPotResolution);

    lsYValue = applyPotModifiers (lsYValue, yMod1, yMod2, masterPotResolution);

    writeToDigitalPot (lsYOutPin, lsYValue);
    
    //----------C-Stick X-Axis------------
    //int cXValue = getPotValue (cLeft, cRight, cXOrder, masterPotResolution);

    //writeToDigitalPot (cXValue);

    //----------C-Stick Y-Axis------------
    //int cYValue = getPotValue (cDown, cUp, cYOrder, masterPotResolution);

    //writeToDigitalPot (cYValue);
}

void writeToDigitalPot (int writePin, int inputValue)
{
    digitalWrite (writePin, LOW);
    
    SPI.transfer (potWriteAddress);
    SPI.transfer (inputValue);
    
    digitalWrite (writePin, HIGH);
}

int getPotValue (int potLowPin, int potHighPin, int &potPressOrder, int inputPotResolution)
{ 
    int potMin = 0;
    int potMax = inputPotResolution;
    int potMiddle = ceil (inputPotResolution / 2.0);
    
    boolean lowIsPressed = !digitalRead (potLowPin);
    boolean highIsPressed = !digitalRead (potHighPin);
    boolean lowWasPressedFirst = lowIsPressed && (potPressOrder == 0);
    boolean highWasPressedFirst = highIsPressed && (potPressOrder == 1);

    // Low Cases
    if (lowIsPressed && highWasPressedFirst)
    {
        potPressOrder = 1;
        return potMin;
    }
    if (lowIsPressed && !highIsPressed)
    {
        potPressOrder = 0;
        return potMin;
    }

    // High Cases
    if (lowWasPressedFirst && highIsPressed)
    {
        potPressOrder = 0;
        return potMax;
    }
    if (!lowIsPressed && highIsPressed)
    {
        potPressOrder = 1;
        return potMax;
    }

    // Middle Cases
    if (!lowIsPressed && !highIsPressed)
    {
        potPressOrder = -1;
        return potMiddle;
    }
    if (lowIsPressed && highIsPressed && (potPressOrder == -1))
    {
        potPressOrder = -1;
        return potMiddle;
    }

    return potMiddle;
}

int applyPotModifiers (int potFullValue, int mod1Pin, int mod2Pin, int inputPotResolution)
{
    int potMiddle = ceil (inputPotResolution / 2.0);
  
    double mod1Decimal = 0.20;
    double mod2Decimal = 0.41;
    double combinedModDecimal = 0.10;
    
    boolean mod1IsPressed = !digitalRead (mod1Pin);
    boolean mod2IsPressed = !digitalRead (mod2Pin);

    if (mod1IsPressed && !mod2IsPressed)
    {
        if (potFullValue < potMiddle)
        {
            return potMiddle - potMiddle * mod1Decimal + 0.5;
        }
        if (potFullValue > potMiddle)
        {
            return potMiddle + potMiddle * mod1Decimal + 0.5;
        }
    }
    if (!mod1IsPressed && mod2IsPressed)
    {
        if (potFullValue < potMiddle)
        {
            return potMiddle - potMiddle * mod2Decimal + 0.5;
        }
        if (potFullValue > potMiddle)
        {
            return potMiddle + potMiddle * mod2Decimal + 0.5;
        }
    }
    
    if (mod1IsPressed && mod2IsPressed)
    {
        if (potFullValue < potMiddle)
        {
            return potMiddle - potMiddle * combinedModDecimal + 0.5;
        }
        if (potFullValue > potMiddle)
        {
            return potMiddle + potMiddle * combinedModDecimal + 0.5;
        }
    }

    return potFullValue;
}
 
Two potential sources of cross talk with the buttons rig, one is if the changing current draw through the buttons on one axis is changing the supply voltage to both button sets and throwing out the measurement on the other axis. Other is if the actual ADC components in the controller have got cross talk. So one thing to do is make really sure the supply and ground points you are using really are 'shared' points on the original axis measurment wiring. They may have added their own limiting components to the PCB and you need to have + and - wires for each axis plus a seperate supply for the Teensy if you go that route.

Re testing Digi pots if you can still test to your PC it may be useful to run something like writeToDigitalPot (lsXOutPin, (millis()/500)%128); which should sweep the pot across it's full range of output values (128 is max isn't it?) at a slow rate (maybe drop that 500 to 100 or 50 if it's too slow). You can use a multimeter while this is going on (hence slow rate) and also watch if other axis are up to things they shouldn't.
 
Do a quick count on how often you are cycling in loop() - unless something there has a wait it'll be thousands of times a second.

Using an elapsedMillis limitLoop; like below it will only process everything 20 times per second. See if that alters anything and then adjust for the updates you need per second.

if ( limitLoop > 50 ) {
limitLoop = 0;

// current loop() code here
}
 
Thanks for the suggestions. I will do some more testing when I get the chance and update with my findings.


On a fighting game forum, I found a thread that has a similar project to mine. The project uses a digital arcade stick and a modifier button that works on both the x and y axes at the same time. In a post, the guy who wired it mentions that he used 4066 switching chips and hex inverters to do it, but he doesn't really go into detail how.

I asked in that thread, but until there is an answer, if anyone could explain how that might be done it would help me out a lot!

This is the thread: http://forums.shoryuken.com/discuss...ck-updated-prototype-arcade-stick-coming-soon
 
A 4066 is a digital switch, so guessing it's using similar thought process to your hardware switch design but with the 4066 adding and removing resistors from circuit driven by some basic logic from the hex inverters. Would be suspecting his wiring is pretty complex if he's doing it right since it'll need to implement the code you have for the digi pots as hardware, and face similar problems to your switch design with avoiding short circuit events blowing everything up.
https://en.wikipedia.org/wiki/NAND_logic
http://www.nxp.com/documents/data_sheet/74HC_HCT4066.pdf
Unless that stuff is making sense I'd be careful about trying to emulate it since it would be tricky to fault find.

Done right it would be a cheap and robust way to do it though.
 
I did a lot of testing today and I think I solved my problems.

The digipots sticking seemed to be a result of updating so frequently. I guess they don't like being updated on the order of MHz. So I added parts to my code that only update the pots when they change, and so far this has been working perfectly with no sticks. I've also been running the clock at 2 MHz, which seems to be working fine. I don't know if I would benefit from running it higher.

I was having problems running off of the 3.3v, so I soldered onto the 5v pin on the GC controller, and so far this has been working out great. No problems there yet with axis crosstalk or anything. I am powering the digipots with the 3.3v coming off of the Teensy.

The last problem was the noise. I am pretty confident that this is a problem with my breadboard and crappy jumper wires. If you hold shield in the game, you can tilt the shield around with analog movement. I noticed that when tilting the shield, if my hand would bump into the jumper wires connecting everything, the character would jitter around a lot. This is enough to cause missing shield drops. I'm hoping this won't be a problem when I get everything all soldered together. Fingers crossed on that one.


So my considerations now are figuring out the logistics of making the controller. I can't really see a way around using my Teensy in it, so I'll probably end up doing that. I have a Teensy with pins in it, so I might solder it to a protoboard or something. If anyone has any more suggestions on building it I would definitely be open to hearing them.


I have another question: In the places where there were joystick pots, if I am not using those grounds and high voltage spots, should I put a resistor through them? Or should I just leave them unconnected? I don't seem to be having any problems right now leaving them unconnected, I am just wondering if there is any benefit to doing that.
 
Leaving the unused supply and return points are fune, though be aware of them in however your final rig works since you don't want bare wires touching the exposed pads.

If you can find something like them I'm a big fan of https://www.adafruit.com/product/591 and the like as having the right numbers of tracks in the right places for many things, and having proper mounting holes but vero(strip) board is also fine. Main things now come down to soldering quality - dry joints are not something you want in something that gets pounded
https://www.google.com.au/search?q=...ppbQAhUJG5QKHUW8ANgQ_AUICCgB&biw=1920&bih=971

Otherwise it's mechanical, make sure you allow enough room, make sure things are bolted down and see if you can make it easy to fix.
 
Thanks for the tips. I have some protoboard that I had ordered before. It isn't quite like the one you posted because it has no default connections, but it will probably work ok. I just need to figure out a good way to connect it all on the board. It looks like I'll have to use a lot of wires since the digipots are kind of rigidly laid out, same with the Teensy. And the Teensy isn't laid out in such a fashion that solder bridges would work well in this case.
 
It has taken quite a while, but after a lot of soldering and testing, my design works really well.

I have another question however. The GameCube controller has a D-pad, which has four inputs that all share a ground with the rest of the controller. I was originally intending to simply connect four buttons to these inputs, but I have an idea now to make a modifier button that I can hold down that allows me to use my other modifier buttons as the D-pad.

This may seem stupid, but my question is, how can I use outputs from my Teensy to complete the D-pad connections to the ground?
 
Alkamist said:
This may seem stupid, but my question is, how can I use outputs from my Teensy to complete the D-pad connections to the ground?
Click to expand...

You might be able to do it, providing both boards share grounds, voltage levels, etc. However, I'm a software guy, and I have fried several boards, so I would defer to one of the EE types in terms of whether it is a good idea from an electrical point of view.

However rather than directly connecting the Teensy, it might be better to use an optocoupler to provide a degree of electrical separation between the two boards. An optocoupler is a chip with a LED on the inside and a photo sensor. When you apply current to light up the LED, the photo sensor completes its circuit. This way, the Teensy isn't directly connected to the gamecube controller.

I've used the Vishay CNY74-2H-ND optocouplers in the past, with 4 buttons, you may want the CNY74-4H-ND instead:

To connect to the Teensy, connect a resistor to each the output pins on the Teensy (I use 220 ohm pull-down resistors) to the input pins on the CNY74, and connect each of the ground input pins to your ground. Then connect power/ground to the output CNY74. When testing it, it is useful to connect a led/resistor to the outputs, so you can see when it is pushed.

I'm sure other optocouplers can be used, but initially I had some problems with other brands (perhaps they needed 5v, etc. or I didn't wire them correctly).
 
Last edited:
MichaelMeissner said:
You might be able to do it, providing both boards share grounds, voltage levels, etc. However, I'm a software guy, and I have fried several boards, so I would defer to one of the EE types in terms of whether it is a good idea from an electrical point of view.

However rather than directly connecting the Teensy, it might be better to use an optocoupler to provide a degree of electrical separation between the two boards. An optocoupler is a chip with a LED on the inside and a photo sensor. When you apply current to light up the LED, the photo sensor completes its circuit. This way, the Teensy isn't directly connected to the gamecube controller.

I've used the Vishay CNY74-2H-ND optocouplers in the past, with 4 buttons, you may want the CNY74-4H-ND instead:

To connect to the Teensy, connect a resistor to each the output pins on the Teensy (I use 220 ohm pull-down resistors) to the input pins on the CNY74, and connect each of the ground input pins to your ground. Then connect power/ground to the output CNY74. When testing it, it is useful to connect a led/resistor to the outputs, so you can see when it is pushed.

I'm sure other optocouplers can be used, but initially I had some problems with other brands (perhaps they needed 5v, etc. or I didn't wire them correctly).
Click to expand...

Thank you for the information. That seems quite a bit more complicated than I hoped it would be. I'll probably just end up sticking with buttons connected to the inputs on the board then and save myself some soldering and potential hair pulling. I will reference this if I change my mind however.
 
Opto couplers are the safe answer, but if you check the pins with respect to the Teensy gnd and don't find anything outside 0-3.3v that covers most of the bang potential. Other test would be the current flow through the pin which should be low, but a test with multimeter in series and confirming you can't get more than 20mA would be another method.

Or you can just do it, see if the Teensy goes bang and if it does get another one. Depends on your time/money tradeoffs.

To actually get it to work you would either be toggling the input beteween input and out put, or better between output and disable - https://forum.pjrc.com/threads/24087-How-to-disable-a-pin

The better answer would be to us a transistor as the switching element but that will take up more space so you'd be trading more robust design for size and complexity.
 
Another quick question:

I recently had an idea that would require the Teensy to be aware of a button press that is connected directly to the GameCube controller board. So basically I need one of the arcade button to complete two circuits. Would the best thing for this be a DPDT relay? If so, what kind should I be looking for? There are so many options to choose from on Mouser and I'm not sure what the right choice is for a GC controller board.
 
A DPST relay will do the job, but will add a time delay as the contacts physically move, and if this is a button that you tap quickly may not work well either. Basically you shop for the cheapest one that drives at the voltage you need, which will be a problem since it's hard to make 3.3V relays and even 5V ones are relatively rare.

Check the voltages on the existing button both open and closed and see if it's a pull high or pull low design. You may find you can just connect through your existing button in parallel, if it switches in the right direction and the voltages are the same. If not then you probably want to use a couple of basic transistors

https://learn.sparkfun.com/tutorials/transistors
See this drawing here
https://cdn.sparkfun.com/r/400-400/assets/learn_tutorials/1/9/3/npn-switch-led.png
and the digital logic section. Don't get to wound up in how transistors work but do get your head around the conditions when the transistor conducts (0.6V) and when it doesn't (no Base Emitter) and how to blow them up (to much base-emitter current). For digital logic the exact resistor values are less important as long as you hit those limits of 'enough to turn it on but not so much something catches fire) which leaves a fair bit of room for just dropping whatever parts you have on the bench.

Do notee that the classic transistor to switch LED on linked above inverts logic, but if this is a problem you just chain two together and get the result you need to press the button by inverting twice.
 
GremlinWrangler said:
A DPST relay will do the job, but will add a time delay as the contacts physically move, and if this is a button that you tap quickly may not work well either. Basically you shop for the cheapest one that drives at the voltage you need, which will be a problem since it's hard to make 3.3V relays and even 5V ones are relatively rare.

Check the voltages on the existing button both open and closed and see if it's a pull high or pull low design. You may find you can just connect through your existing button in parallel, if it switches in the right direction and the voltages are the same. If not then you probably want to use a couple of basic transistors

https://learn.sparkfun.com/tutorials/transistors
See this drawing here
https://cdn.sparkfun.com/r/400-400/assets/learn_tutorials/1/9/3/npn-switch-led.png
and the digital logic section. Don't get to wound up in how transistors work but do get your head around the conditions when the transistor conducts (0.6V) and when it doesn't (no Base Emitter) and how to blow them up (to much base-emitter current). For digital logic the exact resistor values are less important as long as you hit those limits of 'enough to turn it on but not so much something catches fire) which leaves a fair bit of room for just dropping whatever parts you have on the bench.

Do notee that the classic transistor to switch LED on linked above inverts logic, but if this is a problem you just chain two together and get the result you need to press the button by inverting twice.
Click to expand...

Thanks for the info. Yeah a relay doesn't seem like what I want if it has moving parts and delay. Transistors seem like more of what I need. I'll look into it and see if it's something worth doing!
 
So my controller is working really well, but I've had some ideas to improve the design.

I kind of want to experiment with this library (https://github.com/NicoHood/Nintendo) to try to make a version of my controller that requires only a Teensy. The benefits of this are that I don't have to rely on a padhack of a GameCube controller, and all of my buttons will run through the Teensy, which will allow me to experiment with all sorts of things.

The library compiles out of the box if you do it for an Arduino, but it doesn't seem to work if you try to compile it for a Teensy 3.2, which is what I have. However, I was able to get it to compile for the Teensy++ 2.0, but in order to do that, I had to change all of the .c files in the library to .cpp. If you don't do this, you get tons of compiler errors saying the type bool is undefined.

I'm wondering, does anyone know of changing the files to .cpp will cause any problems? I figured I would post here and ask in case anyone knows. If it won't work for a Teensy, I would have to go with an Arduino. I would rather not do that though since I need one with at least 25 digital ins for my buttons, and those are expensive. A Teensy++ 2.0 would be ideal to use.

Another question is: does anyone know if a Teensy++ 2.0 would be able to communicate with a GameCube's data line properly? I can power it with the 5v line coming from the GameCube, but I'm not sure what that means for the data line.
 
.cpp file extensions should be fine and expected to work.

The GameCube is likely using AVR Arduino specific processor instructions versus the Teensy 3.2's ARM processor. Unless there are alternatives that are ARM compatible those AVR specific items would need to be addressed to USE Teensy and ARM compatible methods.

Indications are it uses AVR specific assembler code that would need to be replaced:
1.2.1 Release (27.01.2017)
* Fix compiling of assembler functions
Click to expand...
 
defragster said:
.cpp file extensions should be fine and expected to work.

The GameCube is likely using AVR Arduino specific processor instructions versus the Teensy 3.2's ARM processor. Unless there are alternatives that are ARM compatible those AVR specific items would need to be addressed to USE Teensy and ARM compatible methods.

Indications are it uses AVR specific assembler code that would need to be replaced:
Click to expand...

Thanks for the info. So the Teensy++ 2.0 should work then is what I'm gathering.

Do you know how the Teensy being powered by 5v would affect the data line? Pardon my ignorance, I don't really know how it works. I think the 5v coming from the GameCube is originally intended to power the rumble motor, not the logic. I could be wrong though. Would powering the Teensy from 5v make it incompatible with the GameCube's data line?

I know there is information on converting the Teensy++ 2.0 to work with 3.3v, but it seems you have to use 8MHz for that, which wouldn't be compatible with this library.
 
I can't speak for the T++2.0 much - except it is an AVR powered 5V processor and should be good for use with AVR code base in a 5V system.

I expect with the Arduino UNO or whatever shown on the GitHub page as presented being a 5V device it should designed for and be good to go at 5V - as long as all the components are on the 5V level? If other connected elements of the system are 3.3V specific then those would need to be addressed.
 
defragster said:
I can't speak for the T++2.0 much - except it is an AVR powered 5V processor and should be good for use with AVR code base in a 5V system.

I expect with the Arduino UNO or whatever shown on the GitHub page as presented being a 5V device it should designed for and be good to go at 5V - as long as all the components are on the 5V level? If other connected elements of the system are 3.3V specific then those would need to be addressed.
Click to expand...

I see. Well I would only be using arcade buttons and maybe a potentiometer at some point, so I guess I would be fine.

I suppose it would be worth getting a Teensy++ 2.0 and trying it out. Thanks for your help!
 
So after a bunch of testing I have found that the Teensy++ 2.0 does work with the NicoHood Nintendo library.

I now have a new issue. In my controller, I am trying to create a macro system for fun. It would allow me to string together various inputs at different timings. One specific one I am trying to do requires two inputs spaced out, and the timing is frame perfect at 60 fps. So I need to be able to register an input in a specific 16.6666 millisecond window.

I've been trying to use elapsedMillis and elapsedMicros, but the input timing seems to fluctuate between 1-3 frames, making it unreliable for a macro.

So my questions are:
- Is this timing fluctuation because elapsedMillis and elapsedMicros are not precise?
- Is it caused by the time-sensitive code that is executed by the NicoHood Nintendo library?
- Is there some other way I should be going about this?

It could be a problem with the input polling of the game but I don't think it should be that far off. It also could be a problem with the NicoHood Nintendo library, or a problem with the way the Teensy interacts with it. I'm not sure.

If anyone has any insight I would appreciate it!
 
Status
Not open for further replies.
Back
Top