Friday, December 23, 2011

How to Download Region-Locked Japanese Games from Android Market

The content of this tutorial is pulled from this post on byuu's forum. I am copying it here for redundancy and search engine indexing. The copyright belongs to D--.

I've finally found a way to pull region and phone model locked Japanese games from the Android market, such as the new Shiren game by Chunsoft. I'm posting the instructions here so no other poor fucker ever has to go through figuring this out.

Basically speaking, these games are locked by both SIM region and firmware information. Companies like NTT DoCoMo offer a select group of handsets with their service, and these handsets have firmware that has been heavily hacked on the inside to brand it as such. In order to get such a locked game, whether free or for sale, onto your phone, you will need to make Android Market think you are running an NTT branded handset.

To do this, you will need the following:
  • A rooted Android phone
  • RootExplorer
  • Superuser
  • Market Access - this app is ad free and can run at boot
  • A barcode reader that can handle QR codes
1. Run RootExplorer and navigate to /system. Click the button to remount as r+w.
2. Long press on build.prop and select Copy. Paste it into the same folder or another folder to make a backup. You DO NOT want to lose this.
3. Long press on build.prop and select Edit in Text Editor.
4. Find and modify the following values (jacked from an NTT DoCoMo SHARP SH12C). Be aware they may not be grouped logically, so search the whole file if need bed. If a value doesn't exist, you will need to create it:
ro.mtp.manufacturer=NTT DOCOMO, Inc.
ro.sh_build.version.incremental=01.01.02 2.3.3 S7140 01.01.01 release-keys
With it, I was actually able to purchase and install locked apps. In theory, if you have a tool like TitaniumBackup that converts installed apps to APK files, you could purchase an app, convert it to APK, then use the 15-minute return to get your money back. I have not done this because I don't want this kind of purchase pattern on my credit card, and because I'm willing to give Chunsoft 500 yen because that's a very fair price for Shiren.

5.  Close Root Explorer.
6.  Open System->Applications->All and scroll down to Market. Click Force Close and Clear Cache.
7.  Power off your phone. You absolutely must reboot your phone in order to populate the new values we just made in the RAM.
8.  Run MarketEnabler. Click the third tab and enter this for your SIM code: 44010. All NTT network SIM cards are branded 0xABEA.
8a.  Go to System->Accounts & Sync and add a NEW GOOGLE ACCOUNT. One that has never been tied to any phone. Create one if you must.
9.  Copy the URL of the program in the market and go to Paste it in and generate a QR code.
10.  Take a picture of the QR code with your barcode scanner. When prompted, pick to use Market to open the link.
10a.  Immediately click the menu button and change your account to the new Google account you added to your phone.
11.  Agree to the Market terms and conditions.
12.  Congratulations! You can finally install the fucking game!

NOTE: I was finally able to isolate a strange bug in that your current Google count does not notify Google that it is present on a new device. Apparently, your phone information is only sent to Google when an account is first tied to your phone. If you wish to purchase apps in the market with the account you've added, you will need to use that account to log in. Make sure your Market app is also set to that account so automated downloading can begin.

Thursday, December 22, 2011

My New Das Keyboard

Newegg briefly ran a huge sale on Das mechanical keyboards, so I decided to shell out the money and pick one up. This post will cover my background with keyboards and switches, and then provide some information about the Das.

Background (feel free to skip it if you don't care)

I've been a dedicated touch typist for a number of years, though I have fallen out of practice since leaving professional writing as an occupation and have settled into a modest 85-wpm rut. Even so, the specter of repetitive stress injury (RSI) hangs over me and informs my decisions on which keyboards I will and won't use.

For years, I was drawn to the scissor-switch keyboards, which have a short travel, light resistance and are more common on laptops, rather than the more common "rubber dome" keyboards, which dominate the desktop keyboard market, due to the reduced fatigue on my fingers and wrists. A few years ago, though, I began using my grandfather's original 1989 IBM Model M keyboard, which features the delightful "buckling spring" mechanical switch, and was instantly won over. Rather than lug it back and forth from home to work every day, I asked my employer to purchase a Unicomp Customizer, which retails for approximately $80.
Diagram of a buckling spring switch.

The Unicomp is a joy to type on and feels identical to the original Model M I use at home. However, both keyboards suffer from 2-key rollover, which means that certain keys conflict with one another when pressed, such that the keyboard will ignore any further keypresses, sometimes with as few as 2 keys pressed. This is no big deal when typing because typists never need to press more than one key at a time (except for modifiers, like shift, of course). However, when playing computer games, rollover (sometimes known as "ghosting") becomes a serious problem, which is what led me to shop around for a gaming-specific keyboard.

The Das Keyboard Model S Ultimate

After poring over's exhaustive mechanical keyboard analysis and review thread, it seemed to me that there is a segment of the market that could be considered equivalent. These keyboards all use various permutations of the Cherry MX microswitches and provide N-key rollover (i.e., you can press as many keys as you want and they will never conflict with one another) when connected to the computer via PS/2 (via USB, they are all limited to 6-key rollover, which is a limitation of the generic USB keyboard driver, apparently). Out of the many options, I decided to go with the Das since it was on a hefty sale and I had a spare Newegg gift card to make it even cheaper.

Foreshortening makes the Model M
appear larger, but they are roughly
the same size.
Of the Das models available, I had my choice between blue and brown Cherry switches. According to reviews, the blues are tactile (meaning your fingers feel a haptic click when the switch actuates) and clicky, while the browns are tactile and non-clicky. I have grown accustomed to the clickiness of my buckling springs, so the blues were attractive to me. In practice, the clickiness is nice and familiar and the resistance is surprisingly even less than I'm used to from my buckling springs.

This pic shows the difference in pitch.
While the Model M is rounded, the Das
is straight and flat. I don't really notice
the difference during use, though.
For anyone who is familiar with arcade buttons, the Model M feels like clicky Happ buttons, while non-tactile Cherry blacks would be more like Sanwa buttons (no haptic feedback for when the button actuates). Tactile Cherry MX switches, like the blues and browns, are somewhere in between, probably more like the Seimitsu clickies.

Though I am a touch-typer, I would have preferred to get labeled keycaps on my Das, but the model with Cherry blues and keycaps wasn't on sale. In the future, I'll probably pick up a handful of colored/labeled keycaps, just to give myself a few more landmarks. Perhaps the letter 'P' and/or the hyphen key, and maybe a Tux keycap for the 'super'/Windows key...

An area smoothed by high traffic on
my Unicomp after barely 1 year of use.
Other aspects of the keyboard are all top-notch. The USB ports on the side provide handy access for plugging in a mouse or thumb drive, though the placement of the ports can interfere with mousing on cramped keyboard trays, like mine (see the bottom-right corner of my pics). The keyboard housing is solid, well-constructed and easy to clean, though the glossy, piano black finish really attracts and holds fingerprints. On the other hand, this type of finish won't develop smooth spots in areas of high traffic like the stippled/matte finishes would, so there's a trade-off.

Final Thoughts

Overall, I'm very pleased with the Das. For typing, I guess I still prefer the buckling springs, but the Das is most definitely satisfactory and still blows away any scissor-switch or rubber dome I've encountered. I would recommend this keyboard to anyone who is interested in a solid gaming keyboard that can do double-duty as a very competent typing keyboard.

In a typing comparison, I am able to achieve my same 85 wpm on the Das as with the buckling spring keyboards (as measured by TypeRacer), though the lighter actuation pressure on the Das leads me to bottom out on it more often. However, I think this is something that I could get used to over time and could potentially end up increasing my speed somewhat, once I grow accustomed.

If you would like to learn more and/or are considering taking the plunge on a mechanical keyboard, the aforementioned thread is full of information for potential buyers. To learn more about keyboards in general, the wikipedia has an excellent article covering the various technologies. If you have any questions about any of the keyboards mentioned in this post, feel free to leave a comment.

Update (3/07/2012): I talked my employer into picking up a Das Professional S(ilent) for me. This keyboard uses the Cherry MX Brown switches and features labeled keycaps, unlike the Ultimate I have at home.

While the switches are definitely quieter than the Cherry Blues, they are far from "silent" and are probably only a little quieter than my Unicomp. I'm pleased with this, though, since I like the clickity-clack anyway; it just annoys my office-mates a little less now. Additionally, the Browns require a slightly higher actuation pressure compared with the Blues, putting them more on the level of the Unicomp/Model M.

Typing feels light and sure. This is a very comfortable keyboard and I think most anyone will be pleased with it for typing, probably more so than with the Blue microswitches.

Here are a couple of pics:

Tuesday, December 20, 2011

Cg Pixel Shaders for SSNES

Update (11/08/2012): New shaders added to the end of the post.

In addition to XML/GLSL pixel shaders, SSNES also supports pixel shaders written in Nvidia's proprietary Cg shader language, which is similar in syntax to Microsoft's HLSL language. While Cg hasn't been a very popular language for shaders, historically, many new shaders have been written for use with PS3 homebrew, where Cg is the only supported shader language. In fact, these shaders were downloaded from TwinAphex's SNES9x Next source code repository.

Another benefit to the Cg shaders is that they work with both OpenGL and Direct3D drivers in SSNES, which makes many of the more modern shaders to available to people with poor OpenGL performance for the first time.

As with my previous shader posts, these images were captured at a 3x scale factor, then enlarged using nearest neighbor to 400% for the detail shot. Click the thumbnails to embiggen.


This shader combines Hyllian's 5xBR algorithm with the phosphor-derived scanline shader from Caligari with great results. This shader is designed for use with square, non-aspect-corrected pixels, so be sure to use an 8:7 aspect ratio on SNES to avoid any nasty artifacting. It also expects at least a 5x scale factor, which looks like this:

Here are a few more pictures from the GBA version of Final Fantasy 6 and Street Fighter 3: Third Strike on FBA:

I find the scanlines make text easier to read than with 5xBR alone, for whatever reason.
Download the xBR pack from Hyllian here.


This shader accentuates the individual pixels by adding a cool, beveled look along with some color-tweaking mojo to give them a feeling of depth. Again, it expects non-aspect-corrected images, or else subpixel aliasing effects will make a mess of things.

Here's another picture at 20x (5x scale factor, enlarged 4x with nearest neighbor; see it full size to get the full effect):

Notable ports from the XML shader family include cgwg's CRT shader, Themaister's dot-n-bloom (listed as '') and Waterpaint shaders and an extremely fast implementation of bicubic filtering ( from Hyllian, as well as all the classics, such as HQ2x, SuperEagle and so on.

Update (11/08/2012)


Hyllian has been working on some interesting shaders lately, including an implementation of Christoph Feck's "reverse anti-aliasing" algorithm, which allows for some very sharp, smooth upscaling. It works on any image but really shines on digitized images with lots of gradients (think: SNES games with digitized sprites or games with prerendered backgrounds, like Resident Evil or Final Fantasy 7). It's also particularly good at rendering legible text, so it's great for RPGs, as well. Here are some images of this shader paired with some scanlines:
 As you can see, Clay Fighter looks really great with this shader. Too bad the game is godawful.


As with pretty much everything else, bsnes has taken some sophisticated steps to achieve an authentic gamma ramp that reflects the actual appearance of games. Themaister was kind enough to reproduce the relevant code in Cg form. This is how it looks:
He also wrote a cgp file (just a simple file that tells RetroArch how to deal with multiple Cg shaders) that will enable pixel blending used in pseudo-hires transparency, which bsnes-derived emulation cores typically render as a series of vertical stripes instead of the intended translucent color. You can download the bsnes-gamma-ramp+hires blending bundle here.


A simple, fast scanline shader from Gigaherz, LCD3x is intended to evoke the look of handheld console LCD displays:
It's also a very easy shader to customize, if you want darker scanlines or to brighten the overall image. These variables are located on lines 12 and 13 of the shader, respectively.

I'll add more shaders and more pics in the near future.

Monday, December 5, 2011

Beginner's Guide to Cyanogen Mod on Epic 4G (Samsung Galaxy S SPH-D700)

UPDATE: This guide also works with the new Cyanogen Mod 9 release, which is based on Android 4 Ice Cream Sandwich.

Based on Sprint's depressingly slow release of Gingerbread OTA (over the air) updates for the Epic 4G (aka Samsung Galaxy S SPH-D700), it looks like this phone will be considered EOL (end of life) in the very near future, despite being barely a year old (that's like, what... 7 years in cell phone time?). It is, therefore, very unlikely that us Epic owners will ever receive an official update to Android 4.0 Ice Cream Sandwich.

However, thanks to the open source nature of Android and some extremely clever community members, we can now use the awesome, fast, feature-filled Cyanogen Mod (CM) on our phones. CM7 has only just recently reached 'supported' status on the Epic 4G, while international versions of the phone have had support for some time.


To get started, we need to download some tools:
1. Odin, which is a Windows-only (boo) utility for flashing firmwares on the Epic 4G. Mac/Linux users can try Heimdall, but I won't be covering that in this tutorial.

2. A rooted kernel for Samsung's official Gingerbread ROM. This will prep your phone for all of the shenanigans we'll be getting into. It also includes some nice community-provided goodies, like a fix for the keyboard's habit of dropping double-tapped letters.

3. ClockworkMod, a special bootloader that now works with the Epic 4G. Once you get this guy installed, you never have to use your computer for this kinda stuff again. You can just flash in new ROMs (like CM updates) directly from your phone's SD card.

4. A Cyanogen Mod image optimized for the Epic 4G. This is the one I used, but since then, the epicmtd (the codename for the Epic 4G) has become an officially supported device! That means you can always get the latest stable and/or nightly builds from the official CM distribution source. One thing to be aware of: CM10 requires repartitioning your phone, so once you go to it, you can't go back to CM9/ICS or earlier without returning to stock first. As long as you stay with CM9 or earlier, however, you can swap between them without doing a full reversion.

5. Samsung's USB Phone Drivers. Without this driver, Odin will fail to see your phone :(

6. G-Apps. They're named in this fashion: gapps-[android revision]-[date] Find the one that matches your CM version (ICS corresponds to CM9 while JB corresponds to CM10) and has the most recent date.

You'll also need a USB-A-to-microUSB cable that is SHORTER than the one that came with your phone. For some strange reason that I won't go into here (it has to do with impedance of the wire :O), the 6-foot cable that is shipped with the phone will almost always fail the process, leaving you with a semi-bricked phone. Get one like this instead.

Ok, once you've collected all of your tools, we can get started.


1. Install your USB Phone Driver and unpack your Odin zip file. Inside the resulting folder, you should have your Odin executable (ends in *.exe), Odin3.ini and a *.pit file (mine is victory_8G_100528.pit).

2. Plug your USB-A-to-microUSB cable into your computer, but not into your phone. Now, power off your phone, slide open your phone's keyboard and hold down the number 1 key and the power button while plugging in the microUSB cable. It should boot into this screen:
3. Now, open Odin. It should look something like this:
Make sure, under 'Option' on the left, the box next to 'Re-Partition' is NOT checked. Then, on the right, click the button labeled PDA and navigate to your Samsung recovery ROM (#2 in the tools above). Choose it and, back in the main window, click the big button labeled 'Start.'

Some messages should run through the window on the bottom left of the Odin window and, if everything went well, it should end up like this:
and your phone should reset itself and boot into the Samsung ROM.

4. Now, power off your phone again, unplug it from your computer and perform step #2 again to get it back into the recovery state.

5. Back in Odin, click the PDA button again, but this time, navigate to the ClockworkMod ROM (#3 from the tools above). Choose it and, back in the main window, click the 'Start' button again. The message window in the bottom-left of the menu should cycle some more messages and, if everything went well, it should say All threads completed. (succeed 1 / failed 0) and your phone should reset itself again.

At this point, we're finished with Odin (forever), so go ahead and close it out.

6. From now on, you can flash anything you want directly from your SD card, which is awesome. So, put your phone into USB Mass Storage mode (I had to unplug my USB cable and then reconnect it, then it prompted me as usual) and drag your CyanogenMod ROM (#4 from the tools above) to the root (top level directory) of your SD card and rename it to '' (very important).

Now, on your phone, tap the button labeled "Disconnect storage from PC" to unmount it from your computer and power-off your phone. Once it's completely turned off, power it back on, but when you do, press and hold the power button, the camera button (i.e., the button below the power button) and the 'Volume Down' button on the other side of your phone to enter the ClockworkMod bootloader. It should look something like this:
Using the volume up/down button to navigate, select 'Apply' It will ask for confirmation and warn you that it cannot be undone. Confirm your selection and it will begin installation, which should look like this:
When it's all finished, it will put you back in the bootloader, where you can choose 'Reboot system now':
If everything went well, you should see the CyanogenMod7 boot screen, like this:
Congratulations! Take a deep breath and give yourself a pat on the back. We just have a few more things to add and then we'll be done! You can proceed to step #7.
If you just keep seeing the CyanogenMod7 boot screen over and over (like I did), then you've encountered the "bootloop" error, which is no big deal. Just boot back into your ClockworkMod bootloader, choose 'Mounts and Storage' from the main menu, and then 'mount USB storage' (you may have to unplug/replug the USB cable from your computer if it doesn't recognize it straightaway). Once it mounts on your computer, you can try to redownload your CyanogenMod image, rename it to and replace it on the root of your SD card. When it's done copying, select 'Unmount,' tap the 'back' button to go back to the bootloader, select 'wipe data/factory reset' and then flash it again to CM.
7. Once you successfully reach the CM desktop, activate USB Mass Storage mode via the pulldown main menu. Once your SD card mounts on your computer, create a new folder in the root directory (you can call it whatever you want, but I'm going to call it 'updates'). Note: you can also delete your CM image at this point, if you want to free up the space. Put your G-Apps into your new directory and boot back into your ClockworkMod recovery.

Once you're there, choose 'Apply update from zip file on SD card,' then 'choose zip from SD card,' then navigate to your newly created directory ('updates' for me) and choose your gapps zip. When it finishes, choose 'Reboot' from the bootloader and you should be all set!

Whenever new updates for CyanogenMod are released, simply rename them to '' and place them on the root of your SD card, then run the update from ClockworkMod's bootloader. < Note: since this was written, you can update straight from CyanogenMod without using ClockworkMod by going to System Settings > About phone > CyanogenMod updates. Here, you can browse and download updates and apply them on the next reboot.

Wednesday, November 30, 2011

Upgrading My Powered Subwoofer for Hi-Fi

I had been supplementing the low end on my ol' hi-fi with a crappy 30-watt powered subwoofer that came with some boxed surround sound set I purchased a number of years ago. It uses an 1/8" jack for input and drives a 4.5" (I think) woofer in a 4th order bandpass enclosure, like this:
However, the sound was pretty lackluster and failed to really produce anything much below 50 Hz, so I decided to kick it up a notch with some spare equipment I had laying around.

The stock woofer was highly inefficient when trying to play low frequencies, and was prone to "chuffing" (the sound air makes when it is quickly pushed out of the port hole) at higher volumes. The subwoofer's amplifier, however, is quiet (no humming, even with the volume cranked) and I like the simplicity of the 1/8" input (fewer wires jumbled up behind my setup), so I decided to bypass the crappy stock speaker and use the amp to drive a more capable bass speaker.

I had a spare Electro Voice EVM-15L driver with matching enclosure that I used for playing bass guitar, so I cut a 1/4" patch cable in half to get at the bare signal/ground connections without damaging the existing enclosure (in case I decide to use it for bass guitar again at some point) and disassembled my little subwoofer enclosure.

The subwoofer amplifier stage is mounted on a plate that came off easily after removing 8 little screws. A single wire connected the amplifier to the crappy stock speaker, so I cut that and pushed it to the outside of the enclosure to power my EV 15".

At this point, I could have removed the amplifier plate entirely from the old enclosure and woofer, but I didn't want to have a bunch of bare circuit boards laying around, so I routed the aforementioned cut-wire out through one of the screw holes and then screwed the plate back into place on the enclosure.

Unfortunately, when I connected the now-liberated amplifier to my EV 15", I experienced a lot of clipping, even at low volumes. I suspected that this might be a problem with the impedance of the driver not matching up with that of the stock driver, so I wired a spare 8-ohm resister in series with my EV, which fixed things right up. Now, it sounds great and has much more volume than I could ever want/need (the EV's SPL at lower frequencies is, unsurprisingly, far greater than the stock driver's).

The bass is smooth, punchy and you can feel it in your guts, unlike the piddly, flatulent sounds of the stock configuration. I've heard a lot of audiophiles say that "pro" audio gear is inappropriate for hi-fi use, but my experience demonstrates otherwise.

Monday, November 28, 2011

Installing Linux Mint 12 on Lenovo x120e

Ubuntu has really been pissing me off lately with the whole GNOME 3 / Unity desktop hokey pokey so I decided to test the waters with some other options. After trying and rejecting some alternate desktop packages within the Ubuntu ecosystem, I decided to try the newly released, Ubuntu-derived Linux Mint 12.


Since my computer (Lenovo ThinkPad x120e) doesn't have an optical drive, I downloaded the Linux Mint 12 CD (64-bit) release image and used Ubuntu's "Create a USB startup disk" utility to write it to my flash drive. However, when I tried to boot from it, it kept failing at the bootloader with an error that I can't quite remember (I'll try to reproduce the problem, for search indexing's sake).

I installed the unetbootin package, though, and it created a working drive on the first try. Once I booted into the Mint live system, installation proceeded smoothly and identically to a normal Ubuntu install.

First Impressions

Upon rebooting into my shiny new installation, the restricted driver manager popped up and acknowledged my Broadcom wireless card and Radeon graphics. The wireless drivers never kicked in, though, and the graphics displayed text wrong in the panels and menus (some letters and words were a scrambled, garbled mess).

The lack of wireless *and* a proper graphics driver was a definite deal-breaker for me, so that's where my first experience ended. I hope to give it another shot soon, so I'll update this post if I have any better luck.

UPDATE (12/05/11): I switched over to Linux Mint Debian, which is a rolling-release version based on Debian Testing. Again, installation was successful and fast. Debian doesn't have some of Ubuntu's noob-friendly utilities, such as the 'Additional Drivers' (jockey) utility, so you'll have to manually install the fglrx-driver package and then configure your /etc/X11/xorg.conf file to get accelerated graphics. There is an automated tool, aticonfig, that you can use to configure your xorg.conf. The following command will install the fglrx driver and the helper libraries to get accelerated video decoding, then invoke the aticonfig command to automatically configure your xorg to use the new driver (Thanks Erik!):

sudo apt-get install libva1 libva-x11-1 libva-tpi1 libva-glx1 libva-dev xvba-va-driver fglrx-atieventsd fglrx-control fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-modules-dkms
Thankfully, Mint Debian had none of the aforementioned weird rendering issues with the proprietary driver, and Compiz worked just fine (I installed the fusion-icon package so I could turn it on and off more easily).

UPDATE (12/30/11): Erik notes:
I went back to the open source drivers....
They seem to work much better for watching flash movies. For Youtube I use the FVR Flashvideoreplacer addon. The other websites are better with the open source drivers then with fglrx.
So, if you watch a lot of Flash video (youtube, Hulu, etc.), you might be better off sticking with the default, open source drivers, buy YMMV, so be sure to try both.

I have not yet been able to get my Broadcom wireless working, but I'll try to update this post if/when I get it figured out. If you are fortunate enough to have chosen the other wireless chipset, you should be fine out-of-the-box.

Saturday, November 19, 2011

Advanced RetroArch Configuration Options

Update (4/23/2012): SSNES has changed its name to reflect its versatility beyond SNES emulation. The new name is RetroArch and this article has been updated to reflect the change.

This guide picks up from where the basic guide left off, so if you haven't read it yet, you should.

In the main window, you can choose whether to save a BSV movie, which is basically a small file that logs all of your keypresses when you play. You can later take this file and replay it back like a sort of movie. This can be used to share your gameplay with others without the necessity of passing around gigantic files.

Below that, we have FFmpeg movie output, which allows you to dump actual video files using state-of-the-art, lossless RGB x264 with FLAC audio. The files can be quite large, but are appropriate for high-quality recording for things like speed runs. Currently, only *.mkv files are supported, so if you want to use this feature, make sure your file name ends in mkv. This feature can be used in conjunction with BSV playback to simplify recording speed runs, etc.


At the top of the main window, you'll see a menu labeled Settings. From there, click on General, and it should open a window that looks like this:
The first entry, Enable rewind, is what toggles on the ability to use real-time rewind, similar to what you find in the popular indie game Braid.

The next few options are for special use cases and can generally be ignored (the defaults are usually fine).

The next option I want to point out is Records filtered output, which will make the aforementioned mkv video dumps capture the image *after* filters (but not shaders) are applied, so your video will look as fancy as what you see on your screen. Below that, you have fields to load XML cheat databases, such as those used in bsnes, and below that you have some entries to specify paths for various additional files, such as save data and screenshots, that RetroArch creates. If left blank, these will default to the folder the ROM is loaded from.

From here, you can choose your desired video driver. For most people, OpenGL (the default), will be fine and I will assume that's the one you'll use for the remainder of this tutorial. However, if OpenGL doesn't work for you, you can choose the slow and crappy (but reliable) SDL driver, or the D3D driver (not available in Linux, of course).

Windowed X and Y scale let you set custom sizes for the emulator window, while Fullscreen X and Y resolutions let you set custom resolutions in fullscreen (leaving it at 0 will attempt to scale the window as large as possible).

Checking VSync will cap your framerate to your monitor's refresh rate (a good thing, or else the emulator will run as fast as it can...).

Start in fullscreen is self-explanatory, and you probably want to leave Force 16-bit color turned off.

Disable composition (Win Vista/7) will automatically turn off Aero transparency, which can conflict with VSync in windowed mode (makes video stuttery), but doesn't affect fullscreen.

Bilinear filtering will add a slight blur to the image to take the edge off of the hard pixel edges (also known as smooth video in some emulators). This option has very little impact on performance.

Lock aspect ratio will ensure that the image is always a given aspect ratio (default is 8:7, assuming square pixels). You can also enter a custom aspect ratio (in decimal format, such as 1.333333 for 4:3 assuming non-square pixels) in the window next to the Aspect ratio entry farther down.

Crop overscan cuts off a few pixels around the edges of the image that were customarily left blank by developers and sometimes contain garbage pixels.

Below that, we have Shader/filter settings, which opens the advanced shader and filter settings window, and at the bottom we have Font settings which opens the advanced preferences for the onscreen text display.

Shader and Filter Settings

This is where RetroArch gets its bling:
The first entry, Cg pixel shader, allows you to load pixel shaders in Nvidia's Cg format. Below that, you can load bSNES XML shaders (deprecated in bsnes with v083, but RetroArch still supports them). The Cg shader format works with both OpenGL and D3D drivers, which is nice, but the selection is more limited than with the more common bSNES XML shaders.

The XML shader directory option allows you to select a folder that contains XML shaders that will be loaded in sequence when you press the assigned hotkey.

Checking the box by Render-to-texture (2-pass rendering) allows you to "stack" an additional XML pixel shader for additional effects. If you enable this, the FBO X and Y Scale fields allow you to specify a scale factor for the first-pass pixel shader. This often doesn't make a huge difference, but it can help with certain shaders that are intended to be calculated at a specific scale, such as HQ2x. Bilinear filtering (2. pass) applies the same slight blurring as before, but this setting ensures that you have fine control over how much blurring occurs and when. Finally, the Shader (2. pass) field is where you select the desired shader for the second pass.

The last field, bSNES video filter, allows you to apply CPU-powered filter libraries from bsnes (like XML shaders, they were deprecated in bsnes as of v083, but RetroArch still supports them), such as blargg's kickass NTSC filter.

You can download a number of Cg shaders from my Mediafire Cg repo, while XML shaders can be downloaded from Screwtape's XML shader repo and/or my Mediafire XML repo.

This page has preview pics for most of the XML shaders and a link to Themaister's WebGL shader testing applet.

You can download bsnes video filters for Windows here (32-bit) and here (64-bit) and for Linux here (32-bit) and here(64-bit).

Font Settings

With the On-screen message font entry, you can load a custom Truetype Font for RetroArch to display onscreen, while On-screen font size specifies the font size in points.

Enable on-screen messages is pretty self-explanatory. Uncheck to disable onscreen messages from  RetroArch.

On-screen message pos lets you specify custom X and Y axis positions for onscreen text, and Message color (RGB hex) determines the the color of the text in hex format. You can use an online color picker like this one to get your desired color in the proper format.


The first option is self-explanatory. Uncheck it to completely disable audio.

Audio driver is also pretty straightforward. DirectSound is usually the most compatible in Windows, but XAudio2 has lower latency and is often less buggy. In Linux, ALSA is what I use, but many speak highly of OSS.

With the External audio driver option, you can choose a custom driver that conforms to the RetroArch plugin API, but the only one available at the time of this writing is Themaister's experimental WASAPI driver. Below that, you can specify an Audio DSP plugin, which can potentially provide reverb and echo effects, etc. Mudlord has written a few of these, which even come with a fancy Qt GUI.

Audio sample rate should be set to match your computer's sound card output rate, which is usually the default 48 kHz.

Audio input rate can be confusing at first but is awesome once you get it set up (like RetroArch itself :P). Basically, as the emulator chugs away, it creates video frames at a rate of 60 per second and audio at an ideal rate of 32,040 samples per second. However, modern LCD monitors rarely have a true 60 Hz refresh rate, so, when displayed with VSync enabled on such a display, the audio and video will get faintly out of sync and cause either a video frame to drop (manifested as a stutter in the video) or a crackle in the audio. The default value of 31,980 is a closer match to modern display refresh rates than the ideal rate, but you can nudge it higher--if your video still drops frames occasionally--or even lower if your audio continues to crackle.

Audio rate step specifies the granularity at which the audio rate increases or decreases when you press the corresponding hotkeys.

Dunno what Audio device does.

Audio sync is similar to VSync in that it keeps the framerate in synchronization with the audio. Keep it checked for best results.

Audio latency (ms) is pretty self-explanatory. The default value is usually fine.

Input Settings

The Input settings window is where you can assign buttons and/or keys.

The slider at the top, labeled Input axis threshold, determines at which point an analog control will register as a digital button-press.

Below that, you can choose whether or not to use Player 1 button/key assignments during netplay regardless of whether you're hosting the game or connecting to someone else.

The pulldown menu below that lists the categories of keys you can assign, including all of the available controller slots from Player 1 to Player 5 and the miscellaneous RetroArch functions, like rewind. You can bind any of these functions by double-clicking on its entry and then pressing the appropriate key when prompted.

Last, the Detect analog checkbox determines whether analog inputs are even polled.


Netplay is one of RetroArch's crown jewels and can be enabled via the main RetroArch-Phoenix window. We'll cover its configuration first and then go over some of the quirks you should be aware of.

If you check the box to enable netplay, you must specify whether you will be hosting (server) or joining (client) the game. If joining, you must also enter the host's IP address in the field below. Make sure your firewall is open on port 55435 (default; you can change it if you like) and that the port is forwarded in your router, if applicable. You can also specify 'spectator mode,' which will allow an arbitrary number of spectators to join and watch you play without being able to play themselves.

Delay frames denotes the maximum number of frames RetroArch will need to emulate at once to maintain synchonization due to actual network latency. You can figure out an appropriate ballpark for this number by pinging the other player and dividing the time (in milliseconds) by 16 (roughly the number of milliseconds in a frame from a game running at 60 fps).

Similar to the GGPO platform, RetroArch creates a constant stream of savestates which, along with button presses, are exchanged and compared between the server and client machines. If the savestates start to diverge, the game rolls back in time to a point where they both agree and then emulates the missing frames all at once to get back to the appropriate spot. This gives the illusion of completely lagless inputs, which is invaluable for twitchy, fine controls, such as parrying in Street Fighter III: Third Strike.

The downside to this method is that sound is almost always crackly and it can sometimes create odd time-rollback isues (hard to explain, but you'll know them when you see them ;P). It also produces occasonal spikes in CPU utilization as the emulator needs to emulate a series of frames all at once to catch up after a rollback.

If the gameplay is a bit choppy, try increasing the number of delay frames a bit. If you try to connect to a server and it immediately says client disconnected, open your log and make sure your ROMs match exactly (it will complain about a hash mismatch otherwise). If it gives you a weird time-out error, just close the window and try to connect again and it should work itself out (sometimes excessive spikes in network latency can cause the states to diverge catastrophically, resulting in this error).

It is also important to note that netplay does not work with all libsnes implementations. Known working implementations include snes9x (and the -next variant) and FBA's CPS3 driver (e.g., for SFIII: Third Strike). Other implementations may work, but you'll have to try them yourself (please leave a comment with your experiences if other implementations work/fail). Often, RetroArch won't show a disconnection if things desync during netplay and will instead show either a non-moving second player, or his/her behavior will be weird (like jumping into holes, running into enemies, etc.).

Getting Started with RetroArch

Update (4/23/2012): SSNES has changed its name to reflect its versatility beyond SNES emulation. The new name is RetroArch and this article has been updated to reflect the change.

RetroArch is a multi-platform multi-emulator with support for some really cool, unique features, including extensive shader and filter support, real-time rewind, lossless video dumping, advanced "lagless" netplay, and more. Unlike many other emulators, RetroArch is under rapid and active development and receives new features on a regular basis. However, all of these esoteric options and capabilities can be daunting to new users, so this guide will cover the basics. The instructions are primarily geared toward Windows users, but the configuration information is essentially the same on any platform.

So, first off: RetroArch is all about modularity, so we need to download a couple of initial modules, namely the RetroArch executable and its helper libraries. To get started, go to the RetroArch homepage and download the RetroArch full package that suits your system (the 'x86' build will work on all machines, while the x64 build will only work in 64-bit versions of Windows; get the x86 version if you don't know which is appropriate for you). The slim package contains the absolute minimum required for bare, no-frills emulation, while the full package is prepared to utilize RetroArch's many advanced features.

Once your download finishes, extract the zip file, navigate to the extracted RetroArch folder and look for retroarch-phoenix.exe. This is the graphical user interface (GUI) module that will help us get RetroArch set up and configured. Double-click it and you should see a window that looks like this:
Along the upper edge of the window, open the RetroArch menu and select Update RetroArch:
It should open a window that looks like this:
You can use this tool to automatically download updates for RetroArch, its helper libraries and any/all of the various emulation cores. First off, you'll need to select which flavor of RetroArch you're using--x86 or x64 (aka x86_64)--by clicking on the appropriate bubble next to CPU.
Then, click on the button labeled Check version. This will search for updates to RetroArch and/or its helper libraries and populate the list of available emulation cores:
After that, click on the bubble labeled Redist and then the button that says Download RetroArch. This will fetch any updated RetroArch executables, as well as fresh copies of all of the helper libraries (you can update RetroArch without the helper libraries by using the Full button instead of Redist).

At this point, you can also automatically download any of the cores in the list by double-clicking on its entry. After the download finishes, it will ask if you want to use the core. Whether you do or not is okay, as we'll be specifying our desired core in just a few seconds anyway.

Once you're done downloading cores (you can come back to this menu and download more cores at any time), close the Updater window and return to the main window, where we'll need to configure some options.

Starting from the top, the Normal ROM path is where you select the ROM you want to play. It will not hide inappropriate files, so make sure you pick the right one for the system you wish to emulate ;)

Next, we need to tell RetroArch where to store and load its settings, via the RetroArch config file path. Click Open, and then navigate to your RetroArch folder and choose the file named retroarch.cfg. Likewise, for RetroArch path, click Open, navigate to the same folder and select retroarch.exe.
Finally, the Emulator core path lets us select which emulation core we wish to use. So, click Open, navigate to the RetroArch folder and look for your desired core that you downloaded from the Updater, such as gambatte-0.5wip1-x86_64.dll in my case. RetroArch can be paired with any emulator core that conforms to the libretro API specification, including but not limited to the original libretro (previously known as libsnes) derived from byuu's bsnes.

At this point, simple emulation should be functional, so go ahead and try it by clicking on the big button labeled Start RetroArch. If it works, congratulations! You're ready to play. Check out the advanced configuration options to learn about filters/shaders, netplay, rewind support and more.

If it doesn't work, click on the File menu at the top of the window and select Show log. This will give you some information on why it failed. If you seek help at the RetroArch forums or in the RetroArch IRC channel, be sure to have this information handy, as it will help others solve your problem.

If you would like to explore some of RetroArch's more advanced features, check out this guide.

For Linux Users

If you're using a Debian-based distro, such as Ubuntu or Mint, you can use my PPA repo, where I package a number of emulators, including RetroArch and all flavors of libretro. To install RetroArch, open Synaptic Package Manager and add ppa:hunter-kaller/ppa to your software sources. You can then install any of the packages through your normal installation procedure of choice.

Otherwise, configuration is just like in Windows, except your retroarch.cfg file is initially installed to /etc/retroarch.cfg (but can then be copied to and overridden by any retroarch.cfg file located in ~/.config/retroarch/) and the emulation cores install to /usr/lib/.

Wednesday, October 5, 2011

Using sloth86's Ambient Occlusion Tools in SF4

In the course of making skins for SF4, you might have toggled off an unwanted model, such as Chun Li's spiked bracelets, only to find an unsightly darkening, similar to a shadow, where the object used to be. This darkening is part of what's known as an "ambient occlusion (AO) map," which is used by the game to fake some self-shadowing by the models and thus reduce the amount of shadows your computer needs to draw dynamically to look realistic. However, once the offending model is gone, the AO isn't really appropriate anymore, so we need to do something about it.

For this tutorial, you'll need to download some of sloth86's tools: AOExtractor, AOInject and EMG Swapper, as well as piecemontee's Asset Explorer (aka, SF4Viewer). You'll also need a paint program that can view/edit EPS files, such as Photoshop. UPDATE (6/20/2012): the links for sloth86's tools are dead. You can now get the AO tools here and the EMG Swapper here.

Once you have your tools, open your desired costume file (*.obj.emo) in the Asset Explorer. I'm going to be using Chun Li's default costume (CNL_01.obj.emo):

As you can see in the picture above, I've already toggled off her 'Ring' model, which has left the visible AO darkening on her 'Skin_arm' model, which I intend to fix.

So, next we'll want to select that darkened model, right-click and choose 'raw dump' to get the raw EMG model. Name it something informative with the .emg file extension and click 'save.'

While we're here, take note of which EMG model we're extracting, counting from the top. For me, it's the 10th one. We'll need this information later, so write it down or something.

Next, open the AOExtract tool. You should see a window like this pop up:

In the first field, put in whatever you just saved your dumped model as. In my case, 'skin_arm.emg.' The other options can be left at the default values, unless you just feel like changing them. (Subdividing triangles will make your EPS file look a little nicer, but it takes longer and is unnecessary)

Click 'Extract' and you should end up with a new file, in my case 'new.eps.'

Open your new EPS file in Photoshop and you should see something like this:

Those triangles you see correspond to the triangles used to make the model (just like the UV map, if you're familiar with those). As you can see, some of them are particularly dark, while others are lighter, just like we saw in the Asset Explorer window.

So, using the dropper tool, pick a medium color (we don't want a dark shadow, but we don't want it all bright like a highlight, either). If you're familiar with using hex color values, EFEFEF is a pretty good, generic match.

Once you have your color, you can either use the paint bucket tool to change each triangle by hand, or you can just paint over the whole thing, like I did.

Once you're all finished, we need to 'Save As...' and choose the bitmap (BMP) format, with OS/2 compatibility, 24-bit and no compression.

Next, open the AOInject tool. You should see a window like this:

In the first field, enter the name of your dumped EMG model, in my case, skin_arm.emg. In the second field  enter the name of our modified, blank AO map, in .bmp format. The third field can keep its default value.

Click 'Go' and you should be left with a new EMG model that we can view in the Asset Explorer:

As the pic shows, it's all one uniform gray color, instead of having light and dark areas.


However, now we need to actually get this unshadowed model back into our character model. For this, we turn to the EMG Swapper tool.

Open it up and you should see a window like this:

In the first field, enter the name of the character model you're working with, in my case, CNL_01.obj.emo. In the second field, enter the number of the model we're replacing (remember the thing we wrote down earlier??), in my case it's number 10. In the third field, enter the name of your modified model (the one we injected the new AO map into), in my case 'blank.emg.' The last field can be left with the default value, unless you want to name it something else.

Click 'Go' and you should be left with a new EMO file, which we can view in the Asset Explorer:

Our model fits right in and doesn't have any messy shadows for nonexistent objects anymore. Mission accomplished!

Unfortunately, you can see that her hands still have darkening, which creates a seam next to our modified object, but using your newly found AO mapping expertise, I'm sure you can fix it on your own. ;-)

That's it. Good luck, share your work and ALWAYS MAKE BACKUPS!

Monday, September 26, 2011

Pixel Shaders in Genesis, GBA, GBC Emulation

If you've looked at any of the amazing pixel shaders available for bsnes, such as the collaborative CRT shader from cgwg and DOLLS or Themaister's dot-n-bloom, you may have wanted to use them with other systems, such as Sega Genesis or Gameboy Advance. Well, now you can! Update (10/03/2011): now it works with Final Burn Alpha, as well. Update (10/5/2011): I'm adding download links for Windows binaries of the various libraries, when possible.

Themaister wrote some "hacky" wrappers around Genesis Plus GX, Visualboy Advance and Gambatte that route their APIs to match up with that of libsnes. That means any frontend for libsnes, such as Themaister's own SSNES, can now serve as a frontend for these excellent emulators. Thus, any features of the frontend, such as SSNES' real-time rewind and FFMPEG-powered video dumping capabilities, get baked in automatically. This also extends SSNES' badass GGPO-style netplay to all of these systems (where applicable, of course).

If you're using Ubuntu or another Debian-based distro, you can get precompiled binaries from my PPA repo. Other *nixes can compile them from source. The only dependencies are git (not even totally necessary if you manually download the source via http), a compiler that supports C++98 or higher (gcc-3.4 and up, IIRC) and zlib (in Debian-based distros, it's the zlib1g-dev package).

So, open a terminal and type:

For Genesis Plus GX:
git clone
cd megadrive-next/src/libsnes

Download Windows libsnes-genesisplusgx binaries
(you may need to rename zlib.dll to libz-1.dll for it to work)

For Visualboy Advance (vba):
git clone git://
cd trunk/platform/libsnes

For Gambatte:
git clone git:// --branch libsnes
cd gambatte-libsnes/libgambatte/libsnes

For Final Burn Alpha (fba):
git clone git://
cd fba-next-slim/src/burner/libsnes

Download Windows libsnes-fba binaries

The resulting libraries will all be called In my packages, the libraries are named according to the emulator (libsnes-*.so) so you can have them all peacefully coexist.

One thing to be aware of: SSNES-Phoenix's file browser will filter out non-SNES extensions, so you'll have to manually type the filenames unless/until Themaister does anything about it.

Screenshots (dot-n-bloom shader is used for the GBC and GBA screenshots, CRT is used for Genesis and FBA):

Analytics Tracking Footer