Sdl2 haptics

My xbox360 controller came today, so I gave it a whirl. The haptics
work, as in, SDL_HapticRumblePlay() makes the device vibrate; it just
doesn’t STOP.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

As a recap, with directinput device that has worked on a game;
SDL_NumHaptics() says 1.
SDL_JoystickIsHaptic() says 1.
SDL_HapticOpenFromJoystick() says NULL.
SDL_HapticOpen(0) returns a pointer, but the device doesn’t vibrate with it.

Trace:
SDL_SYS_HapticOpenFromJoystick
SDL_SYS_HapticOpenFromDevice8
IDirectInputDevice8_
SetCooperativeLevel fails
ret 0x800700aa The requested resource is in use. HRESULT

As to the xinput politics, I think the hardcoded buttons are worth it
if you don’t need to configure inputs in a game, and the game can show
the actual button that you should push instead of “BUTTON 7”… =)

I believe I’m having the same bug but on Linux:

2013/7/16 Jari Komppa <jari.komppa at gmail.com>:> My xbox360 controller came today, so I gave it a whirl. The haptics

work, as in, SDL_HapticRumblePlay() makes the device vibrate; it just
doesn’t STOP.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

As a recap, with directinput device that has worked on a game;
SDL_NumHaptics() says 1.
SDL_JoystickIsHaptic() says 1.
SDL_HapticOpenFromJoystick() says NULL.
SDL_HapticOpen(0) returns a pointer, but the device doesn’t vibrate with it.

Trace:
SDL_SYS_HapticOpenFromJoystick
SDL_SYS_HapticOpenFromDevice8
IDirectInputDevice8_
SetCooperativeLevel fails
ret 0x800700aa The requested resource is in use. HRESULT

As to the xinput politics, I think the hardcoded buttons are worth it
if you don’t need to configure inputs in a game, and the game can show
the actual button that you should push instead of “BUTTON 7”… =)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Nevermind, they are actually different bugs.

2013/7/16 Leszek Godlewski <@Leszek_Godlewski>:> I believe I’m having the same bug but on Linux:

X360 controller does not stop rumbling when stopped without a delay · Issue #922 · libsdl-org/SDL · GitHub

2013/7/16 Jari Komppa <jari.komppa at gmail.com>:

My xbox360 controller came today, so I gave it a whirl. The haptics
work, as in, SDL_HapticRumblePlay() makes the device vibrate; it just
doesn’t STOP.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

As a recap, with directinput device that has worked on a game;
SDL_NumHaptics() says 1.
SDL_JoystickIsHaptic() says 1.
SDL_HapticOpenFromJoystick() says NULL.
SDL_HapticOpen(0) returns a pointer, but the device doesn’t vibrate with it.

Trace:
SDL_SYS_HapticOpenFromJoystick
SDL_SYS_HapticOpenFromDevice8
IDirectInputDevice8_
SetCooperativeLevel fails
ret 0x800700aa The requested resource is in use. HRESULT

As to the xinput politics, I think the hardcoded buttons are worth it
if you don’t need to configure inputs in a game, and the game can show
the actual button that you should push instead of “BUTTON 7”… =)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/7/16, Jari Komppa <jari.komppa at gmail.com>:

My xbox360 controller came today, so I gave it a whirl. The haptics
work, as in, SDL_HapticRumblePlay() makes the device vibrate; it just
doesn’t STOP.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

o.O Yeah, may want to consider reporting that to bugzilla, especially
now that there’s a bugfix sprint.

As to the xinput politics, I think the hardcoded buttons are worth it
if you don’t need to configure inputs in a game, and the game can show
the actual button that you should push instead of “BUTTON 7”… =)

Games that don’t let you change the controls are badly designed :confused: And
the button name thing could be easily solved by just retrieving the
name (though it’s true some drivers return ugly names).

The biggest problem is that it was an obvious attempt at further
lock-in. PCs aren’t consoles.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

o.O Yeah, may want to consider reporting that to bugzilla, especially
now that there’s a bugfix sprint.

I looked at the source code instead, and then dug up on how xinput’s
rumble works. It only lets you set the servo speeds. There’s no
effects or anything. So there’s a design decision, more than just a
bugfix, here: whether the xinput rumble should emulate the full haptic
interface, or if it’s the applications’ job.

If it’s the application’s job, then a new “stupid” rumble interface is
needed. If it’s SDL’s job, then there’s a lot of work to do: some kind
of “rumble mixer” and scheduler, etc.

As to the xinput politics, I think the hardcoded buttons are worth it
if you don’t need to configure inputs in a game, and the game can show
the actual button that you should push instead of “BUTTON 7”… =)

The biggest problem is that it was an obvious attempt at further
lock-in. PCs aren’t consoles.

I was about to argue the opposite, but then I dug up information on
the xinput and all that, and found that microsoft has crippled the
directinput support for their gamepad for no reason whatsoever, at
which point it became rather obvious…

But still. When PC joysticks were limited to one axis and a button,
they were more common. Then came directinput and a device explosion,
with various different joysticks and joypads and whatnot… but people
gravitated more and more to mouse and keyboard, except for maybe
flight sim enthusiasts (when did you last see a good new flight sim?)
or racing fans with their wheels and pedals.

Now that there’s one fixed, clear gamepad, players seem to get them,
and games support them too (and not just console ports, although there
are plenty of those). So maybe PC will start getting more game
controller love due to the lock-in attempt.

As one microsoft exec on a flight once told me, there are necessary
evils in the world…

2013/7/16, Jari Komppa <jari.komppa at gmail.com>:

I looked at the source code instead, and then dug up on how xinput’s
rumble works. It only lets you set the servo speeds. There’s no
effects or anything. So there’s a design decision, more than just a
bugfix, here: whether the xinput rumble should emulate the full haptic
interface, or if it’s the applications’ job.

If it’s the application’s job, then a new “stupid” rumble interface is
needed. If it’s SDL’s job, then there’s a lot of work to do: some kind
of “rumble mixer” and scheduler, etc.

If SDL is going to claim to support those effects by itself then
honestly SDL should attempt to recreate them whenever possible (though
I’ll be blunt and say I never understood the idea behind effects in
the first place…).

I guess in a game this isn’t much of an issue anyway since the rumble
setting would change every frame anyway.

But still. When PC joysticks were limited to one axis and a button,
they were more common. Then came directinput and a device explosion,
with various different joysticks and joypads and whatnot… but people
gravitated more and more to mouse and keyboard, except for maybe
flight sim enthusiasts (when did you last see a good new flight sim?)
or racing fans with their wheels and pedals.

Joysticks weren’t common back then, and in fact they weren’t until
recently (and even then still most PCs lack controllers), early
joysticks had a dedicated port and many PCs lacked them, to the point
the Sound Blaster had to include a joystick port on its own.

Now that there’s one fixed, clear gamepad, players seem to get them,
and games support them too (and not just console ports, although there
are plenty of those). So maybe PC will start getting more game
controller love due to the lock-in attempt.

From what I gather, it requires its own proprietary protocol (rather
than using the protocol specified in the USB standard), and I’m not
sure if you’re allowed to use it without paying them a license or
something like that. If that isn’t lock-in, then I don’t know what it
is.

And my point is that they also prevented any expansion from ever
happening. Let’s say for example that somebody comes up with a
controller with relative axes (which can be used to e.g. gimmick
mouselook or something like that), how do you get that to work with
Microsoft’s API?

This is a bug with our current Windows XInput haptic code (XInput
doesn’t offer an API for running the motors for a certain time, but
rather wants you to turn it off yourself).

We should really fix this for 2.0.0…maybe check if it’s time to turn
off the motors during PumpEvents or spin a thread for it or something.

–ryan.On 07/16/2013 02:57 AM, Jari Komppa wrote:

My xbox360 controller came today, so I gave it a whirl. The haptics
work, as in, SDL_HapticRumblePlay() makes the device vibrate; it just
doesn’t STOP.

The amplitude parameter works, but the length parameter doesn’t do
anything. The effect just starts playing and doesn’t stop. I can use
SDL_HapticRumbleStop() to stop it, but that’s a lot of hassle.

So there’s a design decision, more than just a
bugfix, here: whether the xinput rumble should emulate the full haptic
interface, or if it’s the applications’ job.

The problem is that I don’t know how to emulate it…most haptic
things work just like the X360 controller, I’ve been told: two motors
that have different frequencies, that you can run at different speeds.
The problem is that XInput doesn’t supply any effects, you can just
specify power levels for the two motors at any given time. Presumably
all the other devices that use these effects through DirectInput work
the same way, it’s just something else managing the motors (the driver?
The hardware itself?).

Ethan Lee had a smart solution: add a new SDL effect that just lets you
control the motors separately, and expose it for XInput controllers (and
let SDL_HapticRumblePlay() use it if the device doesn’t expose a “Sine”
effect). This isn’t a bad idea, since most of the games that are getting
ported talk to XInput directly, and just want to map that functionality.
The problem? We’re out of bits for new effects, since we used a UInt16,
so it’ll have to wait for 2.1 or whatever.

If SDL is going to claim to support those effects by itself then
honestly SDL should attempt to recreate them whenever possible (though
I’ll be blunt and say I never understood the idea behind effects in
the first place…).

A lot of people can’t feel the difference between any of the effects.
It’s all just vibration to them.

At any rate, if someone finds me some docs on the math behind the
various effects we support, we can totally enable them all with the
XInput API by managing the motors ourselves behind the scenes.

–ryan.

If it’s the application’s job, then a new “stupid” rumble interface is
needed. If it’s SDL’s job, then there’s a lot of work to do: some kind
of “rumble mixer” and scheduler, etc.

If SDL is going to claim to support those effects by itself then
honestly SDL should attempt to recreate them whenever possible (though
I’ll be blunt and say I never understood the idea behind effects in
the first place…).

Haptics and audio are relatively similar. The “effects” are like
sample-based sound effects that you trigger to play. On the other
hand, if you want to simulate a racing game, you modify the audio all
the time, as well as modifying the haptic response based on the
roughness of the road or whatnot.

So yeah, there’s some point.

Let’s say you have a shooter where your controller vibrates a little
every time you shoot, you get a long light vibration from picking up a
powerup and a harsh spike when you get hit. All of these may overlap.
Like with audio, you need a mixer to solve this. Unlike with audio,
where you can just buffer things up and toss to the sound card, these
need to be changed in real time. Luckily you only need ~1ms
resolution, probably can get away with ~10ms.

I guess in a game this isn’t much of an issue anyway since the rumble
setting would change every frame anyway.

Could. Not would. I’d rather not write that kind of “rumble mixer” for
a game if I can get the “effect” support from SDL. And I’d need to
fudge it anyhow to work with directinput somehow. And, if SDL
changes and suddenly gives that effect support, my work would a) be
pointless and b) very likely break.

But still. When PC joysticks were limited to one axis and a button,
they were more common. Then came directinput and a device explosion,
with various different joysticks and joypads and whatnot… but people
gravitated more and more to mouse and keyboard, except for maybe
flight sim enthusiasts (when did you last see a good new flight sim?)
or racing fans with their wheels and pedals.

Joysticks weren’t common back then, and in fact they weren’t until
recently (and even then still most PCs lack controllers), early
joysticks had a dedicated port and many PCs lacked them, to the point
the Sound Blaster had to include a joystick port on its own.

Most sound cards came with joystick ports back then. And if you were
gaming, your priority would be to get a soundcard, not a joystick
first. =)

Now that there’s one fixed, clear gamepad, players seem to get them,
and games support them too (and not just console ports, although there
are plenty of those). So maybe PC will start getting more game
controller love due to the lock-in attempt.

From what I gather, it requires its own proprietary protocol (rather
than using the protocol specified in the USB standard), and I’m not
sure if you’re allowed to use it without paying them a license or
something like that. If that isn’t lock-in, then I don’t know what it
is.

Ick. Okay, that’s bad. From a hardware vendor point of view. From
player’s point of view, however, it appears to be better. And from a
game developer’s point of view, well, if you develop your controls for
one specific gamepad, the gameplay is likely to be better.

Anyway, we’re going circles here. You say it’s all bad, I say it’s
bad, but there are good side-effects.

And my point is that they also prevented any expansion from ever
happening. Let’s say for example that somebody comes up with a
controller with relative axes (which can be used to e.g. gimmick
mouselook or something like that), how do you get that to work with
Microsoft’s API?

DirectInput is also Microsoft’s API =)