Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...

Browsing this Thread:   1 Anonymous Users



(1) 2 »


Controller

Joined:
2007/4/16 6:26
From Norway
Group:
Member
Posts: 4026
Offline
With a new great game ported to AROS, Tower57 I'm in talk with the developer about our joystick, controller support.

This is from Daniel:

But as far as I can see there is no library / API to query a complex dual-stick's multiple axis like in AOS4 and MorphOS, I only found the good old low-level stuff in AROS (which is only good for old-school joysticks).

I can tell from trident that all the buttons on my pad work (12) when I track incomming signals and both pads also report everything to trident so I guess it is a matter of adding this to a library and we could have this supported?

For other Amiga platforms they have this:

AmigaInput on AOS4 and sensors.library on MorphOS

Could we steal Qjoypad from Linux.

https://askubuntu.com/questions/140617/how-do-i-use-a-gamepad

Input device ID: bus 0x3 vendor 0x45e product 0x7 version 0x100
Input device name: "Microsoft® Microsoft® SideWinder® Game Pad USB"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_A)
Event code 305 (BTN_B)
Event code 306 (BTN_C)
Event code 307 (BTN_X)
Event code 308 (BTN_Y)
Event code 309 (BTN_Z)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 312 (BTN_TL2)
Event code 313 (BTN_TR2)
The button order here reflects that in qjoypad, so qjoypad's button 1 is BTN_A on the controller, etc.


Posted on: 3/16 11:53

Edited by nikolaos on 2018/3/16 12:14:25
Edited by nikolaos on 2018/3/16 12:15:03
_________________
www.aspireos.com
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
HID class patches the lowlevel library and from Trident one can map the joystick movements to it, I think...

https://youtu.be/OKaW19B7wnc

Found also this, http://aros-exec.org/modules/newbb/vi ... t_id=57903#forumpost57903

Nothing happened since the first post on 2011/7/26 :)

Posted on: 4/19 6:58
Transfer the post to other applications Transfer


Re: Controller

Joined:
2007/4/16 6:26
From Norway
Group:
Member
Posts: 4026
Offline
Dizzy: Daniel that did the Tower57 port added the option so we can use analogue hack. I can now use controller with all buttons and the 2 analog sticks that are essensial for that game.
It is for sure not the cleanest way to support dual analoge pads or many buttons and it would be welcome if someone did the needed code to implement this into AROS. From what I understood SDL can be used as reference since all the input, joypad code is there.

Posted on: 4/19 9:43
_________________
www.aspireos.com
Transfer the post to other applications Transfer


No Account
Re: Controller
Guest_No Account
Quote:

nikolaos wrote:
With a new great game ported to AROS, Tower57 I'm in talk with the developer about our joystick, controller support.

This is from Daniel:

But as far as I can see there is no library / API to query a complex dual-stick's multiple axis like in AOS4 and MorphOS, I only found the good old low-level stuff in AROS (which is only good for old-school joysticks).

I can tell from trident that all the buttons on my pad work (12) when I track incomming signals and both pads also report everything to trident so I guess it is a matter of adding this to a library and we could have this supported?

For other Amiga platforms they have this:

AmigaInput on AOS4 and sensors.library on MorphOS

Could we steal Qjoypad from Linux.

https://askubuntu.com/questions/140617/how-do-i-use-a-gamepad



It isnt quite as straight forward as you think to do cleanly/correctly.

Quote:

Input device ID: bus 0x3 vendor 0x45e product 0x7 version 0x100
Input device name: "Microsoft® Microsoft® SideWinder® Game Pad USB"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_A)
Event code 305 (BTN_B)
Event code 306 (BTN_C)
Event code 307 (BTN_X)
Event code 308 (BTN_Y)
Event code 309 (BTN_Z)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 312 (BTN_TL2)
Event code 313 (BTN_TR2)
The button order here reflects that in qjoypad, so qjoypad's button 1 is BTN_A on the controller, etc.




I would prefer a more permanent solution - this sounds too "quick fix"/ hacky.


IMHO we need 2 new components to compliment the existing and expose new features.


A> We need a new input (like) device that does the same kind of things as the existing input.device. It should be the place drivers register input controllers, and handles forwarding supported events to the existing input.device for legacy support. Lets call it hid.device for the time being.

* = we can copy/reuse a lot of the existing input device code for this and addapt it.

B> We need a new lowlevel.library that also deals with the new hid.device to communicate with controllers and provides a light weight api for devs to interact with the controllers. Again, it should forward supported events to the existing lowlevel.library for legacy support - but new code should use the new library instead. Lets call it inputdevice.library for now.

* = this probably needs a different api to the existing one.

So ..


The existing implementation has many shortcommings that we need to address in these new components.

# Theres no clean way for input devices (other than those that use the existing input.device) to register with the system in a unique way - which is why poseidon devices for instance all map to port 1 until configured manually. The hid.device needs to handle registration and allocate a suitable unique ID to use for each attached device.

# Theres no real way to query "what" is attached to the system currently - the library needs to provide a clean way to do this, and to find out the capabilities of any device.

Since AROS uses the hidd device API, it should be able to find out the hidd objects available representing the devices, then query those directly.

# Existing input is only handled via polling which is not very amigaos like (AmigaOS being event driven). The new library needs to provide a way for listeners (apps using the devices) to register event handlers and pump the events to them. lowlevel.library could register and have the events it needs pumped to it, then expose them for legacy apps using polling.

# New controllers have other features integrated (such as sound output, etc) - so it should be able to query the input devices hidd driver and find out what else it supports.

[edit]

Thinking about it a little more ...

# We may be able to proivide both using one implementation, and have just the device but with extra lib functions to its base exposing the "low-level" API for apps to enumerate, etc, the actual devices. This would allow for a smaller footprint overall and negate the need for glue between both.

# HumanInput would probably be a better base name if thats what it is meant to represent. Input.device would the the system level input, and HumanInput for real interactive devices used by a user.

# We should consider advanced input events that AROS/AmigaOS cant propely handle currently - like multi-touch, when implementing the API's

# It would be nice to provide a way for a listener to obtain exclusive access to a device, Instead of only having all events distributed globaly like input device/lowlevel currently do.

Posted on: 4/19 10:36

Edited by Kalamatee on 2018/4/19 11:05:17
Edited by Kalamatee on 2018/4/19 11:06:14
Edited by Kalamatee on 2018/4/19 11:23:13
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
We could make a gamepad "stack" that attaches to Poseidon PsdEventHook and goes through a list of supported game controllers and if it has one then claims the device for the "stack".

Common API would there after be used to communicate with the controller.

Now everything is in the hid.class but with that we should be able to bypass the hid.class claiming the device.

Posted on: 4/19 23:00
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

nikolaos wrote:
Dizzy: Daniel that did the Tower57 port added the option so we can use analogue hack. I can now use controller with all buttons and the 2 analog sticks that are essensial for that game.
It is for sure not the cleanest way to support dual analoge pads or many buttons and it would be welcome if someone did the needed code to implement this into AROS. From what I understood SDL can be used as reference since all the input, joypad code is there.


HID.class has had the lowlevel patch in it from day one on our repository. Haven't tried to map anything with the Trident though...

Posted on: 4/19 23:05
Transfer the post to other applications Transfer


Re: Controller

Joined:
2007/4/16 6:26
From Norway
Group:
Member
Posts: 4026
Offline
This is to advanced for me but Joystick, lowlevel port 1 with 2 button controller always worked. The problem been more advanced controllers with more buttons and 2 analogue pads. You can not map buttons or controllers without using the analogue hack is my understanding.

Posted on: 4/20 5:31
_________________
www.aspireos.com
Transfer the post to other applications Transfer


No Account
Re: Controller
Guest_No Account
Quote:

DizzyOfCRN wrote:
We could make a gamepad "stack" that attaches to Poseidon PsdEventHook and goes through a list of supported game controllers and if it has one then claims the device for the "stack".


I was thinking more the opposite. the usb hid.class would register a "hidd" driver representing the device with humaninput.device, which can be queried to determine what buttons are present etc. humaninput.device can broadcast events when a device is attached or removed, so that listeners can determine when to enumerate what is available to update in their own state.

If a driver (lets say a ps4 or xbox controller), exposed an audio device to push sound out of its headphone jack or integrated speaker ... we could expose that attachment via the usb objects hidd also. It would need to privde an ahi device representing the audio output. You would then either be able to choose to send audio via it using AHI - or if a e.g game supported such functionality, it can determine the ahi device for the controller via the enumerated hidd object ... and pump certain sounds specifially for that controller/user

Quote:

Common API would there after be used to communicate with the controller.

Now everything is in the hid.class but with that we should be able to bypass the hid.class claiming the device.



I would like that the usb hid class just maps the usb hid device to an object format that is generic for AROS to understand and use, and let AROS components manage the enumeration and actual usage/mapping of the functionality.

Posted on: 4/20 8:16
Transfer the post to other applications Transfer


No Account
Re: Controller
Guest_No Account
Quote:

nikolaos wrote:
This is to advanced for me but Joystick, lowlevel port 1 with 2 button controller always worked. The problem been more advanced controllers with more buttons and 2 analogue pads. You can not map buttons or controllers without using the analogue hack is my understanding.



Theres a few problems;


A> Theres not propper support for controllers with more than 2 buttons, more than one analogue input, other newer features


B> Theres no way to query what is available


C> theres no way for devices to automatically assign themselves to a unique port. everything just gets dumped on port 1.


D> You _must_ manually configure it all yourself in trident prefs presently. This is really un-user friendly and cryptic for those without prior knowledge.


E> Theres no amiga like event-driven way to get feedback from the controllers. It must be polled which is inefficient. Its also far less responsive for gamers.




Posted on: 4/20 8:21
Transfer the post to other applications Transfer


Re: Controller

Joined:
2008/2/5 6:58
From Sunny Finland
Group:
Member
Posts: 1026
Offline
Quote:

Kalamatee wrote:
Quote:

DizzyOfCRN wrote:
We could make a gamepad "stack" that attaches to Poseidon PsdEventHook and goes through a list of supported game controllers and if it has one then claims the device for the "stack".


I was thinking more the opposite. the usb hid.class would register a "hidd" driver representing the device with humaninput.device, which can be queried to determine what buttons are present etc. humaninput.device can broadcast events when a device is attached or removed, so that listeners can determine when to enumerate what is available to update in their own state.

If a driver (lets say a ps4 or xbox controller), exposed an audio device to push sound out of its headphone jack or integrated speaker ... we could expose that attachment via the usb objects hidd also. It would need to privde an ahi device representing the audio output. You would then either be able to choose to send audio via it using AHI - or if a e.g game supported such functionality, it can determine the ahi device for the controller via the enumerated hidd object ... and pump certain sounds specifially for that controller/user

Quote:

Common API would there after be used to communicate with the controller.

Now everything is in the hid.class but with that we should be able to bypass the hid.class claiming the device.



I would like that the usb hid class just maps the usb hid device to an object format that is generic for AROS to understand and use, and let AROS components manage the enumeration and actual usage/mapping of the functionality.


Well... The Poseidon's eventhook system doesn't allow one to claim a device or interface, I thought it could but no. The whole psdEventhook system isn't finished and was left half way done.

With Poseidon one can claim the whole device or just one(or more) of it's interfaces. If the humaninput.device would only use the interface for buttons etc. then some other class could use the audio interface. Not sure what the usbaudio.class is capable of at the moment, but that is meant for usb and audio.

Posted on: 4/20 11:18
Transfer the post to other applications Transfer



(1) 2 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4434
2 magorium
magorium
4095
3 nikolaos
nikolaos
4026
4 phoenixkonsole
phoenixkonsole
3929
5 deadwood
deadwood
2917
6 ncafferkey
ncafferkey
2796
7 mazze
mazze
2221
8 clusteruk
clusteruk
2112
9 damocles
damocles
1789
10 BSzili
BSzili
1513
© 2004-2018 AROS Exec