Author Topic: arosx (xinput gamepad usb class)  (Read 1026 times)

dizzy

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Re: arosx (xinput gamepad usb class)
« Reply #15 on: January 15, 2019, 09:38:50 AM »
@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... ?
« Last Edit: January 15, 2019, 06:46:58 PM by dizzy »

dizzy

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Re: arosx (xinput gamepad usb class)
« Reply #16 on: January 15, 2019, 07:26:10 PM »
I'll start tomorrow renaming things differently, I just don't understand the point... I'll call the arosx.class XUSB.dll and arosx.library XINPUT.dll  ;D
EDIT: Holy shit! I can actually do that!

« Last Edit: January 15, 2019, 07:38:58 PM by dizzy »

nikos

  • Member
  • ***
  • Posts: 151
  • Karma: +2/-1
    • aspireos
Re: arosx (xinput gamepad usb class)
« Reply #17 on: January 15, 2019, 07:36:12 PM »
Dizzy: When can I test :) What fantastic work you are doing :)

dizzy

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Re: arosx (xinput gamepad usb class)
« Reply #18 on: January 15, 2019, 07:42:02 PM »
Dizzy: When can I test :) What fantastic work you are doing :)
I will start my 6 days of work tomorrow morning at 5:30 it might not be until the end of work schedule that I'll continue with it. It's almost all there, just needs some sort of interface for games to attach to. It is also all there but no code in the library.

nikos

  • Member
  • ***
  • Posts: 151
  • Karma: +2/-1
    • aspireos
Re: arosx (xinput gamepad usb class)
« Reply #19 on: January 15, 2019, 08:36:04 PM »
Great Dizzy. Have a great work week and looking forward to test it when ready :)

NinjaCowboy

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
Re: arosx (xinput gamepad usb class)
« Reply #20 on: January 16, 2019, 02:59:32 PM »
Did the Amiga CD32 have an API to handle game controllers? I wonder if that could be extended to have joystick support and work with your Xbox 360 driver.

dizzy

  • Newbie
  • *
  • Posts: 36
  • Karma: +0/-0
Re: arosx (xinput gamepad usb class)
« Reply #21 on: January 22, 2019, 03:01:32 PM »
Did the Amiga CD32 have an API to handle game controllers? I wonder if that could be extended to have joystick support and work with your Xbox 360 driver.
Not sure, I think it used the lowlevel library.

I've fixed a thing or two since the last commit. Poseidon event handler system which I based my event handling takes a ULONG as input but it is only stored as a UWORD. Took some time as I had no glue why my events didn't show which controller gave an event...

I am also totally lost as what events should I present. The arosx.class could send events on plugging the controller or unpluging  it, but if there is no listener for events then the events are lost, like teardrops in the rain. They aren't even sent with the code at hand.

Things get even more complicated as I don't want to hardwire the arosx as gamepad only. I have only gamepads, but what would happen if a xinput racing wheel is attached? There would be a long structure defining all the possible events as booleans...

Or should I just inform with the event that a change has happened and the game code would have to inspect what has changed? Poll the input and check...
« Last Edit: January 22, 2019, 03:11:11 PM by dizzy »