Re: [AD] Haptics

[ Thread Index | Date Index | More Archives ]

Hi Trent,

First of all I'm glad you finally got down to looking at what I made last year, and I think your criticism is fair enough. I'll try to answer your questions point by point, then we can decide what to do with the API as it currently is.

Op 29-05-15 20:54, Trent Gamblin schreef:
I'm writing a complete Lua binding for 5.1 so I'm going over the entire
API. One thing that stands out is haptics. The API appears to be a thin
layer over Linux kernel API. That means it's horrendous to actually use
because it was never intended to be used directly. With all of the other
APIs we sat down and thought of ways to make the interface useful, easy
and simple but not with haptics. I'm proposing that we do a reboot of
the haptics interface or at least consider some friendlier alternatives.
When I look at it and try to actually implement a haptic effect without
studying the code I want to punch my monitor because it's impossible,
particularly the documentation for ALLEGRO_HAPTIC_EFFECT.

I admit that the API is a thin layer over the Linux API. The thing is though, the Linux haptic API, the Windows DirectX haptic API, and one of the two (yes two) OSX haptic API's all work very similarly, and support the same effects (at kleast in theory). Only some OS-specific and API specific details differ. These three APIs offer the widest range of effects. SDL2 also uses a very similar API for the same reason. The abstraction I implemented in very thin because it is a widely supported abstraction.

There are many problems, though. annoyingly, /no hardware maker/ has bothered to implement drivers for the more complete OSX hapics API, so it's generally a dead duck. That's why it's not implemented. Windows now has the newer Xinput API which only supports two motor vibrational effects. DirectInput is now considered as deprecated. OSX has a similar newer joystick and haptics API with a similar restriction of only two motor vibrations. Smarthphones generally only support vibrations. That leaves desktop Linux as the only platform where full-featured haptics support is not deprecated.

Arguably, we could drop the whole ream of effects and implement only a single active two-motor vibration effect. I didn't choose for that option at the time because I wanted allegro 5 to be feature-competitive with SDL2, but maybe, seeing he deplorable state of joystick and haptic support nowadays, it might be wiser to only support haptic effects that actually have a chance to work over all platforms?

I agree the documentation is unclear at some points, due to my surgery, lack of time, and inability to test the more intricate effects and document what exactly happens when you use them. I was forced to document going by the underlying API's documentation.

Op 29-05-15 21:34, Trent Gamblin schreef:
Or at the least some of the errors and inconsistencies in the docs/API
should be fixed. At first read I noticed:

ALLEGRO_HAPTIC_EFFECT: this is very difficult to follow. Should include
the declaration of the struct in the documentation.
Yes it's hard because there are so many different effects in the full-featured API's.

"replay" field in ALLEGRO_HAPTIC_EFFECT: name suggests playing twice or
more but documentation suggests otherwise.
Yes, that's a poorly chosen name, likey cribbed from SDL or from the Linux API.

al_release_haptic and al_release_haptic_effect: In Allegro we use
destroy which I assume is what these do. They also return bool but
that's not mentioned in the documentation. Destroy functions should
never return bool generally.

Actually they don't destroy anything. Memory is managed fully but the haptic system, except for the custom haptic effect which should be handled by the user of the library. It's academic though since custom haptic effects don't work at all on most systems or joysticks. There's a hardware-imposed amount of haptic effects that can play at the same time, and the current API reflects that. When you create a haptic effect you take up one of the effect solts, and when you release it, ypou free that slot. But the slot itself isn't destroyed, hence the inconsistent name.

al_get_haptic_active: I'd prefer al_is_haptic_active like the rest.
Yes, that makes sense.

Op 29-05-15 21:43, Trent Gamblin schreef:

Now I'm curious. Does al_release_haptic_effect free the memory? If so
does data.periodic.custom_data get freed and how?
No it doesn't. As I said, you need to do that yourself if needed, but custom effects don't work due to lack of hardware support so the question is academic.

Op 29-05-15 21:47, Trent Gamblin schreef:

Also not having XInput support ensures that, what, 75% of people can't
use haptics so therefore there's strong reason not to use it at all. I
might be willing to write a driver if we can clean up the API.
Actually that's a mistake in the documentation. Check out the source code, there is a new XInput joystick and haptics driver that gets selected automagically when you plug in an XInput enabled device switched to XInput mode. You probably forgot, but actually helped me to debug it. :)

So I hope that answers some of your questions , feel free to ask more. Joystick support is iffy nowadays, and haptics are even weirder. The question for us is, what will we do? Trim down the API radically to simplify it, or clean up the current one and document it better? As long as my sticks vibrate, I'm happy to discuss any and all ideas.

Kind regards,


Mail converted by MHonArc 2.6.19+