Thanks for the good ideas Leif. For a first attempt, I've decided to implement it in parallel with the existing Joystick class, in the same way as the AppleRemote is done. I think doing it this way will help me understand the requirements better. After that I will go for a simpler solution (as you've suggested), and then ask for opinions on possible inclusion into the main pyglet branch. This is also a way for me to learn the codebase better, as I really like pyglet and want to be able to contribute more in the future.
I've already got an idea for handling the configuration database. It will be basically the same way SDL does things, as I feel this works well. 1. Firstly, there will be an internal database (list of dictionaries or similar) that contains predefined support for the most popular game controllers. 2. Secondly, there will be a method from adding additional mappings from a file. SDL has the "SDL_GameControllerAddMappingsFromFile" function, so I want to add something similar. Regarding #2, I've worked out a crude parser for the sdl2 community database at https://github.com/gabomdq/SDL_GameControllerDB. I want to have support for this format, because it's also the same format that is produced by Steam when you configure a controller in "Big Picture Mode" (the TV interface for Steam). The work has already been done in this regard, so why not use the same format. On Friday, October 30, 2015 at 1:52:47 PM UTC+9, Leif Theden wrote: > > I would use the existing API, and layer your virtual device on top of > that. Each platform has their own way of getting input from devices, and > creating a 'parallel implementation' at the device level would involve > writing an implementation for each platform (win32, os x, linux). By using > the existing API, you will basically just be making a mapping layer between > real events and the 'normalized' events that fit your universal controller > model...if that makes sense. > > > https://pyglet.readthedocs.org/en/pyglet-1.2-maintenance/programming_guide/input.html#using-joysticks > > Here's a couple ideas for using the existing API: > > 1. Create a subclass of Controls (pyglet.input.base.Control) that map a > value from an existing device to your generic model. Then aggregate the > Control objects into a Joystick instance. This is how pyglet does it > (besides the event mapping). You will get event binding with decorators > and basically a drop-in replacement. I'd recommend this approach first. > > 2. Create a subclass of EventDispatcher, and listen to all joystick > events. The new class will have a dict mapping with keys of raw input for > a specific controller and values of your generic model. Subscribe to all > joystick events, then dispatch events that fit your model. > > 3. Create a generic class with a set of on_joy_press, on_joyaxis methods > that will map inputs. This class can be customized and events > bound/subscribes to a device with joystick.push_handlers > > Those are my ideas at the moment, I hope that gives you some direction. > Finally, I hope you decide to use the existing pyglet API, as opposed to > hacking evdev or something; your work will work for all platforms without > much effort. > > If you are really not sure what to do, you can tackle non API things > first, like sourcing a database for joystick devices and building a > json/xml file that can be loaded in the module to supply the button/axis > mapping. I realize you linked one already, but that will have to be > transformed into something python can use, like a dict. > > > On Thursday, October 29, 2015 at 9:14:09 PM UTC-5, Benjamin Moran wrote: >> >> The input module would make sense as a package. >> >> My issue with the Game Controller implementation is more a logistical >> one. From a high level, "Game Controllers" are really simple. They are just >> joystick devices that match an internal configuration database. They then >> expose a consistent internal button/axis/trigger mapping. So essentially, >> the code is the same as a Joystick, plus the additional database check and >> button mapping. With that in mind, I was debating whether or not it would >> make sense to layer it on top of the Joystick class, or just create a >> parallel implementation. >> >> Layering it on top of the Joystick class would require a few additions to >> that class, so maybe it's not a good idea for a first revision. I think >> I'll do a parallel implementation, even if it does mean duplicating some >> methods (for example the _create_joystick method in evdev.py). >> >> >> >> >> >> >> >> On Friday, October 30, 2015 at 3:57:25 AM UTC+9, Rob wrote: >>> >>> And you thanks for the contribution. >>> >>> For the place to add it, I am thinking we might need to upgrade the >>> input module to a package. We can then expose the original contents of the >>> input module through __init__.py. >>> >>> Rob >>> On 29 Oct 2015 4:40 pm, "Benjamin Moran" <benmo...@gmail.com> wrote: >>> >>>> Thanks Leif, and Rob, for your feedback. >>>> >>>> I've been working on my Game Controller implementation as well, but >>>> need some opinions on the best place to add it in. It's probably best to >>>> start a new thread for that. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "pyglet-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to pyglet-users...@googlegroups.com. >>>> To post to this group, send email to pyglet...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/pyglet-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
