Assembling Your Box

Continued from Building an Arcade-style Fight Stick

As I said, I won't cover much here, but I will go over some of the tools I used in my construction. A router and table saw will make the job much easier, but you can get by with just a drill, some specialized bits and a circular saw.

For the button holes, I used a 1 1/8" spade bit, purchased at the local hardware store for about $5. You can either lay your button layout sheet directly on the wood and drill through it, or you can just mark the centerpoints and save the layout for later use. The only things to remember with using the spade bit are to make sure you go in straight and be patient to avoid it getting bogged down or stuck.

For the joystick hole, I used a 2 1/4" hole saw attachment. Again, take your time lest you end up with a costly waste of wood due to a misplaced hole.

I recommend attaching your pieces using pegs made of dowel rod and wood glue, since that will be much sturdier (and nicer looking) than just a bunch of nails. If you're a master carpenter, go ahead and do a dovetail joint or anything else that will improve the strength of the box, since you'll be beating the hell out of it on a regular basis.

Page 1: Building an Arcade-style Fight Stick
Page 2: Assembling Your Box
Page 3: Pad Hacking
Page 4: Installing the Hardware
Page 5: Conclusions and Helpful Links

Building an Arcade-style Fight Stick

In anticipation of Capcom's release of Street Fighter 4 on the PC, I decided to build a 2-player arcade console, similar to those available from X-Arcade. There are many options and choices to be made in such a project, as well as dozens of pitfalls, so I thought I'd share my experience to help inform anyone else who wants to give it a shot.

Step 1: Defining Your Goals

This is a pretty intense project, so you'll want to have a good plan from the outset. It can be costly to change your mind halfway through, so make sure you've decided as much as you can before you even get started. Some things you have to decide:

A. Which platform(s) do you want your stick to be compatible with?

Are you strictly a PC/MAME gamer? If so, you will probably want an I-PAC interface, which will make your computer see your stick(s) as a keyboard that is then easily recognized and mapped within your software. This is similar to the approach taken by X-Arcade and other PC-only arcade sticks. These control units are a mainstay of the DIY MAME cabinet crowd.

If, however, you play on a console such as the XBox 360, you might prefer doing a "pad hack" whereby you connect your arcade buttons to the circuit board inside of a console controller. This is what I chose to do because it allows me to use my sticks on my PC *and* on my friends' XBox consoles (thanks to the XBox's use of USB for their controllers). This method is a little more intense than using an I-PAC because you'll need to have a steady hand and some experience with soldering, but it's not terribly tough if you take it slow and exercise some care.

B. Which hardware do you want to use?

When it comes to arcade hardware, one size does not fit all. There is incredible diversity among sticks and buttons that varies by manufacturer, region (Japan vs America) and games that are intended to be played. For example, many competitive Street Fighter players prefer (to put it mildly) Japanese-style sticks (especially Sanwa), while Pac Man pros usually opt for ball-top American-style sticks. Furthermore, Street Fighters usually choose Japanese-style buttons, which are convex and have a shorter throw compared with American-style buttons. I recommend doing your homework and clocking in some time with a few different sticks before you make your choice because it's totally up to individual preference.

I grew up using Happ bat-top sticks and Happ's clicky, concave buttons in the local arcade, so that's what I went with. I purchased them from Tornado Terry on eBay at a really great price.

C. What kind of button layout will you use?

The button layout is almost as personal and important as the hardware selection, so again, you'll want to do your homework and try out a few things before making any major moves. Some prominent stick-makers are using an eight-button layout with four buttons in two rows (as in the Mad Catz Tournament Edition stick), but I often get lost on this configuration and end up accidentally scooting over to the wrong buttons during the more heated moments.

Again, Japanese- and American-style button layouts differ, with Japanese-style layouts having a staggered positioning that mimics the way your fingers naturally fall, while American-style layouts are straight across.

Slagcoin.com has a pretty great collection of sample layouts that you can use or you can modify one of them to create a unique layout that's all your own, which is what I did:

(since I modified it, the measurements may not all be accurate, so you're probably better off printing it out and working directly with the template if you plan to use this one)

I went with a Japanese-style stagger because I find it to be more ergonomic. Additionally, since I emulate a lot of Neo Geo games, I wanted to have four buttons in one of the rows to recreate that feel but not on both rows to avoid confusion. This fourth button in the bottom row also works perfectly as the 'run' button in certain Mortal Kombat games.

D. What materials do you want to construct your stick out of?

This is where you can really put a visible, personal touch on your creation and make something that is instantly identifiable. Arcade sticks are pretty much just boxes that you screw things to, so you can build a box from scratch using high- or low-quality materials, or you can repurpose a box from somewhere else to give your stick a "found materials" kind of look. I won't delve too deeply into this aspect of the construction process since I'm a shitty carpenter and you can definitely find more complete and informative guides to box-building elsewhere online.

I wanted something large, sturdy and attractive enough to leave in my living room, so I opted for a combination of red oak top and two sides paired with high-quality plywood (from the 'project' section of Lowe's, not that splintery shit from the lumber section) for the bottom and other sides. I then stained it with a dark stain and covered it with several coats of shellac, which made it look like an antique piece of furniture.

It didn't turn out perfectly due to my aforementioned shitty carpentry skills, but it passed the wife test so it's good enough for me.

Page 1: Building an Arcade-style Fight Stick
Page 2: Assembling Your Box
Page 3: Pad Hacking
Page 4: Installing the Hardware
Page 5: Conclusions and Helpful Links

Choosing an HTPC Keyboard and Mouse

I have a home theater PC (HTPC) and have spent a lot of time trying to find an ideal means to control it. While there are a lot of options available on the market, almost all of them fall short in some area.

I have tried quite a few cordless peripherals that all used the standard RF interface via USB dongle. These devices utilize the already crowded 2.4 Ghz frequency band, which you may recognize as the same frequency used by Wifi, many cordless phones and baby monitors. All this interference from other devices means you will have a lot of problems with dropped signals, missed clicks, etc.

Furthermore, optical mice really suck to use on your lap, so I knew I would need something a little out-of-the-ordinary. I have tried a Gyration Air Mouse, which was really neat, but it used an RF dongle and suffered from the aforementioned signal dropouts. :-( Furthermore, the Air Mouse is a delicate piece of machinery with several gyroscopes inside that can get out of alignment if the device is dropped a few times, which is almost unavoidable if you place it on the arm of your couch or chair.

Based on these experiences, my requirements are: Bluetooth, integrated cursor control and Linux support (since I use Ubuntu for my media center). Now, you would think that this sort of thing would be easy to come by and that there would be hundreds of options to choose from among a variety of vendors, but this is simply not the case. In my experience, there are only two viable options: the Logitech Cordless MediaBoard Pro and the Logitech diNovo Mini.

While the diNovo Mini is very cool, it is expensive (approx. $120 at the writing of this review) and the keyboard is of a strangely awkward size that makes it slightly too large for thumb typing but far too small for touch-typing. Additionally, its trackpad thingie in the upper-right takes some getting used to. On the plus side, it's small enough to fit into couch-side storage along with regular TV remotes or even in your pocket. It also has an integrated, clamshell cover that nicely covers the keys when not in use.

However, the small keyboard and funky trackpad thingie make it unsatisfactory for general computing, such as Web browsing and typing, in my opinion.

In contrast, the MediaBoard Pro is much cheaper (approx. $60 currently), but it is marketed for the Playstation 3 rather than for standard PC use. Do not let this scare you away. It syncs fine with both Windows and Linux via the standard Bluetooth stacks with minimal fuss (notice: Logitech also makes a non-Pro MediaBoard that uses 2.4 Ghz RF; make sure you don't buy it on accident) and the PS3-specific media keys can be easily ignored or repurposed with key-mapping software.

The MediaBoard Pro is a full-sized keyboard with all of the keys you would expect, including F-keys, Del/Ins/Home/PgDwn/PgUp/End keys, etc. The only key that is missing is the Windows key, which has been replaced by dedicated keys for left- and right-clicking. It also has an integrated trackpad--similar to those found on most laptops--off to the right, where the keypad would normally be located.

I found the trackpad to be responsive, if a bit on the small side, and it has an area on the right side that is dedicated to scrolling (similar to the mouse wheel) and worked quite well without any configuring.

Some minor quibbles: this keyboard feels very light and somewhat cheaply made, but I guess that's what you get for $60. Also, it has a glossy black finish which looks really nice at first but attracts fingerprints and tiny scratches like nobody's business. Lastly, I have a feeling that the silver finish on the accents will quickly rub off, likely leaving an unsightly unfinished plastic instead.

All in all, I think the Logitech Cordless MediaBoard Pro is the best option for anyone who plans to do any actual computing (typing, navigating, Web browsing, etc.) with their HTPC. If you intend to use a media frontend, such as MythTV or XBMC, the diNovo Mini might be a better fit, since it feels more like a conventional remote and those interfaces do not require as much mouse/keyboard action.

Monitoring a Directory to Automatically Invoke HandBrake

I've seen this question pop up a lot on HandBrake's forums and IRC channel, so I thought I'd make an entry about it here (Mac users skip down to the bottom for your directions):

Many folks have expressed interest in being able to specify a directory for HandBrake to 'watch' for new files that it would then automatically attempt to convert with predefined settings. I think most people are wanting this for use with devices, such as iPods, PS3s and AppleTVs, which require specific settings for videos to work. While HB doesn't support this functionality on its own (and the devs don't sound too interested in adding it), you can accomplish much the same thing in Ubuntu Linux using HandBrakeCLI and a little shell scripting.
WARNING: I'm a novice at scripting and there is definitely a more effective and elegant way of doing this. If you have a suggestion, please leave a comment! Similar steps will also work on other platforms/distros, so feel free to leave a comment about your successes or failures.

First, we'll need to install a utility to enable monitoring of directories:

sudo aptitude install inotify-tools

Next, we'll make some new directories in our home folder to hold our scripts and conversions. In a terminal, type:

cd $HOME ; mkdir HandBrake ; mkdir HandBrake/convert

Navigate to the newly created HandBrake directory:

cd HandBrake

and type:

gedit monitor.sh

This is where we'll write our script to monitor the 'convert' directory and invoke another script to do the actual conversion:

#!/bin/bash

inotifywait --monitor -e moved_to -e create ~/HandBrake/convert | while read dir;
do
(~/HandBrake/convert.sh)

done

Save, exit and--again--type:

gedit convert.sh

Here we will create our conversion script (be sure to put your desired file extension and preset in place instead of the bracketed reminders):

#!/bin/bash
for file in ~/HandBrake/convert/*
do HandBrakeCLI -v -i "$file" -o "$file".converted.[FILE-EXTENSION-GOES-HERE] --preset [PRESET-NAME-GOES-HERE] ;

#uncomment next line to delete original
#rm $file

done

Save and exit, then type:

chmod +x *.sh

to make both scripts executable.

Now, you can start monitoring by typing:

sh ~/HandBrake/monitor.sh

or you can set the script to run as a startup item where it will run continuously in the background starting the next time you log on.

Henceforth, any file you move or copy into the 'convert' directory will automatically convert to the desired format. This script will only work on one file at a time (i.e., you have to wait for the encoding to finish before dropping in the next file to convert). Also of note: HB will choke if the file is weird in any way--e.g. no audio track--and you'll have no way of knowing it if the script is running in the background, since it won't print any output.

Good luck and let me know if you run into any problems.

Bulk Encoding on Macs

Update (06/01/09): There's been a lot of clamoring on the Mac board of the HandBrake forums asking for bulk input of files to be converted using a preset. The devs have no interest in adding such a feature at this time because of the tremendous support headache it could cause, but you Mac users can do scripting to accomplish the same thing.

Just like the Linux users, open a Terminal (Applications > Utilities > Terminal) and type:

cd Desktop ; nano convert.sh

then paste in this (shift+ctrl+v; be sure to put your desired file extension and preset in place instead of the bracketed reminders):

#!/bin/bash
for file in ./*
do ./HandBrakeCLI -v -i "$file" -o "$file".converted.[FILE-EXTENSION-GOES-HERE] --preset [PRESET-NAME-GOES-HERE] ;

#uncomment next line to delete original
#rm $file

done

Save and exit (ctrl+x), then type:

chmod +x *.sh

to make the script executable. Now, just put the script into a folder with your HandBrakeCLI binary and you should be able to invoke the script (navigate to its directory in the Terminal by typing cd [space after cd] and then dragging your conversion folder onto the Terminal window and hit 'Enter,' then type ./convert.sh) and automatically convert any files within the directory using the chosen preset. I would recommend just keeping a folder around that you use for conversions and keep the script and HandBrakeCLI binary in there at all times, then you can just drop in the files you want to convert, start the script and go along your merry way.

UPDATE (12/20/2013): An anonymous reader shared his script, which sounds much more robust than mine:

inotifywait -r --monitor --quiet -e moved_to -e close_write --format '%w%f' /mnt/public/convert/video/android-hq/ | while read -r FILE; do echo "File copy detected" echo "Starting HandBrake..." (sleep 15 && /usr/bin/HandBrakeCLI -v -i "$FILE" -o /mnt/public/convert/output/video/"$(echo "$FILE" | cut -c38- | rev | cut -c4-| rev)android-hq.mkv" -e x264 -x weightp=0:cabac=0 -b 650 --audio 1 --aencoder faac --ab 96 --mixdown stereo --gain 3 --width 720 --loose-crop --decomb --markers --turbo --two-pass --vfr --subtitle 1 --native-language eng && sleep 15 && rm -rf "$FILE")& done

UPDATE (9/27/2014):The same user (name is teeedubb, apparently) is back with an update. This was posted in the comments but got mangled, so I tried to piece it back together:

I'm back - I have revisited the above script because it had some glaring faults - it would start a handbrakecli process for each file, which when encoding a seasons worth of tv shows it would bring my pc to its knees, it didnt handle files in sub directories, didnt handle multiple profiles and probably would have given undesirable results if a file extension had more than 3 character, plus it was kinda messy. New version below solves these issues: It queues encodes using task-spooler (tsp package in ubuntu), works with sub-directories in the watch folder (and deletes any empty subdirectories within watch folders) and supports multiple profiles. Options are 'watch directory', 'output directory' and 'task-spooler slots' (concurrent jobs) which are set through the variables. You can set multiple handbrake profiles which the script uses based on which directory the files are copied into, if files are copied into the root watch directory the first profile is used. Options for profiles are: 'name', profile name which will be appended to the transcoded file (this needs to match the profile directory and be fairly unique - script searches the input file location for profile name, so a profile called 'android' could confuse the script when transcoding the movie 'android cop'), 'handbrake settings', settings for handbrake to use (I'm pretty sure you could use --preset XXXX here as well), 'file extension', file extension for handbrake to use on output file and 'delete source file', whether or not to delete the source video file. You can create extra profiles by adding variables beginning with PRESET2 etc and adding elif entries to the if/then statement in the script. By default the script attempts to delete any empty subdirectories *and its ancestors* when completing a transcode, so you need to ensure you profile directories are not empty - I have done this by creating a hidden file in each profile dir and making the file un-deletable (eg: profile1 dir is /mnt/public/convert/video/android-hq, run the command touch /mnt/public/convert/video/android-hq/.android-hq && sudo chattr +i /mnt/public/convert/video/android-hq/.android-hq).

and here's the script:

#!/bin/bash
#script to watch a directory for incoming files and pass them onto HandBrakeCLI

WATCH_DIR="/mnt/public/convert/video/"
OUTPUT_DIR="/mnt/public/convert/output/video/"
TASK_SPOOLER_SLOTS=2

##HANDBRAKE PROFILE 1
PRESET1_NAME="android-hq"
PRESET1_HANDBRAKE_SETTINGS=" -e x264 -x weightp=0:cabac=0 -b 650 --audio 1 --aencoder faac --ab 96 --mixdown stereo --gain 3 --width 720 --loose-crop --decomb --markers --turbo --two-pass --vfr --subtitle 1 --native-language eng"
PRESET1_FILE_TYPE="mkv"
PRESET1_DELETE_SOURCE="yes"

###########################

ts -S $TASK_SPOOLER_SLOTS
inotifywait --recursive --monitor --quiet -e moved_to -e close_write --format '%w%f' "$WATCH_DIR" | while read -r INPUT_FILE; do

PRESET_NAME="$PRESET1_NAME"
HANDBRAKE_SETTINGS="$PRESET1_HANDBRAKE_SETTINGS"
FILE_TYPE="$PRESET1_FILE_TYPE"
DELETE_SOURCE="$PRESET1_DELETE_SOURCE"

if [[ $(echo "$WATCH_DIR" | grep -i "$PRESET1_NAME") ]] ; then
PRESET_NAME="$PRESET1_NAME"
HANDBRAKE_SETTINGS="$PRESET1_HANDBRAKE_SETTINGS"
FILE_TYPE="$PRESET1_FILE_TYPE"
DELETE_SOURCE="$PRESET1_DELETE_SOURCE"
fi
FULL_FILE_NAME=$(echo ${INPUT_FILE##*/})
OUTPUT_FILE=$(echo ${FULL_FILE_NAME%.*})
tsp bash -c 'nice -n 19 /usr/bin/HandBrakeCLI -v -i "$0" -o "$1""$2"-"$3"."$4" "$5" && if [[ "$6" = yes ]] ; then sleep 15 ; rm -f "$0" ; fi ; rmdir -p "$(dirname "$0")"' "$INPUT_FILE" "$OUTPUT_DIR" "$OUTPUT_FILE" "$PRESET_NAME" "$FILE_TYPE" "$HANDBRAKE_SETTINGS" "$DELETE_SOURCE"
done

My PPA Repository for Filthy Pants (HandBrake Repository)

After much more time and effort than I care to admit, I finally got Canonical's build servers to successfully build deb binaries for HandBrake in my PPA repository.

From here on out, I will no longer distribute packages through Rapidshare, which some people didn't like, and will exclusively use the PPA repository. I will regularly build development packages of HandBrake with both the GTK and QT4 GUIs (the CLI version will also be included with the GTK package).

To access my PPA repository through apt (so updates happen properly and so forth), hop on a terminal and type:

sudo gedit /etc/apt/sources.list

and add these lines at the bottom:

#Filthy Pants PPA
deb http://ppa.launchpad.net/hunter-kaller/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/hunter-kaller/ppa/ubuntu jaunty main

Save and close, then type:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0x065fda2d23cfea71e753d04703e1fe8b2796dec2

After that, type:

sudo aptitude update

and you're all set.

Ubuntu 9.04 Jaunty Jackalope on Acer Aspire One

If you use Ubuntu 9.10 Karmic Koala, please read this first (thanks Pjotr!):

In 9.10 Karmic Koala, there's the same problem with acer_wmi as in 9.04.

However, your 9.04 fix causes instability in the kernel, in 9.10. That's because the blacklisting should be done by editing the existing /etc/modprobe.d/blacklist.conf. And not by creating a new file named blacklist.

Blacklist.conf by default already contains a list of blacklisted kernel modules. You can simply add the following lines for acer_wmi:

# switch the wireless chipset on
blacklist acer_wmi

Original Post:
The new kernel in the beta release of Ubuntu 9.04 Jaunty Jackalope provides better support for netbook hardware including that of my Acer Aspire One, but it still has a few wrinkles that are fairly simple to iron out.

The first thing you're likely to notice is that the wireless connection doesn't work correctly out of the box. It should automatically load the open source ath5k driver and give you the option of using the proprietary madwifi driver (unnecessary in my experience), but you will get no signal and network-manager will have all of the options grayed-out/disabled.

To fix this, hop onto a terminal and type:

sudo gedit /etc/modprobe.d/blacklist

and add the line

blacklist acer_wmi

This should fix your wifi access (and possibly fix your wireless indicator LEDs[!]) in one fell swoop, once you restart.

Next, there is a known issue with the SD card readers stemming from Jaunty's version of the Linux kernel that causes the left reader to fail with this error:

mmc0: error -84 whilst initialising SD card

The left-side SD reader is otherwise not acknowledged, i.e. it doesn't create a /dev/ entry when cards are inserted and hotplug doesn't mount the disk (this problem also exists on the Dell Mini 9, so you guys can benefit from this too). To correct the situation, type into a terminal:

sudo gedit /etc/modprobe.d/options

and add (be wary of line breaks; I recommend copy/pasting instead of manually typing):

options sdhci debug_quirks=1

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: linux-image-2.6.28-6-generic 2.6.28-6.17
ProcCmdLine: User Name=UUID=e309fb14-05db-4e9a-b137-c6bf63eeb6a4 ro quiet splash elevator=noop
ProcEnviron:
SHELL=/bin/bash
LANG=it_IT.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-6.17-generic
SourcePackage: linux

Reboot and most everything should work properly, hotplugging and all. Also to be aware of, the right-side reader does not work properly if there is not a card in it at boot. In this case, it won't show any trace anywhere that you even have a right-side reader.

For both of these fixes, all we've done is created a text file that the system loads as it boots. If you wish to undo these fixes, you can just delete the text files and it'll go back to normal.

Finally, ctrl+alt+backspace doesn't kill the xserver anymore in Jaunty because people were apparently pressing it accidentally...? You can supposedly re-enable it (if you like) by installing a program called dontzap:

sudo aptitude install dontzap

and then typing into a terminal:

sudo dontzap --disable

Unfortunately, this did absolutely nothing on my system. Maybe you'll have better luck. In the meantime, you can either restart your entire system, or hit ctrl+alt+F1 to drop down to a console and type:

sudo /etc/inti.d/gdm restart

A scary blue and red error screen will pop up notifying you that there's already an xserver running, to which you can just hit OK and it will restart with the new one.

I've been using the netbook remix, which is really attractive and easy to use. Its launcher menu is incompatible with Compiz-fusion, but it looks nice enough that I don't even miss compositing.

Also of note, suspend actually seems to work now instead of totally borking my system, and the integrated mic/webcam seem to work much more reliably now.

Let me know if you have any issues and I'll try to help resolve them.

New Directions for Building HandBrake SVN

Update (5/15/09): I have working binaries available in my PPA repository. Directions for adding it to your package manager are available here.

A couple of months ago, the HandBrake devs implemented some major changes to the build procedure for HandBrake from the project's SVN repository. I'm not really sure why they did this, but it seems to have cut a couple of dependencies, which is nice*. Here's the new method that worked for me on Ubuntu 8.10 Intrepid Ibex and 9.04 Jaunty Jackalope (adapted from their build instructions in the readme).

Step 1: download the dependencies
In a terminal, type:

sudo aptitude install subversion build-essential m4 wget autotools-dev yasm autoconf intltool libtool libbz2-dev zlib1g-dev libglib2.0-dev libdbus-glib-1-dev libgtk2.0-dev libhal-dev libhal-storage-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev automake1.9 libnotify-dev libwebkit-dev

Update (6/18/09): as of svn 2550, libgtkhtml-3.14-dev was replaced by libwebkit-dev.
Users of OpenSuSE may need to download the additional dependencies zypper and in to build the CLI, as well as gtkhml2 and gtkhtml2-devel to build the GUI. Users of Red Hat/Fedora or derivatives may need to install the package groups "Development Tools," "Development Libraries," "X Software Development," and "GNOME Software Development," as well as zlib-devel, bzip2-devel, dbus-glib-devel, hal-devel, gtkhtml3-devel, gstreamer-devel, and gstreamer-plugins-base-devel.

Step 2: download the source from HandBrake's SVN repository
in a terminal, type:

svn checkout svn://svn.handbrake.fr/HandBrake/trunk hb-trunk

This will download a bunch of stuff and finish by telling you which revision you have checked out.

Step 3: switch to your newly created directory
in a terminal, type:

cd hb-trunk

Step 4: prepare the source for building
in a terminal, type:

./configure --launch

This command should take care of most of the remaining steps, i.e. making a scratch directory and compiling the source for both the CLI and GUI interfaces.

Step 5: install the GTK GUI
in a terminal, type:

cd build/gtk ; sudo make install

In you experienced any errors during Steps 4 or 5, you can attempt to run through the build functions manually:
In a terminal, type:

rm -rf build ; mkdir build ; cd build

then:

../configure ; make

and finally:

cd gtk ; make ; sudo make install

*Interestingly, the build process no longer invokes/requires jam, which had always been a vestigial requirement left over from HandBrake's roots in the venerable BeOS.