-
-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid unreferenced Gamepad instances to be created by the compiler #316
base: master
Are you sure you want to change the base?
Conversation
|
||
|
||
extern SingleGamepad_ Gamepad5; | ||
extern SingleGamepad_ Gamepad6; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I remember correct, only 3 will ever work, as the 32u4 only has 6 usb endpoints, of which 3 are used by the serial?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, but they turn up handy if the CDC serial gets disabled. Since with this modification their presence won't cause any overhead, I thought I'd throw them in.
Does it seem to fix, or does it really fix the issue? |
It fixes the issue on a project of mine. I need to test on other projects before I can say it definitely does with confidence. Just thought I'd share the patch in the meantime, so that maybe other people could test on their own. |
Just noticed an odd side-effect: Gamepad1 no longer corresponds to the first gamepad detected by the system, sigh. Apart from this problem, I am using 6 controllers together with no issues (of course the CDC Serial was disabled). |
I think the order of Gamepad creation could be related to:
So you could try to change the name of the cpp files maybe. Another idea would be to add special attributes to the class to change its construction order. I am not sure if that is possible, but I remember that there could be options like that. Is it even important to have them in the correct order? |
I thought the same, but the first use in my code is in an array which is populated in order. Files and instances are named in ascending order so I see no way that could lead to the reverse order. I think users would expect Gamepad1 to be the first controller, I think we should preserve this behavior. |
I dont know, but I bet you will find it out. |
More testing confirms that this solves the initial issue, but still I can't understand why the order of controllers gets reversed. |
Sorry to revive this old conversation, but I’m having trouble implementing SukkoPera’s fix in my code, which currently has only 2 HID gamepads. The only way I can get rid of the third is by deleting the extra SingleGamepadX.cpp files and removing the lines in SingleGamepad.h. I’d like to be able to dynamically change the number of HID gamepads generated. Is there a way to accomplish this? |
Hi! First of all, @NicoHood I know that maintaining a project isn't easy, so thanks a lot for this library! Is there any chance to have this PR merged? I am experiencing the same issues as in #266, and although creating instances in the lib files is common practice in the arduino environment, it get's kind of annoying when you try to dive a bit deeper. For what I've been reading the order of compilation is not defined by the C standard, but if there's a GCC behavior we could try to hack around that to make it work for most of the people. |
This seems to fix #266 upstream.
Since now only referenced Gamepad instances are actually created by the compiler, I took the liberty of adding Gamepad5 and 6.