Last week, my girlfriend Amber and I headed to All Electronics. I didn't realize she'd never been before; she was freaking out. We managed to suppress most (but not all) of our impulse buys.
What we absolutely could not resist, though, was this joystick. It was a part without a project: we needed to use it in something... it had the same sound as using a Street Fighter machine. (As a side note, it never occurred to me to realize that those joysticks were just four limit switches whose combinations gave you eight different control messages. Tight.)
They were also having a massive sale on really robust tour cases. And they had the big "American-style" flashy arcade buttons (like you'd see on a MIDI Fighter) out on display. That was it: "Let's try to repackage our games from last year's expo as a self-contained unit, with an embedded LCD monitor, arcade controls and 5V cell-phone power."
That was my excuse for buying two Raspberry Pi Model Bs.
I had heard warnings from some of my friends that this project would probably not end with success: apparently, Processing (which hosts most of the engine for our video games) runs terribly on the Pi - ostensibly from getting choked through a JVM.
I've flirted with the idea of triple-booting my MacBook Pro with Ubuntu before in a flight of power-user nerdiness, but I've never actually tried it. I knew that OS X is essentially a hot-rodded UNIX file system, and that any Apple customer who's comfortable with talking to Darwin in Terminal probably shouldn't be afraid of any distro. And so, when I got the Pis two nights ago, I delved into Raspbian, and figuring out how to install Processing and ChucK on it.
I say "port" when I talk about the mouse, keyboard, OS X controller, Windows controller, Raspbian controller and Rail Bow versions of TD Skillz, but for the most part I just mean "HID object remappings."
ChucK has a great library object in it for HID devices. Like "hi" in Max, any joystick, racing wheel, or other weird peripheral can be identified as just a series of channels and values (usually 0 - 1). The strange thing is that for the same USB controller, different button presses (the "left" button, for instance) come up in totally different paths from operating system to operating system. So, each platform needs a new diagnostic test into the paths so that the source code downstream can be adjusted.
Raspbian's implementation was especially weird because it didn't even treat the D-Pad as button presses, it treated it like axial hat movement; as though they were two analog sticks with three possible values (-1, 0, and 1). So, this took a bit more of a rewrite in Processing than I expected, but it was still only a few minutes work.
Although it required spending several hours with the amazing "apt-get" feature of Linux quite intimately along the way (in getting ALSA/libsndfile/Bison/Flex/etc. etc.), the port worked "perfectly." Only problem is, it was awful. It was just as my friends said it was: unusably slow. Like, below one frame-per-second slow.
Oh well. I have two awesome cheap computers to run emulators and play with digital GPIO on in nice cases, now, anyway. I added the functional (if unusable) Raspbian port of TD Skillz to the GitHub repository, and the project page has likewise been updated.
Interested in getting your hands on a Raspberry Pi of your own? Visit element14 and pick one up.