Input and games.

[Todd Showalter]

On Sat, Apr 27, 2013 at 10:23 AM, nerdopolis
<bluescreen_avenger at verizon.net> wrote:

> What about rumblepads? How would the protocol control the rumblepad in some
> controllers?

    I think rumble is beyond the scope of the proposed gamepad
protocol.  The problem is that (at least in my experience) whereas
many controllers have some form of rumble, the actual physical rumble
hardware has very little in common between devices.  Some things have
linear motors, some have rotary motors.  Some have both.  Or multiples
of one or the other.  Some (like the wiimote, IIRC) aren't actually
rumble per se, and are actually a speaker you stream sound to at low
bit rates.

    The other problem (at least to me) is that rumble flows in the
opposite direction from input; in the gamepad protocol I'm proposing,
all the data is flowing from the hardware through the server to the
application.  Rumble runs the other way.  Rumble in general is far
more akin to sound playback than it is to input; you're basically
feeding a control stream to an actuator.

    Beyond that, at least with some gamepads, the rumble hardware is
subject to restrictions; in particular, at least one bit of kit I've
worked with that's still in circulation doesn't get enough power over
the controller cable to run all of the rumble motors at the same time,
and if you turn too much on the board-level logic in the gamepad can
start acting wonky.

    So, the short version of my answer is (1) I think rumble is a
totally different problem domain that wants its own protocol, and (2)
I'm not sure there's enough commonality or sanity in rumble hardware
to build a useful protocol.

                                       Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.