[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers 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,
B.