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 =)
And