AROS World Exec
Development => AROS Software Development => Topic started by: dizzy on January 10, 2019, 09:44:35 AM
-
Hi,
I've just updated the arosx.class on AbiV1 to show all the input values that the Microsoft game controller API provides on the interface setting gui.
Buttons:
XINPUT_GAMEPAD_DPAD_UP
XINPUT_GAMEPAD_DPAD_DOWN
XINPUT_GAMEPAD_DPAD_LEFT
XINPUT_GAMEPAD_DPAD_RIGHT
XINPUT_GAMEPAD_START
XINPUT_GAMEPAD_BACK
XINPUT_GAMEPAD_LEFT_THUMB
XINPUT_GAMEPAD_RIGHT_THUMB
XINPUT_GAMEPAD_LEFT_SHOULDER
XINPUT_GAMEPAD_RIGHT_SHOULDER
XINPUT_GAMEPAD_A
XINPUT_GAMEPAD_B
XINPUT_GAMEPAD_X
XINPUT_GAMEPAD_Y
Axis:
LeftTrigger
RightTrigger
ThumbLX
ThumbLY
ThumbRX
ThumbRY
Now in order for make use of it I'm thinking to expose arosx.library build in to the arosx.class.
API would mostly be a clone from Microsoft game controller API...
Only 4 gamepads and only one opener for the library... Or should it be per gamepad...
If anyone would like to make a better gui for it then I'd be pleased...
-
Dizzy: :D
Thanks man 8) Good to see you back. This is great news. Looking forward to try it out.
4 gamepads is enough.
-
Hi,
Sorry for the slow pace... Had so much other things ahead.
I compiled that Prototype for Linux (https://amigaworld.net/modules/news/article.php?storyid=8312) Might be a good candidate for testing the gamepad thingy. Not sure if I'm able to compile it to AROS on the build system.
Here's a link for the arosx.class (i386-AbiV1) https://www.dropbox.com/s/lzqudemy8wjanes/arosx.class?dl=0 (https://www.dropbox.com/s/lzqudemy8wjanes/arosx.class?dl=0)
-
Hi Dizzy. Prototype looks fantastic :D That would be something to have for AROS.
-
No stress Dizzy :D I'm just glad you are back. Tried the class now and seams to work great :) At least all buttons and direction + analog sticks responds :)
Will there be some kind of legacy support. Lowlevel?
edit: only thing I noticed is that the X is blinking in green all the time. Should normaly go to 1 right? Pressing the X button does nothing.
-
At the moment there is no limit on the number of controllers. They aren't even counted upon. Hence there is no led thingy going on. Home/logo button is not forwarded either, it's not in the Microsoft API.
-
Dizzy: I see. Thanks for the explenation :)
-
Hi. Any hope for an ABIv0 backport?
-
Hi. Any hope for an ABIv0 backport?
I don't see any problems for it running on ABIv0, nothing really special about the class in any way. I have not setup any ABIv0 build systems at the moment so I can't provide any test pieces for it.
I'm trying to build the Prototype game for AROS. I had GCC4.6.4 build on my build system, the Prototype code doesn't like it to be that old... I'll check some other games as I haven't got a glue which sort of interface would be most suitable. Event base system would be good, but I think most games just poll the inputs.
-
What about the plugin here.
It is for the PS1 emulator fpse. The emu source code is not available but the plugin source is there to play with.
I be happy to test but must be abi v.0
https://www.amidog.com/amiga/fpse/
-
What about the plugin here.
It is for the PS1 emulator fpse. The emu source code is not available but the plugin source is there to play with.
I be happy to test but must be abi v.0
https://www.amidog.com/amiga/fpse/
I'll see about the plugin once I get things going on better with the class. It's a bit early for backporting as the code at the moment doesn't actually do anything usefull.
I've limited the number of gamepads to four now and set the leds to lid according to the gamepad number.
I'll clean up the basic framework of the code so it will change quite a bit. Now the code is mostly just some code snippets here and there...
EDIT: I've cleaned the code a lot now, it should be easier for now to attach other library to it. It needs a bit more streamlining, I'll do a commit after that is done.
I'm not sure if I should provide the arosx_ll.library to substitute the lowlevel.library with hex editor on already compiled games. As Poseidon already patches the lowlevel I'm not sure how my patching would affect it.
EDIT: On HTML5 the gamepad API inhibits the discovery of controllers until one presses a button on the controller. This is to inhibit fingerprinting the machine, I don't think that is needed for us... ?
As the arosx Poseidon class now only setups gamepads, I think if there will ever come support for different kind of XInput controller, say a racing wheel, then I think they will get their own numbering so the four controller limit isn't for all xinput controllers but for controllers of the same kind... don't know...
-
Hi Dizzy. Thank you a lot for your work on this. Realy appreciated. On Morphos there is this lowlevel emulation using Xbox controllers to support classic. That would be nice for us to I think.
-
I've basicly now rewritten the whole thing... :o
I should have started a bit more object oriented way. Now there is the AROSXClass and it has AROSXClassController which in turn can be XInput gamepad. The arosx.library does nothing at the moment but now it is actually working (can be opened and closed...), it was just a quick copypastemonkeycode from the first thing I found on the AROS tree.
I've looked at a lot of game controller API's and they pretty much just poll the inputs, let's see what the arosx.library will house.
As the arosx.library is part of the arosx.class (just a different interface exposed to outside world) I'm thinking just to use arosx.class memory as if it belonged to arosx.library. Or pass around messages.
Maybe messaging is better suited... Don't know... For force feedback it might be beneficial to have a queue of ff-commands with duration and instant flush of the queue when needed.
Yesterday I tried to find how the battery information is passed on the USB, but my Windows machine is W7 and it has older xinput. Not sure if it provides such information. I installed vs2017 and got at least one example that polled the inputs and send ff commands to work.
For the Logitech F710 wireless gamepad arosx.class shows that it is wireless and when it goes to sleep mode and when it wakes, not sure if it will work the same with different wireless controllers.
-
This sound fantastic Dizzy. When you have it ready I will talk to the porter of Tower 57. That game realy requires analog pads.
Hope he will do a recompile for AROS version.
-
@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.
-
@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... ?
-
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!
(https://www.dropbox.com/s/8va7wmkuo2o17c9/XUSB.png?dl=1)
-
Dizzy: When can I test :) What fantastic work you are doing :)
-
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.
-
Great Dizzy. Have a great work week and looking forward to test it when ready :)
-
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.
-
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...