@dizzy. kalamatee is complaining about your naming convention "arosx".. he says it should be simply "xinput".
wanna join us on slack?
edit: ah, he wrote you already. nevermind.
I'm not entirely so fond of it either, it comes from the fact that it's for AROS and purely for XInput. I could have called it AROS_XINPUT or something.
Either way, as XInput's internals are closed I think for the reimplementation for XInput controllers it suits just fine. It doesn't even try to pass as XInput, it's different.
The base class arosx.class, which is also a library, doesn't need arosx.conf to build includes, our build system needs it to be in place for building the class/library. Could it use the Poseidon base class conf? Poseidon uses that to call the classes. EVERY SINGLE ONE .conf file is redundant except the base class conf, make a change in there and crash is about to happen. Only the base, version and some library flags are used.
There is no option to pass different .conf file...
Build system also builds the linklib for arosx.library although it has no code, but only needs to build the includes...
On Windows the layer communicating with the XInput device via USB is called XUSB. Should I name the base class to XUSB? XInput does not directly communicate with any controller.
Last night in the bed crying myself to sleep, I tried to justify myself why the other arosx.conf is in the inlude folder. It's sole purpose is to build the includes for the arosx.library... Or so I told myself...
On Apple the call to discover wireless controllers is called startWirelessControllerDiscoveryWithCompletionHandler, I would have prefixed it with "IOS_" or" Apple_"
No just kidding, the purpose of "AROSX_" prefixes is to prevent naming conflicts. I think no one is fool enough to name their things in a similar way...
Not much things are exposed to the outside world containing that prefix, the class code is littered with it though... Which is kinda pointless if the point is to prevent naming conflicts as I could name a thing differently if conflict occured and not just name everything with that prefix...
Well... The real truth why things are the way they are is that there is no preliminary planning involved with this... It all just kind of evolved... No real answer to this one I'm afraid...
I could have created a single library that talks to Poseidon directly, but then I would have to query it for all the devices. Now they are handed to us by the interface binding mechanism.
Basicly the arosx.class and arosx.library is the same thing. Poseidons arosx.class has in essence two library interfaces, one for Poseidon (arosx.class) and one for the user (arosx.library) then there are the handler tasks dancing in between. It could also be made such that the class code exposes message ports (or a device interface) and some library talks to it via those...
I haven't made up my mind how the arosx.library attaches itself to a controller. arosx.class could call some function "AddController" That way also other than XInput controllers could be bind with the library, but then arosx.library would have to have some more generic name, "gamecontroller.library" or something... I don't foresee that anyone would take on the task to make hid.class controllers attach to anything else than lowlevel.library.
There still could be a third, more generic library that gathers different kinds of controllers, one being the four arosx controllers... Either things bind with arosx.library or arosx.library binds with some other game controller library.
If anyone wants to code such a game controller API then I'm all good with that. I've stated it before that I do not look forward defining any such game controller API.
controller
|
Poseidon
|
arosx.class/arosx.library
|
Game or game controller library
For the event based notifications, I'm thinking to imlement these functions:
port = CreateEventPort(controller id)
AttachEventHandler(&Handler, port)
RemoveEventHandler(controller id, port)
DeleteEventPort(port)
Or something... ?
