Filthy Pants: A Computer Blog

Apple iPod Nano 1G Recall

2012-01-07T10:40:00.000-08:00

Due to a potential for exploding batteries, Apple recently instituted a recall on all 1G iPod Nanos, of which I had two (one with 2GB capacity and one with 4GB). I sent them off and, after a pretty long turnaround time (nearly two months altogether), I've received my first replacement: a brand new 6th generation touchscreen iPod Nano with 8GB capacity :D

If you happen to have one or more of the old models, I recommend you take advantage.

How to Download Region-Locked Japanese Games from Android Market

2011-12-23T07:54:00.000-08:00

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.build.id=S7140
ro.build.display.id=01.01.02
ro.build.version.incremental=01.01.01
ro.build.version.release=2.3.3
ro.product.model=SH-12C
ro.product.brand=DOCOMO
ro.product.name=SH12C
ro.product.device=SH12C
ro.product.board=SH12C
ro.product.manufacturer=SHARP
ro.product.locale.language=ja
ro.product.locale.region=JP
ro.mtp.manufacturer=NTT DOCOMO, Inc.
ro.sh_build.id=S7301
ro.sh_build.version.incremental=01.01.02
ro.build.product=SH12C
ro.build.description=SH12C-user 2.3.3 S7140 01.01.01 release-keys
ro.build.fingerprint=DOCOMO/SH12C/SH12C:2.3.3/S7140/01.01.01:user/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 kaywa.com. 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.

My New Das Keyboard

2011-12-22T09:37:00.000-08:00

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 Overclock.net'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 Overclock.net 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.

Cg Pixel Shaders for SSNES

2011-12-20T20:15:00.000-08:00

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, most of these shaders were downloaded from TwinAphex's SNES9x Next source code repository.

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.

5xBR+CRT

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.

Retro

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):

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

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

2011-12-05T13:33:00.000-08:00

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.

Preparation

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. Samsung's modified official Gingerbread recovery 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 there will probably be better/newer ones available by the time you read this.

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

6. G-Apps and Google Talk updates. Google doesn't let CyanogenMod bundle its applications, but you can download them from the CyanogenMod wiki.

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, 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.

Installation

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 'update.zip' (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 sdcard:update.zip.' 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 update.zip 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 and Google Talk update files into your new directory and boot back into your ClockworkMod bootloader.

Once you're in the bootloader, 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). Choose the G-Apps update first, followed by the Google Talk update (if installed in the wrong order, the Google Talk app included in the G-Apps update will overwrite the preferred standalone Google Talk update). 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 'update.zip' and place them on the root of your SD card, then run the update from ClockworkMod's bootloader.

Upgrading My Powered Subwoofer for Hi-Fi

2011-11-30T09:08:00.000-08:00

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.

Installing Linux Mint 12 on Lenovo x120e

2011-11-28T16:49:00.000-08:00

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.

Installation

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.

Advanced SSNES Configuration Options

2011-11-19T18:05:00.000-08:00

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.

General

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/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 SSNES creates. If left blank, these will default to the folder the ROM is loaded from.

Video

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 SSNES 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 SSNES 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 SSNES still supports them), such as blargg's kickass NTSC filter.

You can download a number of Cg shaders from Themaister's Github repo, while XML shaders can be downloaded from Screwtape's XML shader 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 SSNES 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 SSNES.

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.

Audio

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 SSNES 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 SSNES 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 SSNES 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

Netplay is one of SSNES' crown jewels and can be enabled via the main SSNES-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.

Delay frames denotes the maximum number of frames SSNES 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, SSNES 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).

Getting Started with SSNES

2011-11-19T15:13:00.000-08:00

SSNES 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, SSNES 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: SSNES is all about modularity, so we need to download a couple of initial modules, namely the SSNES executable and its helper libraries. To get started, go to the SSNES homepage and download the SSNES 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 SSNES' many advanced features.

Once your download finishes, extract the zip file, navigate to the extracted SSNES folder and look for ssnes-phoenix.exe. This is the graphical user interface (GUI) module that will help us get SSNES 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 SSNES menu and select Update SSNES:

It should open a window that looks like this:

You can use this tool to automatically download updates for SSNES, its helper libraries and any/all of the various emulation cores. First off, you'll need to select which flavor of SSNES 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 SSNES 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 SSNES. This will fetch any updated SSNES executables, as well as fresh copies of all of the helper libraries (you can update SSNES 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 SSNES where to store and load its settings, via the SSNES config file path. Click Open, and then navigate to your SSNES folder and choose the file named ssnes.cfg. Likewise, for SSNES path, click Open, navigate to the same folder and select ssnes.exe.

Finally, the Emulator core path lets us select which emulation core we wish to use. So, click Open, navigate to the SSNES folder and look for your desired core that you downloaded from the Updater, such as gambatte-0.5wip1-x86_64.dll in my case. SSNES can be paired with any emulator core that conforms to the libsnes API specification, including but not limited to the original 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 SSNES. 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 SSNES forums or in the SSNES 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 SSNES' 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 SSNES and all flavors of libsnes. To install SSNES, 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 ssnes.cfg file is initially installed to /etc/ssnes.cfg (but can then be copied to and overridden by any ssnes.cfg file located in ~/.config/ssnes/) and the emulation cores install to /usr/lib/.

Using sloth86's Ambient Occlusion Tools in SF4

2011-10-05T12:58:00.000-07:00

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.

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.

Great!

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!

Pixel Shaders in Genesis, GBA, GBC Emulation

2011-09-26T08:33:00.000-07:00

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 https://github.com/twinaphex/genesis-next
cd megadrive-next/src/libsnes
make

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://github.com/Themaister/gba-next.git
cd trunk/platform/libsnes
make

For Gambatte:
git clone git://github.com/Themaister/gambatte-libsnes.git --branch libsnes
cd gambatte-libsnes/libgambatte/libsnes
make

For Final Burn Alpha (fba):
git clone git://github.com/twinaphex/fba-next-slim.git
cd fba-next-slim/src/burner/libsnes
make

Download Windows libsnes-fba binaries

The resulting libraries will all be called libsnes.so. 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):

SSF4AE - doshu's ULSM Tutorial

2011-09-19T12:42:00.000-07:00

Here's a more or less basic tutorial about how I built my Ultra Light Stage mod. The aspects that I won't cover are basic Gimp/Photoshop manipulations, building your own BGM selection and how to convert a TRN stage to any other stage. If need be, those aspects can all be learned quickly either by reading the SSFIV/AE wikis, by searching the net, or simply by thinking on your own and doing try/errors.
Also, the first part of the tutorial is way more detailed (both in text and pictures) than the last ones, since I wrote it a while back to explain how the Training stage edit works on the polycount forums.

Since I build my mod, a lot of progress has been made in the field of custom Training stage's templates, so instead of blindly followind this tutorial entirely, you should probably just take the parts you need and try to build even better stages than I did (not so hard IMO :p).

Finally, I have to insist that I'm (or was) a total n00b in modding, and that this tutorial might include some really weird and/or not efficient methods for expert modders. I'm repeating myself here, but better safe than sorry^^. Anyway, if you have a better way of doing things, share it! This tutorial will then hopefully be updated .

Ok, let's start with an overview of the needed tools (find those in the wiki and/or with google) :

SF4 Assets Explorer
The Gimp + dds mod
SFIVAM
hexadecimal editor HxD
Ryu's Classic Training Stage mod by hunterk

Quick overview of the whole process :

extract Ryu's Classic Training Stage's dds and observe how it's made
build your own dds from whatever art you find that seems fine (but do not forget to get the author's authorization if you want to share your work!)
do the hex magic
inject the dds : the stage is done!
build the 3 preview pics'dds : big, medium and small size
build the 2 kind of presentation text : Stage Select and pre-versus screen
inject the whole thing into the appropriate files
mute that annoying announcer !

Building your own stage
1. Basic explanations
  Ok, so here's a bit of explanation on how it works. As you'll see, it really needs only basic picture editing skill, and not anything fancy.
  
  First, let's look at the "cube" limitations : the edges (this stage was done by hunterk).
  
  As you can see, all the vertical sides of the cube are filled with the same part of the texture, making it "loop" when it reaches the end. The same with the floor/ceiling. In practice, it doesn't show that much, except when performing some Ultra's like Ryu's Metsu Shoryuken.
  But what is important here, is that because of that loop, the more the left and right sides of the texture looks alike, the less it will be apparent in the stage. In this case, it's almost "invisible".
  Secondly, here's the kind of file the stage's texture is made of:
  
  Basically, the "floor" part is upside, then comes a thin black line, and the the main background. What is important here for "good" results, is that the floor looks as much as possible like one, as it does from all the above examples (and in the WIP preview screenshot). If the original jpg image's "floor" isn't "straight", or is filled with different objects and such, the result might be awkward (or not, it depends).
  
  For example, let's first show the results from the 2 pictures above:
  
  All in all, except the crappy resolution problem, those stages look "good" : the floor is “floory”, and the edges of the texture look alike, so it should be pretty "invisible" while playing.
  
  Let's finish the basic explanations with a "difficult" file to work from (at least for my skills)
  
  That's it for the basic explanations.
2. Choosing some art and building a dds from it
  Basically, you'll want to work from a picture as high def as possible, even if the dds will only be 1280*800. Also, the scene should ideally be pretty empty in the “front”, thus allowing you to easily build the floor of your stage. It is possible to work from more difficult material, but I'll leave it to you to find how, explaining it here would be long and tedious.
  
  For my part, I worked mostly on feeling. Just look at the picture, copy whatever part you want to make the floor of without thinking too much about proportions, copy and paste it as a new image, then resize that new image at 1280*237. That's pretty much it for the floor.
  Return to the original picture, select the other part of it (Ctrl-I should do the trick if your previous selection was still active), copy paste as new image, then resize to 1280*553. That's it for the wall.
  Create a new black backgrounded 1280*800 image, copy paste the floor into it, position it up (using the arrows make it a breeze to do, no pixel precision needed). Do the same for the wall, except you position it down. There should be around 10 pixels left black in between.
  Flip the image horizontally (Image → Transform), then save as a .dds (just name the file whatever .dds when saving). Don't bother about the compression, it's not needed.
  Before injecting the newly created dds file, you need to make it the exact same size as the original one. To do that, just open both the original and the new dds file into your hex editor, and do the following :
  - on the original file : Ctrl-A ; End ; Ctrl-E ; choose 2EE080 ; Ctrl-C
  - on the new file : Ctrl-A ; End ; Ctrl-V ; Ctrl-S
  
  That should do the trick. Basically, you're copying what bytes are missing in the new file from the original one. All the files I created were always 2EE070 sections long, that's how you get the 2EE080 number. Should your file be a different size than that, you will have the adapt this number to that size so that both files are the same size at the end. This method doesn't work with new files bigger than the original though... (see how I'm a n00b in hex editing? Pretty n00bish I must admit, but it works! I have an idea why it does work, but I'll gladly hear some real explanation^^).
  
  A last word about applying filters on the dds befrore injecting it. The ingame look of the stage you built won't be exactly the same as the dds' look, so you might want to try and apply some filters. Here are the ones I used so far:
  - unsharpen: used mostly for high definition material, like most of the stage of the ULSM. I used it twice on each dds.
  - cartoon: used in combination with "Van Gogh" to make low definition material look ok-ish ingame
  Don't hesitate to try other filters too!
  
  Ok, you're good to inject to file into the .emz and test out your newly build stage!
Editing the Stage Select screen

This part is really easy, but quite time consuming. I'll first specify the particularities of each kind of file needed for the Stage Select screen (dds resolution : actual picture resolution (ratio) / type of compression needed):
- big preview picture: 1024*512 / 710*377 (1.88) / BC2/DXT3; the BLD stage needs a 1024*1024 resolution file (adapt the actual picture size accordingly)
small preview picture: 128*128 / 116*89 (1.30) / BC1/DXT1

Then the pre-versus screen:
- medium preview picture: 512*256 / 336*214 (1.57) / BC1/DXT1; BLD, KOR, AFX need a 256*256 image, adapt the actual picture size accordingly

And for the text in both screen (up left for the Stage Select screen, up right for the pre-versus'):
- 256*128 or 512*128 / Comic Sans MS Bold 34 (Place) and Arial Bold 36 (Stage name) / BC2/DXT3

To avoid you the pain of figuring out which stage's text needs which resolution, here's the list of the stages needing a 256*128 dds: AFR, RVR, AFX, VIE, JPN, VCN.

Another time consuming task is figuring which files you need to edit, so here's the list:

\ressource\ui\stage_select\stage_select.emz: for every big/small preview picture and Stage Select screen's text. Finding the small ones is easy, since the entry name corresponds to the stage name. The big picture/text is much more difficult to find, so here's a list to help you out (pic/pic/txt/txt; I guess you have to inject the new pic and text twice, in both entries, I haven't tried to do it at only one place...):
- - - BLD: I30 / I3E / I8A / I98
    - IND: I33 / I41 / I8D / I9B
    - KOR: I36 / I44 / I90 / I9E
    - AFX: I39 / I47 / I93 / IA1
    - LBX: I3C / I4A / I96 / IA4
    - USA: I3F / I4D / I99 / IA7
    - CHN: I42 / I50 / I9C / IAA
    - RUS: I45 / I53 / I9F / IAD
    - BRA: I48 / I56 / IA2 / IB0
    - AFR: I4B / I59 / IA5 / IB3
    - VIE: I4E / I5C / IA8 / IB6
    - JPN: I51 / I5F / IAB / IB9
    - EUR: I54 / I62 / IAE / IBC
    - SCO: I57 / I65 / IB1 / IBF
    - JPX: I5A / I68 / IB4 / IC2
    - LAB: I5D / I6B / IB7 / IC5
    - RVR: I60 / I6E / IBA / IC8
    - VCN: I63 / I71 / IBD / ICB
    - CNX: I66 / I74 / IC0 / ICE
    - BRX: I69 / I77 / IC3 / ID1
    - VNX: I6C / I7A / IC6 / ID4
    - TRN: I6F / I7D / IC9 / ID7
\ressource\ui\versus\versus\img#.emb.emz, where # is between 0 and 3: for everything pre-versus screen related. The entries are self explanatory, with JPN_name for the text part, and stage_JPN for the medium preview picture. Just take a look to find out which stage is where (the text and the picture entries can be in different files). Also, img3.emb.emz contains Boxer's name, so if you're using a JPN character's name mod, be sure to swap the original (Balrog) with is counterpart (M. Bison, to be found in some other file).

And finally, though I won't go through the hassle of explaining Gimp's image editing manipulations (a small hint about it though, be sure to use the game's original files as models for the shapes, especially for the small preview image; that way the result will fit perfectly into the game's screen), I'll throw a word about the halo thing around the text.
At first, I followed this tutorial. The result was good, but I came around a faster and better looking method after a while: follow all the steps until before applying the first Gaussian filter, then do a select all (CTRL-A), and apply directly a 10 point Gaussian filter. That way, you only have to apply one filter with one setting, removing the need to change the settings from 5 to 10 points every time. Finally, just follow the end steps of the linked tutorial.

Ok, now you're set, all that's left is to inject all of your files one by one into the game's files. A long and boring process if you're doing every stage at once, but the result is really worth it!
One last word about this part of the process: don't pay attention if the SF4 assets explorer preview looks messed up, it doesn't affect the in game result.

Mute the announcer
This is quite easy:

open \ressource\ui\sound\se\VERSUS_SE.csb with SSFIVAM
extract everything in a temporary folder ("unpack" command)
hexedit the files containing the sounds you want to delete by selecting all and replacing the data with zeros (listen to the files in AM beforehand, to found out the name of the sounds you want to delete)
then inject all the files inside the original file ("replace content with..." command)

There may be a better way, but that one worked great for me^^.

And that's it for the ULSM tutorial!

SSF4AE - Swapping Static Objects with sloth86's Tools

2011-09-19T05:36:00.001-07:00

Swapping static objects with sloth86's tools.
copyright sensibeat

sloth86's tools: http://aemods.pbworks.com/w/page/42053948/aetools#Sloth86sModelSwapTools

DDSREFEDIT32.exe
EMG2SMD.exe
EMGSWAP.exe
OBJ2EMG.exe (latest version: http://www.mediafire.com/?p1vvruy4ycy3ejt)

piecemonteeSF4explorerV0.37b.exe: http://sf4viewer.sourceforge.net/

With this method you can only swap static objects assigned to 1 bone.

First chose a .obj you want to swap:

Chose a character and extract the full model as a .obj with sf4explorer:

You'll have to edit the model in your 3D editor to fit the character:

¤ More infos about that part here: http://filthypants.blogspot.com/2009/08/beginners-guide-to-sf4-model-editing.html

¤ To open the .obj in 3ds max you may need to open it and save it in misfit model 3d first.

Now you have your model in place save it and open EMG2SMD.exe:

I want to swap my cap with zangief's hairs (15th #EMG -as viewed in sf4explorer-)

Open the smd in notepad and look for the number of the bone you want to link your object to:

in that case I want to link to the "head bone": #6.

¤ More infos on smd here: http://developer.valvesoftware.com/wiki/Studiomdl_Data

Now you can use OBJ2EMG.exe:

¤ To use a .obj from 3ds max in OBJ2EMG you may need to open it and save it in misfit model 3d first.

Then use EMGSWAP.exe:

We aren't done yet, it needs some textures (diffusion+normal map dds):

¤ See other tutorials to add dds to your col.emb and nml.emb...

Then use DDSREFEDIT32.exe (I renamed former new.emo to ZGF_01.obj.emo before this step):

That looks OK in sf4explorer:

Let's test in game:

edit:
I thought the bone ID# was in hexadecimal in the smb... it's in decimal sorry for the confusion, I erased that part.
You actually need to write it in hexadecimal when you do it manually, we'll see that in another tutorial...

edit 2: I knew I forgot something...

I didn't linked any material features in the .emm to my "mcap"

2 ways to do it:
1) the lazy way: edit the obj.emo in hexadecimal and change "mcap" by a material that could do the trick like "shoes" or "pants"

2) using NanjouJ's matedit tool, replacing an unused material (in that case "hair") by "mcap" and the features you want to use on it.
http://aemods.pbworks.com/w/page/42053948/aetools#NanjouJsMaterialsTool

Here's the final result with material features added (no more weird reflections):

Reinstalling GRUB2

2011-09-16T11:48:00.000-07:00

This has come up a million times (every time I reinstall Windows, in fact), and every time I have to search around online and try to remember how to do it. I figured this most recent time that I would just go ahead and write a blog post about it and be done with it, so here it is.

According to this handy page from the Ubuntu community documentation, there are a couple of ways to skin this particular cat. The one that worked best for me was to take an Alternate CD that I already had on-hand, boot into it, and choose 'Repair an Existing Installation' (or something like that) at the first splash screen (the one where you can check the CD integrity, run memtest, etc.).

Once it gets started, run through the options choosing the default keyboard layout, time zone, etc. When it asks you to choose a root, accompanied by a list of all of the HDD partitions, it appears you may choose any of them (I chose /dev/sda5 on this particular machine, which has Win7 in a primary partition and Ubuntu spread across 3 logical partitions). Then, once it kicks you to a command prompt, type:
sudo grub-install /dev/sda
That's it.

Other easy options that I didn't try include booting into a LiveCD session, then installing and running the boot-repair package (it didn't even show up in the apt-cache when I searched for it, so YMMV). In the program, choose the "First Repair" option and then reboot without the CD in the drive. A GRUB splash should show up proposing both Ubuntu and Windows.

Windows 8 Dev Preview on Lenovo X61 Tablet

2011-09-15T13:12:00.000-07:00

I downloaded Microsoft's Windows 8 Developer Preview the other day and decided to try it out on my Lenovo X61 tablet PC. NOTE: This is an older X61, running the Centrino Pro chipset (an older Core2 series chipset). For newer models, you might need to run Windows Update after installing to enable pen/touch input (thanks to reader taytor head for the info).

The trackpoint/eraserhead/navigation nipple/whatever works fine from the get-go, but the middle-button mousewheel emulation does not. It's easily fixed, though, by downloading and installing the driver from Lenovo. After this easy fix, though, I started running into some problems.

First off, my Centrino Pro chipset (Intel Mobile GM965 Express) graphics driver wasn't recognized by default, and every time I tried to install it manually, it failed with an error claiming that the chipset wasn't valid for the driver.

Knowing this to be false, I went and downloaded another copy of the driver from CNET (looks to be a Dell driver, based on some files contained within the driver package). This driver's installation utility failed with an error about an unsupported operating system, which I dealt with by right-clicking on it and going to the 'Compatibility' tab and choosing Windows Vista (no Service Packs) as the compatibility target. After that, the installer ran just fine. Now I have Aero and transparency and everything.

Out of the box, the system recognizes my stylus and allows for pen input and screen calibration. However, I wanted a few features that are only available from the official Wacom driver, so I downloaded it and tried to install it. The installation went fine, but upon reboot, the system no longer recognized my stylus at all. When I went to the control panels and clicked on the Wacom driver panel, it choked and failed with an error about how there were no compatible interfaces found on the system.... Luckily, after uninstalling the driver from my Programs list and uninstalling the drivers from the device manager, all is well again, though I'm stuck with the generic, MS driver.

Other than those hiccups, everything seems to be working well. The system is overtly similar to Windows 7, only with sharp corners and a little less transparency everywhere. Window borders are more opaque now, and they no longer have the Vista-style reflection/glare effects.

The 'ribbon' menu style has been adopted throughout the system and, while I don't really like it, I suspect it will grow on me, much like it did when introduced to Office 2007.

Before my video driver was installed, the Metro UI was horribly slow and took several seconds to transition to and from the traditional desktop view. However, with the driver installed, everything is snappy and attractive.

At this point, the Metro UI is sort of useless and is just a glorified launcher, but MS intends to have the launcher squares configurable and with live updates (i.e., your buddies list will update with who is online, the weather application will show live weather, etc.). However, applications will have to be written especially for the Metro UI using a new API, and MS intends to charge developers 30% of revenue for Metro apps, just like Apple does with their App Store.

If you have any questions about Windows 8 in general or its use on this computer, specifically, drop me a comment.

CCSM Locale Not Supported Error

2011-09-13T16:10:00.000-07:00

My HTPC's compizconfig-settings-manager (ccsm) started failing to launch whenever I clicked on the link, so I tried to run it from the terminal to see what was up. When I did, I saw that it was coughing up this error:

(ccsm:8581): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
Info: No sexy-python package found, don't worry it's optional.
Traceback (most recent call last):
  File "/usr/bin/ccsm", line 38, in 
    import ccm
  File "/usr/lib/python2.5/site-packages/ccm/__init__.py", line 1, in 
    from ccm.Conflicts import *
  File "/usr/lib/python2.5/site-packages/ccm/Conflicts.py", line 26, in 
    from ccm.Constants import *
  File "/usr/lib/python2.5/site-packages/ccm/Constants.py", line 72, in 
    locale.setlocale(locale.LC_ALL, "")
  File "/usr/lib/python2.5/locale.py", line 476, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Turns out the fix is pretty simple. Just open up a terminal and type:

LC_All=en_US.utf8
Lang=en_US.utf8
ccsm

one after another.

Unfortunately, this fix doesn't seem to stick, so you have to do it every time you want to launch.

Intermediate Guide to SF4 EMG (Model) Swapping

2011-08-25T18:51:00.000-07:00

Sloth86 has cracked model manipulation in SF4 wide open. It's now possible to swap models from character to character and costume to costume in a fairly consistent manner, thanks to sloth86's research. Additionally, he was nice enough to write simple, straightforward graphical tools that extend this ability to almost anyone. Just to be clear, though: this procedure often produces strange results, especially with respect to animations. Sometimes these results can be fixed through model editing, sometimes not.

In this tutorial, we're going to use sloth86's methods to take an EMG model from one character and replace it with an EMG model from another character.

First things first, lets get all of the tools we'll need. This is a pretty advanced procedure, so we're going to need piecemontee's SF4Viewer (aka, Asset Explorer), Kensou's Tool(s) and Sloth's tools, specifically, EMGSwap and DDSREFEDIT. Once you have those tools downloaded and organized, we're ready to get started.

First, identify which model you want to move and where you want to put it. I'm planning to take Guy's head (donor model) and place it on Ryu's body (recipient model).

Once you've got it all planned out, open both models (for me, GUY_01.obj.emo and RYU_01.obj.emo) in the Asset Explorer and find the desired objects--in my case Guy's 8th EMG (counting each model, starting from the top in the Asset Explorer's display)--and I'm going to replace Ryu's 12th EMG. The recipient's numbers are important, so write it/them down.

Now, select the donor object, right-click and choose 'Raw dump,' name it something informative (I chose face.emg) and click 'save.'

Next, armed with our model files and numbers, place both the donor *.emg file and recipient *.obj.emo file into the same directory as EMGSwap and double-click on EMGSwap to run it.

This window should pop up:

In the field labeled "Input EMO file," type the name of the recipient model, in my case RYU_01.obj.emo. Then, in the field labeled "EMG # to swap out," type the number of the recipient model you wish to replace, in my case 12 (for Ryu's 12th EMG model, the face). Next, in the field labeled "EMG file to swap in," type in the name of our raw-dumped donor model, in my case face.emg. Finally, in the field labeled "Output EMO file," we'll just leave the default 'new.emo' for now (we'll rename it to replace the old model later, but in the meantime, we don't want to mess anything up before we're sure it's cool).

Click 'Go' and cross your fingers. If all goes well, you should see a window like this pop up:

Looks good so far.

Now, lets check out our Frankenstein's monster by opening the 'new.emo' file in the Asset Explorer:

Yeesh, looks pretty freaky. Since Guy's head was sized and positioned significantly differently from Ryu's, we're going to have to change some things up to make it look normal again.

So, still in the Asset Explorer, lets select our newly imported model, right-click and choose 'Extract...' from the menu. Name it something informative--like face.obj--and click 'save.'

At this point, you might be asking yourself, "if I'm extracting and converting into an obj anyway, why didn't I just export from Guy's model and import straight into Ryu's model in the Asset Explorer, skipping all this EMGSwap bullshit?" Well, smarty-pants, most files in AE (including the *.obj.emo files we're messing with right now) include an index that includes the location and size of each and every file contained within. The Asset Explorer uses this index to determine what can and can't be extracted/injected safely.

However, sloth86's EMGSwap tool rewrites this index for us, so the Asset Explorer can safely extract/inject our borrowed models once EMGSwap has done its thing. Perhaps someday that same functionality will be integrated directly into the Asset Explorer (it's open source, after all), but that day is not today.

Anyway, so we've gotten our model swapped in, but it looks like crap and we'll need to use model editing to fix it. I'm not going to spend a lot of time on this part, since you should already know about model editing enough to fix things yourself. For me, Guy's head was the wrong size, so I needed to enlarge it and move it around a bit. I really should edit Ryu's neck to meet the head, too, but you get the idea...

Alright, with my edits in place, the model looks okay, but you'll notice that the skin looks all white and pasty. That's because it's looking to Ryu's first DDS texture, which corresponds to--you guessed it--his duffel bag. This is actually convenient for my purposes, since I can just replace the duffel texture with my donor texture. Thus, I won't need to edit a bunch of DDS references using sloth86's DDSREFEDIT tool, but you probably will (hence, why I included it in the tools you'd need to download).

I'm only going to use it a little, but I'll try to tell you more about it when the time comes.

In the meantime, we need to create some new texture and normal map containers to go with our new model. To do it, we'll use Kensou's sf4tool, just like in this earlier tutorial I made.

Open your donor's *.col.emb and *.nml.emb files in the Asset Explorer, find the textures that correspond to your donated model, right-click and choose to 'Extract...' them. Name them something informative (I used 'Guy.dds' and 'Guynmap.dds') and click 'save.'

Next, open your recipient's *.col.emb and *.nml.emb files in the Asset Explorer an extract *ALL* of his or her DDS textures. Be sure to name them something informative so you can remember which order they're stored (1.dds, 2.dds, etc. and 1nmap.dds, 2nmap.dds, etc. work well).

Now, as per the aforementioned tutorial, create new *.col.emb and *.nml.emb files with your donated textures in the first position. (I actually replaced my recipient's first textures, so the order for mine was Guy.dds, 2.dds, etc. and Guynmap.dds, 2nmap.dds, etc.) EDIT: I used the first position, but apparently the *last* position is more likely to work...?

At this point, you would run the DDSREFEDIT tool and input the number '0' into the 'new texture map' field and '1' into the 'new normal map' fields (assuming your recipient only had a single texture to begin with; this isn't the case with shoto original costumes, though, so count the textures if you need to, according to the instructions in the program; I had to use '5' for the normal map number), your modified *.obj.emo file in the 'Input EMO file' field, and the number of your recipient's replaced model in the EMG # field (in my case, it was '12'). You would then check the box for '+1 to every other normal map references' (this last bit was unnecessary for me because I replaced the duffel bag normal map with the donated normal map).

This was my result:

Anyway, if this last part seems confusing, don't worry about it. I'll be making another tutorial that goes over the texture reassignment tool using a more typical example in the future. In the meantime, try your best, share your work and ALWAYS MAKE BACKUPS.

Test Driving Oneiric Ocelot on ThinkPad X120e

2011-08-12T09:38:00.000-07:00

It's that time again. With another Ubuntu release looming on the horizon, I decided to upgrade my netbook to the latest daily build (8/12/11) of Ubuntu 11.10 Oneiric Ocelot, which is still in alpha stage.

Installation

Installation was unchanged from 11.04, so much so, in fact, that it even says "Welcome to Natty Narwhal" :P

As with Natty, installation was quick and easy, with the option to download updates in the background as you go. As before, personalization questions were presented *after* installation had already begun, which saves even more time.

First Impressions

The login screen has changed a bit, and now looks really snazzy, with a stylish dot motif in the background. There's an option to select a Guest Account, along with the option to use the new 2D/non-accelerated Unity desktop, which I believe is powered by the Enlightenment libraries. This 2D desktop supports true transparency, which is nice.

Drivers

The jockey-powered "Additional Drivers" utility automatically found the binary driver for my wireless, which is the nonstandard Broadcom chipset option, so all I had to do is tell it to activate it. CORRECTION: My wireless driver was enabled, but not working. On returning to jockey, the driver was listed as not installed and if I tried to enable it, it would give me the error:

SystemError: E:Unable to correct problems, you have held broken packages.

This suggests that my packages were installed, but somehow got messed up. To fix it, I had to find out which packages for my chipset were installed, by typing:

dpkg -l | grep roadcom

(notice, I searched for 'roadcom,' which will catch packages with both 'broadcom' and 'Broadcom' in the title and/or description. This is important, as the bcmwl-kernel-source package will not show up if you search for 'broadcom' alone.) Then remove them entirely by typing

sudo apt-get purge [package names from the previous command]

Reboot, then try the 'Additional Drivers' utility again. It should successfully enable the driver, then you can reboot again and everything should be working properly.

If you got the standard chipset, it should use the open source driver by default. The default video driver is the Gallium-3D-driven open source driver, but I chose to install the proprietary fglrx driver from AMD via the driver utility.

Audio seems fine and my HDMI audio hardware and output were both recognized from the start. The headphone jack also properly mutes the internal speakers when headphones are plugged in, which is an improvement over my experience with Natty.

Waking from suspend seems fine, too, though hibernation still seems to be a no-go. :(

Applications

The default email client is now Thunderbird, which works well with Firefox, the default browser, and the default music client is now banshee (this may not have been a new change; I can't really remember...).

The built-in search tool for Unity is much improved, with little icons down at the bottom of the window for choosing whether to search everything, just files and folders, just applications, or just search your music collection.

Everything seems to be fine so far, a solid improvement over Natty on these machines. I'll post back if I run into any problems. If you have any questions or experience any problems, post a comment!

My DIY Backloaded Horn

2011-07-31T17:05:00.000-07:00

Over the past 6 months or so, I've been researching and ultimately building a pair of backloaded horns. At the time of this writing, I've only actually finished one of them, but I decided to go ahead and make a post about it.

My Phase Technology Teatro 7.5s sound great, but they're pretty weak on the low-end. I've been supplementing with a shitty powered subwoofer scavenged from a boxed 5.1 surround system, but it just doesn't cut it, unfortunately, so I decided to build some speakers that would cover it a little better.

Since getting my upper-mid horns and hearing their clarity and definition, I wanted to go with another horn for the bass, if possible. I've seen a lot of really crazy, gigantic basshorns on the internet and wanted to avoid the size that would be required to reach below 100 Hz with a compression driver--not to mention the batshit crazy prices that large-scale compression drivers go for on eBay and Audiogon--so I decided to look into backloaded horns.

Ideally, a horn should be as long as the wavelength of the lowest frequency you wish to reproduce, with a mouth of approximately that same diameter, thus bass horns have to be gigantic to reach low frequencies. You can cheat a little, though, by placing the horn against the floor and/or wall of your room, which lets you cut the wavelength requirement by half for each surface, as it uses the walls/floor as if they were a part of the horn. Furthermore, backloaded horns are typically folded horns, which lets them squeeze a lot of length into a relatively small package. Finally, by starting with a large cone driver, your required horn length is reduced further still.

I used this 8" driver for the horns, based on their high sensitivity, though these would also be an excellent alternative. If you don't plan to supplement the horns with a tweeter like I intend to do, you might also consider using a full-range driver, like this one, though it is obviously more expensive. This driver is another good option if you want to play at high volumes, due to its high power handling and *huge* cone excursion.

I came up with my own design for the horn itself, based loosely on some designs I found around online. However, most of the designs I found have the mouth of the horn opening into the wall, which I was afraid would deaden the sound, based on how directive my upper mid horns are. So, I tweaked those designs a bit and ended up with something I could construct out of a single sheet of 4'x8' of wood (MDF [medium-density fiberboard] is the best for speakers, but it's heavy, expensive and rough on your tools; particleboard is a good compromise, IMO, insofar as it is very cheap, but with many of the same characteristics as the more expensive MDF; plywood works, too, but it's ugly).

I used 1/2" particleboard, though TBH, 3/4" would probably have been a better choice, both for rigidity and sound isolation. The sides are 2'x4', the back is 1'x4' and everything else is 1'x2' (i.e., the front, the top/bottom and the interior partitions; the last piece is cut in half and glued together at a right angle). I'm not going to go into much detail about the actual construction, since I'm a shitty carpenter and I'm sure you can find better instructions on box-making online than I could ever provide. Anyway...

Glue the pieces together using wood glue, and don't be afraid to really gob it on. You want it to seep into all of those little nooks and crannies in the wood and form a good seal. You can see the excess squeezing out from under the board in this pic:

To be sure that the junctions are all airtight and won't be leaking air into each adjacent chambers, you can follow behind with silicone caulk or "liquid nails" formulated for wood, which is what I used:

If you look closely, you can also see the right-angle brackets I used to reinforce the box structure.

After all of the interior structure is glued solidly into place, you can glue the other side panel to seal the cabinet shut. I used the liquid nails instead of wood glue to seal it, with a bunch of cinder blocks, books, records, etc. piled on top to get a good connection while the goo dries:

One thing to remember before sealing the cabinet: go ahead and thread some speaker wire through because it'll be much easier now than if you wait. If you do forget (like I did, actually), you can tie the wire around something (I used my dog's Kong toy), drop it into the speaker hole and then flip the whole thing around until it pops out the mouth of the horn. This is harder than it sounds, though, because these horns are gigantic and heavy as shit.

Another bit of advice, do your painting *after* your gluing (unlike me), so you don't have to worry about excess glue spilling over onto your fancy paint job.

Most of the projects I've seen online make a big deal about filling any cavities with sand or kitty litter so they don't turn into resonance chambers, but I don't really notice any problems and I did not do it. Of course, YMMV.

Anyway, here's the finished product:

You can see my small upper mid horn perched on top. You can also see the speaker wire dangling out of the mouth of the horn, since I haven't purchased proper binding posts yet (maybe never...).

As far as the sound, the bass response is considerably more potent than I expected. The driver works as a direct radiator (so better quality drivers will make a noticeable difference in sound quality), while the low frequencies bounce around inside and bellow out of the horn's mouth. The horn produces some of the clearest, most defined bass I've ever encountered, though it is definitely lacking above 1 kHz. That in mind, I intend to pair it with either this tweeter or this one.

One last picture of the finished horn, this time from the side:

The depth is really what makes these guys huge. Special thanks to my wife, who is gracious and long-suffering :-P

How to Create High-Resolution Textures in SSF4AE - PC

2011-07-28T15:12:00.000-07:00

This tutorial covers how to create *.col.emb files from scratch using Kensou's Tools. These files can contain any number or variety of DDS textures of any size/resolution or compression type (DXT*). The most common usage for this is to create textures that are higher resolution than the default textures, but it can be used for other purposes, as well.

Sensibeat's tutorial for making high-resolution textures is much more informative, but requires a level of comfort working with hexadecimal code and calculations. This method is considerably easier but you should still try to understand sensibeat's instructions since the same techniques are helpful in other aspects of modding.

Anyway, lets get started. All you need are piecemontee's Asset Explorer and Kensou's sf4tool.

Step 1. Open a *.col.emb file in the Asset Explorer and extract the DDS textures. Name them something simple that reflects the order they're supposed to come in (I like to use 1.dds, 2.dds, etc.).

Step 2. Open the DDS textures in a paint/editing program, such as Photoshop or GIMP, and scale them to the desired resolution. In this case, I'm scaling a bunch of 512x512 textures up to 1024x1024.

Step 3. Save the textures as new DDS files with any compression you like. This is your opportunity to change, for example, DXT1 textures into DXT5 to allow for semi-tranparency.

Step 4. Now, open the directory for Kensou's sf4tool.exe (NOT sf4toolnew.exe). If you don't have a directory named 'emb' in there, create it now, and then put your enlarged DDS textures into it. Next, run sf4tool.exe by double-clicking it.

Step 5. In the big file-directory pane on the upper-right of the window, double-click on your emb directory and click on the left-hand button underneath the big pane. The smaller pane to the left should populate with your files. Put them in the proper order by changing the filenames in the smaller pane (you can just click in there and type) and then click on the right-hand button to bundle them all together.

Step 6. Back in your 'emb' directory, you should have a new file called 'newpack.emz.' Rename it to match the col file you're trying to create, in my case GKI_01_01.col.emb.

All set! The *.col.emb file you're left with is formatted a little strangely and contains some garbage hex in the index and at the end of the file, but AE doesn't seem to care, so neither do I. :P

You can now use the Asset Explorer to extract/inject textures from your new file using the new textures as a base for mods.

Sensibeat's cmn File Size Editing Tutorial (Also Applicable to Other emz Bundles)

2011-07-07T21:18:00.000-07:00

cmn.emz file size editing tutorial

So now we want to copy some file in our cmn.emz.

We need the Length of the file.
Calculate it or easier, just open the file in the hexadecimal editor, the last offset number is our Length.

I want to "inject" an edited HWK.fce.ema

Last offset is 7BA97 so our Length will be 97 BA 07 00

Note that it's smaller than ZGF.fce.ema but it works the same with bigger files.

Now let's find the ZGF.fce.ema location (search works well too but let's use our new knowledge)
TB = 9C5C28+38 = 9C5C60
The true beginning of the #EMA is at offset 9C5C60

I select the full file

I overwrite it with the HWK.fce.ema file

I insert blanks (00) to make the next #EMA begin at the start of a line (like it was)

Now I know there are 3 files after the one I inserted (Thx to piecemontee's AE) that were moved by my changes.
I need to check the TBs of the #EMA #BAC #BCM + the TBs of the files at the end:

#EMA TB: A41700
A41700 - 40 (CL) = A416C0 (RL)

#BAC TB: A5B6A0
A5B6A0 - 48 (CL) = A5B658 (RL)

#BCM TB: A826B0
A826B0 - 50 (CL) = A82660 (RL)

ZGF.skl.emo TB: A843E0
ZGF.skl.emm TB: A843EC
ZGF.obj.ema TB: A843F8
ZGF.fce.ema TB: A84404
ZGF.cam.ema TB: A84410
ZGF.bac TB: A8441C
ZGF.bcm TB: A84424

We need to enter the Length of the new fce.ema (other lengths didn't change), and new RLs and TBs backwards:

Et voilà.

Sensibeat's Model Swapping Tutorial (Updated)

2011-07-07T21:07:00.000-07:00

Updated Version:

Swapping objects (SSF4AE)

piecemonteeSF4explorerV0.37b: http://sourceforge.net/projects/sf4viewer/files/0.37 (Console files format support - SuperSF4)/piecemonteeSF4explorerV0.37b.exe/download
hexadecimal editor HxD (free): http://mh-nexus.de/en/downloads.php?product=HxD

I'll swap cammy's first costume hat with the 2nd one.

In sf4explorer I open CMY_02.obj.emo and I "raw dump" (not "extract") the #EMG (cap_lether) (cap_line)
(I name it CMY_02.cap.emg)

I open CMY_01.obj.emo and CMY_02.cap.emg in HxD

In CMY_01.obj.emo I search for the #EMG (F3) containing the "cap"

(note the offset: 670C0)

I go to the next #EMG (F3)

I place the cursor just before that #EMG and I use the "select block" fonction (CTRL+E) using the start offset I noted (670C0):

OK:

(Note the Length: 63F0)

The #EMG selected in CMY_01.obj.emo, I now "Select All" (CTRL+A) CMY_02.cap.emg and I copy it (CTRL+C).

(Note the Length: 50C0)

I paste it (CTRL+V) over the #EMG selected in CMY_01.obj.emo

OK:

Let's do some math in hexadecimal:

Code:

63F0 (Length of former #EMG) - 50C0 (Length of new #EMG) = 1330

1) I need to substract 1330 in the index at the start of the file for every offset of the #EMGs for every object coming after the "cap", as the new object is smaller than the old one.

By opening CMY_01.obj.emo in sf4explorer, I can count that the cap is the 10th #EMG so I have to substract 1330 from the 11th #EMG to the last one (22th #EMG).

The index of the #EMGs starts at offset 28
From there each block of 8 digits is the offset of one #EMGs minus 30 written backwards 2 digits at a time ("little endian"):
01 23 45 69 in little endian will be 69 45 23 01 in big endian

So I'll have to edit the 12 index entries from offset 50 (#EMG 11) to 7F (#EMG 22)
I substract 1330 to the offsets (calculating in hexadecimal and reading offsets in "big endian"):

Code:

00 06 D4 80 - 1330 = 00 06 C1 50  00 06 E4 50 - 1330 = 00 06 D1 20  ...  00 0A F1 60 - 1330 = 00 0A DE 30

And I rewrite them backwards ("little endian")

2) I need to substract 1330 to 2 more offsets related to the 2nd part of the obj.emo file:

Code:

00 0C A7 00 - 1330 = 00 0C 93 D0  00 0C A5 90 - 1330 = 00 0C 92 60

Let's go to the 2nd offset (minus 20 written backwards, so 00 0C 92 60 + 20 = 00 0C 92 80), using the goto fonction (CTRL+G):

Here's another index I need to substract 1330 to:

From offset C9280 to C92D7, just before the first readable datas (hand_env):

Code:

00 0C A5 E8 - 1330 = 00 0C 92 B8  ...  00 0C A6 D1 - 1330 = 00 0C 93 A1

Save and that's it for the 1st part:

Next I'll show how to add dds to the col.emb and nml.emb files and how to link objects in the obj.emo file to the right dds.

1) Adding dds to the col.emb (and nml.emb) files

In sf4explorer, I extract the dds for the cap from CMY_02_01.col.emb
That I name CMY_02_01.dds:

I open CMY_01.col.emb and CMY_02_01.dds in HXD

In CMY_01.col.emb, I add a line of "00" at the end of the index, here:

I change this "04" at offset 0C (former number of dds):

Into "05" (new number of dds):

And I edit the index because I moved all the offsets by 10 with my line of "00":

I add another line of "00" at the end of the file, here:

(Note the starting offset of the new dds will be: 155850)

I "select All" (CTRL+A) CMY_02_01.dds and copy it

(Note the Length: 555F0)

I paste it at the end of the file (after the line of "00"):

Then I go back to the start of the file to enter the starting offset of the new dds minus 40 writen in "little endian"
(40 = offset where I'll write the new index entry)
00 15 58 50 - 40 = 00 15 58 10 ("big endian")
That gives in "little endian":

Now I add the new dds length written in "little endian" (00 05 55 F0):

Save and do the exact same thing with the normal map dds in CMY_01.nml.emb, adding the normal map dds that contains the cap from CMY_02.nml.emb

2) Linking objects in the obj.emo file to the right dds

dds are ordered from 0 and the normal map dds follow the texture dds, so if you add 1 texture dds, every normal map dds will change number.
I have now 5 texture dds from #0 to #4
and 5 normal map dds from #5 to #9

I open CMY_01.obj.emo in HxD and do a search on "#EMG" (F3)
Each #EMG has those kind of data outlined here:

They contain the links to the dds:

The numbers in red are links to the texture dds
The numbers in green are links to the normal map dds

I have to change all the links to the normal map dds for the 22 #EMG according to the new order of the dds
(I just have to add 1 to every normal map link as we added 1 texture dds)

And edit the "cap" #EMG to link it to my 2 new dds #4 and #9:

Save and it's over.

Original Version:

Let's put Ryu's hairs on Akuma's (a.k.a. Gouki).

preparation:

From GKI_02.obj.emo I dump and rename (included in swap obj.rar):

GKI_01.bsr

GKI_01.nml.emb

GKI_01.shd.emo

They'll be used in kensou's sf4tool to repack the file.

From RYU_03.cos.emz I dump the hair emg file that I rename as RYU_03.hair.emg (included in swap obj.rar):

Open GKI_02.obj.emo and RYU_03.hair.emg in HxD:
The hair being the last emg of GKI file, we can get the information on it's beginning and ending from these:

Code:

offset 24 = offset of the list of offsets of names following the last emg:
00 0B A2 70 + 20 = 00 0B A2 90 so the emg finishes at [COLOR="red"]00 0B A2 8F [/COLOR](1 before)
offset 58 = 1st offset of last emg (hair):  00 0A 68 D0 + 30 = [COLOR="red"]00 0A 69 00[/COLOR]

Let's use the "Select block" option in HxD:

Now select all of the RYU file and copy/paste it over GKY's selection:

OK:

Notice the 2 offsets that will need to be rewritten at the beginning of the file:

Code:

00 0C 01 70  -20 = 00 0C 01 50  -> backwards: [COLOR="red"]50 01 0C 00[/COLOR] @ offset 24
00 0C 02 20 -> backwards: [COLOR="red"]20 02 0C 00[/COLOR] @ offset 10

Then the 2 offsets at the beginning of the file:

So it's good for the emo's references.

Now let's take a look at the emg's references:

43 -> former emg is 42
01 -> number of the 2nd texture dds
05 -> number of the 2nd normal map dds

Save and Rename the file as GKI_01.obj.emo

Put it in a new folder with:

GKI_01.bsr

GKI_01.nml.emb

GKI_01.shd.emo

and only those 4 files.

Open kensou's sf4tool and go look for your file path in the upper right, then click the left button under the big window:

Notice the files obj.emo and shd.emo are swapped.
Rewrite them in the right order (obj before shd) and click the right button:

Done.

Rename the newpack.emz into GKI_01.cos.emz and test it ingame with the GKI_01_01.col.emz provided (2nd costume 1st color file edited to be played as 1st costume):

You've got Akuma with Ryu's hairs.

For swapping smaller objects:

Basically you just have to copy/paste your emg and fill the rest of the former emg with 00's. Then there're just the emg number and the dds references to change. So the swap can be done on the .cos.emz directly.

Sensibeat's .emg File Structure Tutorial

2011-07-07T21:00:00.000-07:00

From RYU_03.cos.emz I dump the face emg file that I rename as RYU_03.face.emg (included in swap obj.rar):

Notice that the emg is composed of 4 objects sharing 1 name.

.emg file references

Let's take a look at RYU_03.face.emg in HxD:

offset 04 to 07:

Code:

00 01 01 43

number of this emg, former is 00 01 01 42, next is 00 01 01 44

offset 10 to 13:

Code:

00 00 02 C7

appears on every emg, may be the marker to the starting point of every later offset references

offset 14 to 15:

Code:

00 01

number of object's name(s)

offset 1C:

Code:

00 50

no idea what those datas are

offset 20 to 21:

Code:

06 66

number of vertex (666 in hex = 1638 in dec)

offset 2E:

Code:

00 40

appears on every emg, no idea what those data are

offset 24 to 25:

Code:

00 00 39 64 (+ 10 = 39 74)

relative offset (couting from offset 10) of another part of the emg

offset 2A to 2B:

Code:

00 04

number of objects

offset 2C to 2D:

Code:

00 70 (+ 10 = 80)

relative offset (counting from offset 10) of the list of relative offsets of the objects

offset 30 to 5F:

no idea what those datas are

offset 60 to 63:

Code:

00 00 00 54 + 10 = 64

relative offset (counting from offset 10) of the 1st object's name dds references (only one here, more references here in case of more objects)

offset 64 to 7B:

Code:

02 00 00 00 00 [COLOR="red"]02[/COLOR] 80 3F 22 00 80 3F 00 00 00 00 00 [COLOR="red"]07[/COLOR] 80 3F 22 00 80 3F

dds reference
the 1st number in red points to the texture dds
the 2nd number in red points to the normal map dds

dds are ordered from 0 (first texture dds) and the normal map dds numbers follow the texture ones
Ryu has 5 texture dds numbered from #0 to #4 and 5 normal map dds numbered from #5 to #9
#2 is the 3rd texture dds
#7 is the 3rd normal map dds

offset 80 to 8F:

list of relative offsets (counting from 10) of the objects

00 00 00 80 + 10 = 90     1st object
00 00 20 50 + 10 = 20 60  2nd object
00 00 29 D0 + 10 = 29 E0  3rd object
00 00 38 80 + 10 = 38 90  4th object

offset 3974: (given at offset 24)

offset of the beginning of the second part of the emg, that I have yet to understand...

Sensibeat's cmn.emz File Structure Tutorial

2011-07-07T20:54:00.000-07:00

cmn.emz file structure

I extracted ZGF.cmn.emz in piecemontee's SF4 AE and opened it in my hexadecimal editor:

I highlighted the references for each data, in bright colors the Relative Location and in faded color, the Length.
So the 16 characters in red are references for #EMO, the 16 in orange are references for #EMM ... etc

You have to know that those values are read backwards (2 characters at a time)

In the case of #EMO, let's look at it's Relative Location (in bright red), we read: 60 00 00 00
It means the Relative Location is 00 00 00 60 (60)

The Rule is: Relative Location (RL) = offset of True Beginning (TB) - offset of Current Reference Location (CL)

We have RL: 60 and CL: 20
TB = RL+CL = 60+20 = 80 (easy one but for later calculations remember we're in hexadecimal)

The True Beginning of #EMO is at offset: 80

Let's try with #EMM:
We read: E8 8D 02 00
Meaning our RL is: 00 02 8D E8 (28DE8)
We have CL: 28
TB = 28DE8+28 = 28E10

The True Beginning of #EMM is at offset: 28E10

Now let's take a look at our #EMO's Length (in faded red, 1st screen), we read: 88 8D 02 00
It means the length of the file is 00 02 8D 88 (28D88)

The Rule is: Length (L) = offset of True Ending (TE) - offset of True Beginning (TB)

We have L: 28D88 and TB: 80
TE = L+TB = 28D88+80 = 28E08

The True Ending of #EMO is at offest: 28E08

The last references are the True Beginnings of the files names at the end of the cmn.emz file:

For ZGF.skl.emo we can read: 90 D0 A8 00
Meaning its True Beginning is at offset A8D090

Sensibeat's Col-based Transparency Tutorial

2011-07-07T20:36:00.000-07:00

So, as many people are asking, and because it may be difficult to find every informations in the SF4 modding thread (31 pages already), I translated a tutorial I made some time ago on a french forum.

I used Sakura as an example.

To make transparency only using col.emz file, 2 steps are required:
- editing the col.emz file with a hexadecimal editor
- editing the Alpha layer of the dds where the texture is

1) edit the col.emz file

First I use piecemontee's SF4Explorer to identify the objects names and find them easier in the hex-editor

link: Free File Hosting Made Simple - MediaFire (you can get a newer version but this one is enough for names)

Reminder: to see objects names in SF4Explorer we are going to look at the cos.emz file, but it's the col.emz file we are going to edit (both are linked).
This step isn't required, but it's such easier when you know the true names of things, instead of having to look for them one by one, doing blind tests...

Ok... there the skirt was obviously "Skirt", but "Hatimaki" for her hairband was quite harder to figure...

Now you know the name of the thing you want to edit, open the col.emz of your mod (not the original col.emz, the unarchived one -dat, emb, name it... I rename mine .emz just after I unarchive them to .emb with quickbms-) under a hex-editor and do a search on that name:

Now scroll down a bit to the line "BrushA":

See those 40 characters outligned? You'll have to edit them:

For full transparency (removing objects, holes, ripped clothes) change them by those 40:

(I'll test on Sakura's skirt)

For semi transparency (Rose's pants) change them by those 40:

(I'll test on Sakura's hairband)

Ok, now that first step is done, save your col.emz and let's edit that texture.

2) edit the .dds file

Firstly what is an Alpha layer?

It's a layer in addition to basic color layers (RGB) that will create transparency (a white layer without colors, only black & white -and shades of grey-).

You find it here in Photoshop:

If it's here, no problem, your .dds file is in DXT5 format.
If it isn't there, the .dds file should be in DXT1, you'll have to add one yourself.

To know the DXT format of your .dds files I recommend downloading Windows Texture Viewer from the NVIDIA site: it shows the DXT.
link: Windows Texture Viewer

To show you the effect of semi transparency, I put a big rectangle with a gradient from white (visible) to black (invisible) on Sakura's hairband:

(on screen: Alpha layer alone)

To show you full transparency, I draw some simple shapes on her skirt:

(on screen: RGB layers and Alpha layer displayed together: the black of the Alpha layer is shown in transparent red under this display mode in Photoshop)

Then I inject the .dds back in the col.emz file...

And here is the result:

Have fun!

Credits goes to sn00pee for all his finds on the subject.

edit:

*forgot to mention an important thing:
Full transparency works if you save in both formats, DXT1 1bit alpha or DXT5.
Semi transparency only works if you save in DXT5.

sn00pee (again) found a way to inject bigger files in .emz without crashing the game here.
(I think the guy that created Rose Ninja used that method on the *cough*second color*cough*)

SSF4AE PC Moveset Swap Tutorial

2011-07-06T08:22:00.000-07:00

Thanks to Capcom's decision to forego emz containers and their associated headaches, moveset swaps are extremely easy to do now and they're not plagued by the "monkeyface" problem we all know so well.

Here's how you do it:
Step 1: Make a backup of your AE installation. If you mess something up, this will save you a lot of time, I promise.

Step 2: Pick 2 characters: 1 whose moveset we'll be taking (the donor) and 1 who will be receiving those moves (the recipient). For this example, I will use Hakan as the donor and Ryu as the recipient (i.e., Ryu with Hakan's moveset).

Step 3: Go to the resource/battle/chara directory and find your donor's folder, in this case HKN. In this folder, copy all of the files from HKN.cam.ema down to HKN.vfx.ttex.emz EXCEPT for HKN.fce.ema and copy them somewhere (a working folder where we have write permissions is appropriate).

Step 4: Rename all of those files we just copied to match our recipient's character prefix, in this case RYU. Now, go back to resource/battle/chara and copy them into our recipient's folder, overwriting the ones that are already there (it's cool, you backed everything up anyway, right? Right??).

Step 5: Now, this is the key step: navigate to your donor's "latest" moveset files, which are located in dlc/03_character_free/battle/regulation/latest/ for normal characters (I'll update this post with the AE character's locations when I get home). Take the donor's bac and bcm files, in this case HKN.bac and HKN.bcm, copy them to our working directory and rename them to our recipient's character prefix.

Step 6: Finally, we take our renamed bac and bcm files and drop them into our recipient's folder in dlc/03_character_free/battle/regulation/latest/ (assuming they're a normal character and not AE-specific), overwriting what's there.

That's it. All done!

I'm going to explain a little bit about what we've just done, so read over it if you're interested:

The actual moves and animations are stored in the .bac and .bcm files, which were previously components of the *.cmn.emz bundles in vanilla SF4. When they were bundled, we had to open the entire bundle in a hex editor and find the desired files and names to edit manually. However, since Capcom stopped using the bundles, we can just rename the files and be done with it.

Now, you'll notice in step 3 we omitted the *.fce.ema file, which contains the character's face animation data. By doing so, we've let Ryu--our recipient--keep his original face animation data, thus avoiding the monkeyface for the most part.

Last, I wanted to mention the various revisions of moveset files included in the AE installation. The ones included in the resource/battle/chara directory are the regular, non-AE movesets, which are superseded by the ones located in dlc/03_character_free/battle/regulation/latest/. However, during the challenges/trials, the game reverts to using the SSF4 movesets, which access the resource/battle/chara ones.

Solder-less Happ Button Mod for Mad Catz SE Fight Stick

2011-06-22T10:07:00.000-07:00

I actually performed this mod about a year ago on my own stick, but never published the pictures or process until now because I didn't think anyone would be interested. However, I've noticed a few threads on the Shoryuken forums with individuals asking for "clickier" alternatives to the sensitive-yet-mushy Sanwa and Seimitsu buttons that are currently preferred by most players, and Happ's products fill that niche quite nicely.

Before I dive in with the mod itself, I'm going to take a few moments to talk about differences between Japanese- and American-style arcade buttons and why someone might prefer one over the other. I'll try to be as objective as possible. If you already know or don't care, feel free to skip straight to the tutorial and pics.

Background

American-style buttons--specifically those from arcade part manufacturers Happ and IL--use a plunger positioned atop a Cherry microswitch, which produces a tangible and audible click when depressed. Japanese-style buttons, on the other hand, use a silent, low-resistance switch that provides little-to-no feedback as to when a button press is registered to the system. This is not to say that Japanese-style buttons are not sensitive, as they are actually significantly more sensitive than the Happ designs, there is simply no indication from the button itself as to when it will register.

Overall, Happ buttons seem to be popular with individuals who also like clicky, mechanical keyboards (like the venerable IBM Model M keyboard, which I use at home), as well as folks who grew up with the American arcade scene (i.e., "old farts," as the kids like to call us).

With that out of the way, lets get started. Some people have laughed at this mod for being "ghetto," but I'll take that over those tacky, overwrought custom sticks so many people seem to favor.

Anyway, as it says in the title, this is a solder-less mod, but you'll still need some additional items (Note: this is a button-only mod; putting a Happ stick into an SE is a much bigger undertaking and I don't recommend attempting it unless you are an experienced modder)

What You'll Need

1. Phillips-head screwdriver. To remove the screws from the bottom of the case.

2. Buttons. I recommend the Happ Competition pushbuttons, which have a low travel distance and convex shape, similar to Japanese-style buttons, but with that same satisfying click as the Happ Classics.

3. .187 quick-disconnects. These connect the stick's board to your buttons. The Japanese-style buttons use .110 quick-disconnects, which are too small for your mighty Happ buttons.

4. Wire. Somewhere around 14 to 16 gauge is good, even a little thicker or thinner should be fine, though you'll want to make sure your quick-releases can grab them properly.

5. Cardboard box. This will be used to make a spacer to provide room for your long-ass American buttons, which run deeper than their Japanese counterparts (/innuendo).

6. Glue. For the aforementioned spacer, which needs to be 2 layers deep. Pretty much any glue should be fine, but you want it to be pretty strong and thick. I used wood glue.

7. Optional. You can use special solderless connectors--like these--to join your wires to the stock wires, but I'll show you a little trick later on that works just fine without any connectors.

Step 1: Remove the bottom plate from the stick

Pretty self-explanatory. Just unscrew the 6 screws (2 in the middle and 1 under each of the 4 rubber feet).

Step 2: Trace the outline of the bottom plate onto your cardboard, twice

Depending on the size of your cardboard, you may have to break down your box. While you're at it, go ahead and draw a second square inside of each, about 1" smaller in each direction.

Step 3: Cut your cardboard

Cut along the lines you just drew such that you have 2x 1" frames of cardboard.

Step 4: Glue the frames together to make your spacer

Put your 2 frames together and glue them. This is your spacer, which provides the necessary clearance for your buttons.

For the next couple of steps, which cover removing the old buttons and putting the new ones in, I recommend replacing 1 button at a time so you don't get the wires mixed up. They're color-coded, but if you lose track of which wires go with which button, you'll have to do a bunch of trial-and-error testing at the end to get everything sorted out. Anyway...

Step 5: Pop out your stock buttons

They have a little clippy thing that holds them in:

If you press it in with a screwdriver or whatever, you should be able to pop them out without much trouble. Make sure you disconnect the wires from the bottoms first.

Step 6: Connect your new wires to the old button connectors

You can use the aforementioned optional solderless splicers or you can do what I did: strip the end of your new wire, pull back the rubber sleeve thing from the old .110 quick-disconnects, wrap your bare wire around the old quick-disconnects

and then slide the rubber sleeve over the whole thing. The connection will be fine and the sleeve will hold everything in place nice and tight. :D

Step 7: Add your new buttons

Not much to this step. Just stick 'em in there, screw on the included nut until it's tight and then clip in the included Cherry microswitch. It's a tight squeeze in the tiny SE case, so you'll want to take that into consideration. Take a look at my finished layout:

Step 8: Connect your buttons and test it out

Crimp your .187 quick-disconnects to stripped ends of your new wires and then connect them to your new Happ buttons. One wire connects to the bent post on the side of the microswitch and one connects to the nearest post on the bottom, as shown in the previous pic. Important: if the quick-disconnect on the side touches the bottom plate of your stick, it will ground itself and cause a button press to register (this is bad). To prevent it, you can tape/glue a piece of paper or plastic (I used one of those anti-static bags that an old computer motherboard was shipped in) to the inside of the plate, just to be extra-cautious.

At this point, you should be ready to test your buttons out. Make sure the wires are all connected to the correct button (i.e., the buttons execute the correct actions in-game). If any of them act like they're always pressed until you actually press the button (i.e., its response is backwards), then you've attached the wire to the wrong post.

Step 9: Replace the bottom plate

Once you're sure everything works properly, just cram your wires into place and screw the bottom back on. With the spacer, the screws should be just long enough to catch if you press firmly on the bottom plate. However, they probably won't be able to hold the rubber feet in place securely and you'll probably lose them (though I imagine most of you are like me and have long since lost those rubber feet anyway).

Here's what it looks like from the side. Yes, the cardboard is visible (though not particularly noticeable), and yes, people will probably make fun of you for it.

If you have any questions about the process, hit me up in the comments.

UPDATE: Reader sfkingalpha had the clever idea of covering the cardboard edge with duct tape, which greatly improves the appearance compared with nekkid cardboard:

http://img.photobucket.com/albums/v341/sfkingalfa/the%20stick/3.jpg
http://img.photobucket.com/albums/v341/sfkingalfa/the%20stick/2.jpg
http://img.photobucket.com/albums/v341/sfkingalfa/the%20stick/1.jpg

"Aside from aesthetics, I think this also helps with air tightness and cardboard deterioration!"

Looks great, sfkingalpha!

He was also able to keep his rubber feet by getting longer screws, specifically 3/4 SS panheads.

Here's his finished product:

http://img.photobucket.com/albums/v341/sfkingalfa/the%20stick/IMAG0007.jpg

http://img.photobucket.com/albums/v341/sfkingalfa/the%20stick/IMAG0006.jpg

Converting Mods Between SF4 Vanilla and AE

2011-06-13T13:32:00.001-07:00

Note: these instructions were written pre-release and are subject to change. They're based on the file structure used in the Xbox 360 version of Super Street Fighter 4 - Arcade Edition but will hopefully apply to the PC version, as well.

The biggest, most obvious difference between vanilla and AE is the fact that AE no longer uses the formerly ubiquitous *.emz bundles--*.cos.emz, *.col.emz and *.cmn.emz--around everything. This makes it easier for us to move costumes around within the character folders, as you no longer have to hex edit the files; just rename them and you're all set. It also means we don't have to muck around with the emz indexes, which really served no purpose and were a total hassle to create from scratch, even with Kensou's SF4tool.

Vanilla to AE

This is the easier conversion of the two, and the only tool you need is piecemontee's Asset Explorer (aka SF4 Viewer).

To get started, find the file(s) you wish to convert and open them in the Asset Explorer. I'll be using my Santa Rufus mod (both cos and col files included) as an example.

Once the files are loaded in the Asset Explorer, click the plus signs to expand them to the point that you see the components of the emz bundles, as pictured:

Then, just go down the line selecting each component file and then right-clicking and choosing 'Raw dump' from the context menu:

Once you have the components busted out of the emz containers, you're all set. Easy, eh?

AE to Vanilla

This one's a little more complicated, but not by much. It also uses just one tool, but this time it's Kensou's SF4tool, which greatly simplifies the creation of emz containers and indexes.

So, to get started, collect all of the component files from an AE character (*.obj.emo, *.shd.emo, *.nml.emb and *.bsr for a cos.emz bundle, *.obj.emm and *.col.emb for a col.emz bundle or *.skl.emo, *.skl.emm, *.obj.ema, *.fce.ema, *.cam.ema, *.bac and *.bac for a cmn.emz bundle) and put them in an easily-accessible folder (your Desktop works just fine for now). Again, I'll be using my Santa Rufus mod, which I just converted for AE a few minutes ago.

Next, we'll open Kensou's SF4tool. If your SF4tool folder does not already have a folder in it named 'emz' go ahead and create one now and drag our desired component files into it. This probably goes without saying, but we have to work with the cos and col components separately; you can't just dump them all in there at once.

Now, open SF4tool. It should look like this:

Then, in the big window area on the right that shows your file structure, double-click on the emz folder (the one we just created if it didn't exist, remember?) and click the left-hand button (the one crudely circled in red in my screenshot). It should automatically populate the smaller window area with our component files, like this:

Unfortunately, Kensou's tool doesn't know the appropriate order for our emz bundles, so we'll have to move some of the components around to suit. Just click right into that little window and edit the entries that are there until they're in the right order. You might want to open a normal vanilla file in the Asset Explorer first to see which order things should be in (obj, shd, nml, and bsr for a cos bundle).

Once everything is in order, click on the right-hand button (the one that ends in emb) to bundle everything up. This window should pop up if you did it correctly:

Now, back in your emz directory, you should have a shiny new file named "newpack.emz." Just rename that to match the numbers of the component files (in my case, CHB_01) and to reflect the type of file you just created (cos, col, cmn, etc) and you should be all set.

Cg Shader Tutorial For Emulators

2011-06-05T18:19:00.000-07:00

04.06.2011 (reposted with permission)

Introduction

This document is for a (fresh) shader developer that wants to develop shader programs for use in various emulators. Shader programs run on your GPU, and thus enables very sophisticated effects to be performed on the picture which might not be possible in real-time on the CPU. Some introduction to shader programming in general is given, so more experienced developers that only need reference for the specification may just skip ahead.

Current emulators that supports the specification explained here to a certain degree are:

– SSNES

– Various PlayStation 3 emulators (SNES9x, Genesis GX, FCEU, VBA)

– SNES9x Win32

There are three popular shader languages in use today:

– HLSL (High-Level Shading Language, Direct3D)

– GLSL (GL Shading Language, OpenGL)

– Cg (HLSL/GLSL, nVidia)

The spec is for the Cg shading language developed by nVidia. It «wraps» around OpenGL and HLSL to make shaders written in Cg quite portable. It is also the shading language implemented on the PlayStation 3, thus increasing the popularity of it. The specification itself can be found here:

https://github.com/Themaister/Emulator-Shader-Pack/blob/master/Cg/README

The Rendering Pipeline

With shaders you are able to take control over a large chunk of the GPUs inner workings by writing your own programs that are uploaded and run on the GPU. In the old days, GPUs were a big black box that was highly configurable using endless amount of API calls. In more modern times, rather than giving you endless amounts of buttons, you are expected to implement the few «buttons» you actually need, and have a streamlined API.

The rendering pipeline is somewhat complex, but we can in general simplify it to:

– Vertex processing

– Rasterization

– Fragment processing

– Framebuffer blend

We are allowed to take control of what happens during vertex processing, and fragment processing.

A Cg Program

If you were to process an image on a CPU, you would most likely do something like this:

for (unsigned y = 0; y < height; y++) {
for (unsigned x = 0; x < width; x++) {
out_pixel[y][x] = process_pixel(in_pixel[y][x], y, x);
}
}

We quickly realize that this is highly serial and slow. We see that out_pixel[y][x] isn't dependent on out_pixel[y + k][x + k], so we see that we can parallelize quite a bit.

Essentially, we only need to implement process_pixel() as a single function, which is called thousands, even millions of time every frame. The only purpose in life for process_pixel() is to process an input, and produce an output. No state is needed, thus, a «pure» function in CS terms.

For the Cg program, we need to implement two different functions.

main_vertex() takes care of transforming every incoming vertex from camera space down to clip space. This essentially means projection of 3D (coordinates on GPU) down to 2D (your screen). Since we're dealing with old school emulators here, which are already 2D, the vertex shading is very trivial.

Vertex shaders get various coordinates as input, and uniforms. Every vertex emitted by the emulator is run through main_vertex which calculates the final output position. For our emulators this is just 4 times, since we're rendering a quad on the screen :D 3D games would obviously have a lot more vertices.

While coordinates differ for each invocation, uniforms are constant throughout every call. Think of it as a global variable that you're not allowed to change.

Vertex shading can almost be ignored altogether, but since the vertex shader is run only 4 times, and the fragment shader is run millions of times per frame, it is a good idea to precalculate values in vertex shader that can later be used in fragment shader. There are some limitations to this which will be mentioned later.

main_fragment() takes care of calculating a pixel color for every single output pixel on the screen. If you're playing at 1080p, the fragment shader will have to be run 1920 * 1080 times! This is obviously straining on the GPU unless the shader is written efficiently.

Obviously, main_fragment is where the real action happens. For many shaders we can stick with a «dummy» vertex shader which does some very simple stuff.

The fragment shader receives a handle to a texture (the game frame itself), and the texture coordinate for the current pixel, and a bunch of uniforms.

A fragment shaders final output is a color, simple as that. Processing ends here.

Hello World!

We'll start off with the basic vertex shader. No fancy things are being done. You'll see a similiar vertex shader in most of the Cg programs out there in the wild.

void main_vertex(
float4 pos : POSITION,
out float4 out_pos : POSITION,

uniform float4x4 modelViewProj,

float4 color : COLOR,
out float4 out_color : COLOR,

float2 tex : TEXCOORD,
out float2 out_tex : TEXCOORD
)
{
out_pos = mul(modelViewProj, pos);
out_color = color;
out_tex = tex;
}

This looks vaguely familiar to C, and it is. Cg stands for «C for graphics» after all. We notice some things are happening, notable some new types.

float4 is a vector type. It contains 4 elements. It could be colors, positions, whatever. It's used for vector processing which the GPUs are extremely efficient at.

We see various semantics. The POSITION semantic means that the variable is tied to vertex coordinates. We see that we have an input POSITION, and an output (out) POSITION. We thus transform the input to the output with a matrix multiply with the current model-view projection. Since this matrix is the same for every vertex, it is a uniform. Remember that the variable names DO matter. modelViewProj has to be called exactly that, as the emulator will pass the MVP to this uniform. It is in the specification.

Since we have semantics for the POSITION, etc, we can call them whatever we want, as the Cg environment figures out what the variables mean.

The transformation happens here:

out_pos = mul(modelViewProj, pos);

The COLOR semantic isn't very interesting for us, but the example code in nVidias Cg documentation includes it, so we just follow along :)

TEXCOORD is the texture coordinate we get from the emulator, and generally we just pass it to the fragment shader directly. The coordinate will then be linearly interpolated across the fragments. More complex shaders can output (almost) as many variables they want, that will be linearly interpolated for free to the fragment shader.

We also need a fragment shader to go along with the vertex shader, and here's a basic shader that only outputs the pixel as-is. This is pretty much the result you'd get if you didn't run any shader (fixed-function) at all.

float4 main_fragment(uniform sampler2D s0 : TEXUNIT0, float2 tex : TEXCOORD) : COLOR
{
return tex2D(s0, tex);
}

This is arguably simpler than the vertex shader :D Important to notice are:

sampler2D is a handle to a texture in Cg. The semantic here is TEXUNIT0, which means that it refers to the texture in texture unit 0. This is also part of the specification.

float2 tex : TEXCOORD is the interpolated coordinate we received from the vertex shader.

tex2D(s0, tex); simply does texture lookup and returns a COLOR, which is emitted to the framebuffer. Simple enough. Practically every fragment does more than one texture lookup. For example, classic pixel shaders look at the neighbor pixels as well to determine the output. But where is the neighbor pixel? We'll revise the fragment shader and try to make a really blurry shader to demonstrate. We now need to pull up some uniforms. We need to know how to modify our tex coordinates so that it points to a neighbor pixel.

struct input
{
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
};

float4 main_fragment(uniform sampler2D s0 : TEXUNIT0, uniform input IN, float2 tex :
TEXCOORD) : COLOR
{
float4 result = float4(0.0);
float dx = 1.0 / IN.texture_size.x;
float dy = 1.0 / IN.texture_size.y;

// Grab some of the neighboring pixels and blend together for a very mushy blur.
result += tex2D(s0, tex + float2(-dx, -dy));
result += tex2D(s0, tex + float2(dx, -dy));
result += tex2D(s0, tex + float2(0.0, 0.0));
result += tex2D(s0, tex + float2(-dx, 0.0));
return result / 4.0;
}

Here we use IN.texture_size to determine the the size of the texture. Since GL maps the whole texture to the interval [0.0, 1.0], 1.0 / IN.texture_size means we get the offset for a single pixel, simple enough. Almost every shader uses this. We can calculate these offsets in vertex shader to improve performance since the coordinates are linearly interpolated anyways, but that is for another time ... ;)

Putting It Together

The final runnable product is a single .cg file with the main_vertex and main_fragment functions added together. Not very complicated. For the icing on the cake, you should add a license header. It's just a comment ;)

/*
Stupid blur shader.
Author: Your friendly neighbor.
License: We don't have those things! :(
*/

struct input
{
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
};

void main_vertex(
float4 pos : POSITION,
out float4 out_pos : POSITION,

uniform float4x4 modelViewProj,

float4 color : COLOR,
out float4 out_color : COLOR,

float2 tex : TEXCOORD,
out float2 out_tex : TEXCOORD
)
{
out_pos = mul(modelViewProj, pos);
out_color = color;
out_tex = tex;
}

float4 main_fragment(uniform sampler2D s0 : TEXUNIT0, uniform input IN, float2 tex :
TEXCOORD) : COLOR
{
float4 result = float4(0.0);
float dx = 1.0 / IN.texture_size.x;
float dy = 1.0 / IN.texture_size.y;

// Grab some of the neighboring pixels and blend together for a very mushy blur.

Result of the shader shown:

As you can see, it's not a practical shader, but it shows the blurring effect to the extreme :)

Expanding Further

It doesn't stop here. A single .cg shader like this is by far the most common way to distribute a shader, but it has some problems.

– There is no way to set the filtering used for the texture. Some filters require nearest filtering, some require linear, although nearest is by far the most common.

– No way to set custom output scale. We're forced to output to full viewport size, which hurts some filters like HQx and friends.

– No way to use multiple shaders. (multi-pass, FBO).

– No way to grab external lookup textures. (Borders, etc)

This has been solved in various ways for the different emulators. The way to do metadata like this varies for the Cg implementations. As of writing, SNES9x Win32 hasn't addressed this, but will hopefully in the near future.

SSNES and the PS3 emulators solve this with a config file.

Lookup textures

We'll first mention a very popular feature among the PS3 emulators, the ability to access external textures. This means we have several samplers available for use. In the config file, we define the textures as so:

textures = "foo;bar"
foo = path_foo.png # In SSNES this is relative, but PS3 emus are absolute path for now.
bar = bar_foo.png
foo_linear = true # Linear filtering for foo.
bar_linear = true # Linear filtering for bar.

PS3 emus use PNG as the main format, SSNES can use whatever if Imlib2 support is compiled in. If not, it's restricted to lop-left ordered, non-RLE TGA.

From here on, «foo» and «bar» can be found as uniforms in the shaders. The texture coordinates for the lookup texture will be found in TEXCOORD1. This can simply be passed along with TEXCOORD0 in the vertex shader as we did with TEXCOORD0. Here we make a fragment shader that blends in two background picture at a reduced opacity. Do NOT assign lookup textures to a certain TEXUNIT, Cg will assign a fitting texture unit to the sampler.

float4 main_fragment(uniform sampler2D s0 : TEXUNIT0,
uniform sampler2D foo, uniform sampler2D bar,
float2 tex : TEXCOORD0, float2 tex_lut : TEXCOORD1) : COLOR
{
float4 bg_sum = (tex2D(foo, tex_lut) + tex2D(bar, tex_lut)) * 0.15;
return lerp(tex2D(s0, tex), bg_sum, bg_sum.a); // Alpha blending. :D
}

In the PS3 emus there is a magic «bg» sampler that is assigned to the current border selected in the menu. It is not needed to define this in any config file.

Here's an example of what can be achieved using borders (which are just a simple lookup texture):

Multipass

It is sometimes feasible to process an effect in several steps. SSNES and PS3 emus differ here.

SSNES uses the same config file where you can do:

shaders = 2
shader0 = pass1.cg
shader1 = pass2.cg

scale_type0 = source
scale0 = 2.0
filter_linear0 = true
filter_linear1 = false

The PS3 emulators handle the same case in the menu generally. There is however a new config system on the way that will handle these kinds of configs.

Game-aware Shaders

This is a new and exiting feature. It allows shaders to grab data from the emulator state itself, such as RAM data. This is only implemented for SNES so far, but the idea is quite extendable and portable.

The basic idea is that we capture RAM data in a certain way (semantic if you will) from the SNES, and pass it as a uniform to the shader. The shader can thus act on game state in interesting ways.

As a tool to show this feature, we'll focus on replicating the simple tech demo shown on YouTube:

http://www.youtube.com/watch?v=4VzaE9q735k

What happens is that when Mario jumps in the water, the screen gets a «watery» effect applied to it, with a rain lookup texture, and a wavy effect. When he jumps out of the water, the water effect slowly fades away.

We thus need to know two things:

– Is Mario currently in water or not?

– If not, how long time was it since he jumped out?

Since shaders do not have state associated with it, we have to let the environment provide the state we need in a certain way. We'll call this concept a semantic.

To capture a RAM value directly, we can use the «capture» semantic. To record the time when the RAM value last changed, we can use the «transition» semantic. We obviously also need to know where in RAM we can find this information. Luckily, the guys over at SMW Central know the answer:

http://www.smwcentral.net/?p=map&type=ram

We see:

$7E:0075, byte, Flag, Player is in water flag. #$00 = No; #$01 = Yes.

Bank $7E and $7F are mapped to WRAM $0000-$FFFF and $10000-$1FFFF respectively. Thus, our WRAM address is $0075.

In the config file, we can now set up the uniforms we'll want to be captured in the config file.

imports = "mario_water;mario_water_time"
mario_water_semantic = capture # Capture the RAM value as-is.
mario_water_wram = 0075 # This value is hex!
mario_water_time_semantic = transition # Capture the frame count when this variable last
changed. Use with IN.frame_count, to create a fade-out effect.
mario_water_time_wram = 0075

The amount of possible «semantics» are practically endless. It might be worthwhile to attempt some possibility to run custom code that keeps track of the shader uniforms in more sophisticated ways later on. Do note that there is also a %s_mask value which will let you bitmask the RAM value to check for bit-flags more easily.

Now that we got that part down, let's work on the shader design. In the fragment shader we simply render both the full water effect, and the «normal» texture, and let a «blend» variable decide. We can say that 1.0 is full water effect, 0.0 is no effect. We can start working on our vertex shader. We will do something useful here for once.

struct input
{
float frame_count; // We only need frame count. :D
};

void main_vertex(
float4 pos : POSITION,
out float4 out_pos : POSITION,
uniform float4x4 modelViewProj,
float4 color : COLOR,
out float4 out_color : COLOR,
float2 tex : TEXCOORD0,
out float2 out_tex : TEXCOORD0,
float2 tex1 : TEXCOORD1,
out float2 out_tex1 : TEXCOORD1,

uniform float mario_water, // Even if the data should have been int, Cg doesn't seem to
support integer uniforms :(
uniform float mario_water_time,
uniform input IN,
out float blend_factor // Blend factor is passed to fragment shader. We'll output the
same value in every vertex, so every fragment will get the same value for blend_factor
since there is nothing to interpolate.
)
{
out_pos = mul(modelViewProj, pos);
out_color = color;
out_tex = tex;
out_tex1 = tex1;
float transition_time = 0.5 * (IN.frame_count – mario_water_time) / 60.0;
if (mario_water > 0.0)
blend_factor = 1.0; // If Mario is in the water ($0075 != 0), it's always 1 ...
else
blend_factor = exp(-transition_time); // Fade out from 1.0 towards 0.0 as
transition_time grows larger.
}

All fine and dandy so far, now we just need to use this blend_factor in our fragment shader somehow ... Let's move on to the fragment shader where we blend :D

const float2 src0 = float2(0.6, 0.7);
const float2 src1 = float2(0.9, 0.9);
const float2 src2 = float2(-0.6, 0.3);
const float2 src3 = float2(0.1, 0.4);
const float2 src4 = float2(0.1, 0.4);
const float2 src5 = float2(0.5, 0.5);
const float2 src6 = float2(-1.0, 1.0);
float apply_wave(float2 pos, float2 src, float cnt)
{
float2 diff = pos - src;
float dist = 300.0 * sqrt(dot(diff, diff));
dist -= 0.15 * cnt;
return sin(dist);
}
// Fancy shizz to create a wave.
float4 water_texture(float4 output, float2 scale, float cnt)
{
float res = apply_wave(scale, src0, cnt);
res += apply_wave(scale, src1, cnt);
res += apply_wave(scale, src2, cnt);
res += apply_wave(scale, src3, cnt);
res += apply_wave(scale, src4, cnt);
res += apply_wave(scale, src5, cnt);
res += apply_wave(scale, src6, cnt);
return output * (0.95 + 0.012 * res);
}
float4 main_fragment
(
uniform input IN,
float2 tex : TEXCOORD0, uniform sampler2D s0 : TEXUNIT0,
uniform sampler2D rain, float2 tex1 : TEXCOORD1,
in float blend_factor // Passed from vertex
) : COLOR
{
float4 water_tex = water_texture(tex2D(s0, tex), tex1, IN.frame_count);
float4 normal_tex = tex2D(s0, tex);
float4 rain_tex = tex2D(rain, tex1);
// First, blend normal and water texture together,
// then add the rain texture with alpha blending on top :)
return lerp(lerp(normal_tex, water_tex, blend_factor), rain_tex, rain_tex.a *
blend_factor * 0.5);
}

The SNES9x-PS3 config file:

imports = "mario_water;mario_water_time"
mario_water_semantic = capture
mario_water_time_semantic = transition
mario_water_wram = 0075
mario_water_time_wram = 0075
textures = rain
rain = "/dev_hdd0/game/SNES90000/USRDIR/borders/Centered-1080p/overlays/none-overlay.png"
rain_linear = true

The shader itself could be added to this config, but it can also be used from the regular menus in case you want to test different approaches to the same RAM value.

SSNES config file:

shaders = 1
shader0 = mario.cg
filter_linear0 = true
imports = "mario_water;mario_water_time"
mario_water_semantic = capture
mario_water_time_semantic = transition
mario_water_wram = 0075
mario_water_time_wram = 0075
textures = rain
rain = rain.tga
rain_linear = true

As you can see, these formats are very similiar. The differences are mostly for historical reasons, and might become closer in the future.

How to test when developing for SNES9x-PS3?

To develop these kinds of shaders, I'd recommend using SSNES w/ Cg support, and bSNES as a SNES debugger to peek at RAM values (build it yourself with options=debugger). After written, the shader should translate nicely over to SNES9x-PS3 with some slight changes to the config.

Here are some screenshots of the mario effect we developed. Obviously this is a very simple example showing what this thing can do :) It's not confined to overlays. The imagination is the limit here.

Before water ...

In water :D

Programs Won't Launch in Win7 64-bit

2011-05-28T12:54:00.000-07:00

UPDATE (10/7/11): I never did find an actual solution for this problem. Every time I thought I had something, it would always come back. In the end, I had to reinstall the system. :/

So, I've been running into an issue on my Lenovo Thinkpad X120e when booted into Windows 7 where programs won't launch from the taskbar when I click on them. The little transparent box shows up around it, it sits for a second, then fades away.

I found, however, that I could run things from the command line, though that was not a good fix. After futzing around with the startup applications in msconfig, I found that it would start programs just fine if I turned off all of my startup items. This was also suboptimal, so I set to tracking down the culprit from the startup items by enabling them one-by-one and restarting each time.

UPDATE (6/5/11): Turns out my below "fix" may have just been coincidental, because my issue returned. It hung around through several reboots until I ran Windows Update and updated my video card driver, after which it went away again. Whether this fixes things permanently, we'll have to see.

I'll update this post if anything changes.

Original, ineffectual post:

Eventually, I found the problem to be related to the Sidebar application, which powers the CPU frequency and weather widgets I like to have sitting on my desktop. :(

I haven't had any problems since I turned it off.

Profiled, optimized libsnes builds for win32

2011-05-16T13:44:00.001-07:00

I've been playing around with mingw, doing cross-compiles of libsnes with profile-guided optimizations (PGO) for use with SSNES in Windows and I think I've gotten it down pretty well.

I used the following C-flags at compile time:

-msse2 -fmerge-all-constants -fmodulo-sched -fgcse-sm -fgcse-las -funsafe-loop-optimizations -fsched-spec-load -fsched-spec-load-dangerous -fsched-stalled-insns=0 -fsched-stalled-insns-dep -fsched2-use-superblocks -fipa-pta -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts -fvariable-expansion-in-unroller -ffast-math -fbranch-target-load-optimize -maccumulate-outgoing-args -combine

This means it's only going to work on CPUs that support the SSE2 SIMD instructions, but that includes pretty much every processor manufactured in the past 8 years, so I figured that was good enough.

If you want to give them a try, you can get them from my mediafire.

More Emulator Pixel Shaders (CRT updated and more)

2011-05-15T19:34:00.000-07:00

I'm just going to dive right in with the pictures in this post. If you want/need some backstory, read my previous CRT shader post. These shaders are all available in Screwtape's bsnes git repo, except for Beam4, which can be downloaded here, and NTSC, which can be downloaded here (both mirrored in my mediafire in case the pastebins expire before Screwtape adds them to his repo).

Update (01/11/12): bsnes support is back! Plus, the Win32 and GTK+ ports of snes9x support these shaders, as well. :D

UPDATE (9/20/11): Themaister has written an awesome little WebGL applet that enables shader testing and combining (up to 2 separate shaders) quickly and easily. Check it out! (requires browser with support for WebGL, such as newer versions of Google Chrome and Mozilla Firefox; only supports single-pass shaders at the time of this writing)

Here's a good picture to test with (320x240 resolution with point filtering, mimics raw SNES output):

UPDATE (5/30/11): Added shots of caligari's phosphor21x shader (a.k.a. caligari's scanlines in Screwtape's repo). UPDATE (6/3/11): Added Themaister's Dot 'n' Bloom, available from Screwtape's repo. UPDATE (6/18/11): Added caligari's scanlines - rgb triad. UPDATE (9/29/11): Added Themaister's phosphorish. UPDATE (11/22/11): Added edge detection and ALovelyBloom.

All images are taken at 3x scale, followed by that same image blown up 400% with no further interpolation. As always, click the thumbnails to embiggen.

4xBR

This one uses an algorithm similar to HQ4x and it shows.

ALovelyBloom

Unfortunately, this one's just a big flare-out on Super Mario World, but it looks pretty good on darker games, if you're into bloom. You can stack it with some other shaders to soften up phosphor effects and so on.

Beam4

This is a multipass scanline shader from cgwg that also simulates an electron beam that takes longer to rise than to fall. It is perfect for producing the pseudo-hires transparency used in Kirby's Dreamland 3 and Jurassic Park. Sadly, it only works in emulators that support shader spec 1.1 (at the time of this writing, Themaister's SSNES and PS3 homebrew emus written by Dante Ali).

Bicubic

This one's pretty straightforward, using an algorithm similar to that of bilinear filtering (aka, 'smooth video'). It's a little sharper and preserves edges a little better.

CRT.OpenGL

This is the latest and greatest version of the collaborative CRT shader. The screen curvature is user-definable, based on changing a single value in the helpfully commented shader code. As you can see, it looks totally amazing. It also runs a lot faster than it used to, so give it a shot even if your machine couldn't handle it before.

CRT-simple.OpenGL

This one is very closely related to the aforementioned CRT shader, only this one is optimized for weaker cards while only sacrificing a tiny bit of accuracy. If your machine can't run the full-fledged CRT shader, this one is your last good chance.

Dot 'n' Bloom

Another cool one from Themaister, Dot 'n' Bloom treats each pixel like a single, distinct dot and then adjusts its size based on brightness, such that brighter dots appear larger than darker ones, similar to a CRT electron beam (though this shader is not attempting to reproduce a CRT, it resembles one). He then added a bit of bloom to blend things together some. The results look really nice in motion (especially on Super Metroid :D) and the shader runs extremely fast.

Edge Detection

This one is more stylized than most of the others I've covered. As you might have guessed by the title, it finds the edges of colors and presents them as an outline. On SMW's cartoony, hard outlines, it makes a crazy quadruple outline.

Lanczos 4-tap

Another fairly straightforward interpolation filter, this one runs quite fast even on weaker hardware. You can learn more about the Lanczos algorithm and its use in resampling at the Wikipedia.

Lanczos 6-tap

As you might have guessed, this one is very similar to the 4-tap Lanczos, but it is further sharpened, which leads to the ringing/halo effect around sprites.

NTSC

This multipass shader is the result of cgwg and Themaister porting blargg's awesome NTSC filter to GLSL. It looks quite nice and doesn't bog down the CPU like the regular filter version. Unfortunately, it only works on shader spec 1.1-compatible emus.

Phosphor21x

This is caligari's implementation of an algorithm originally written by xythen in Matlab, which served as the inspiration for the work that later became CRT.OpenGL. This shader builds on xythen's work to be essentially scale factor-independent, except it looks a little weird at 2x in my experience; everything larger looks great. An interesting note: the scanlines that appear with this shader are not simply added in. Instead, they are naturally occurring as a result of the phosphor simulation. Pretty cool stuff :D

By uncommenting some lines in caligari's code, you can enable one of three phosphor/shadow mask arrangements, of which the RGB triad option is the nicest (I recommend clicking these thumbnails to see in full size):

As you can see, this option causes some serious dimming of the picture brightness, which was also a technological obstacle for actual CRT engineers when shadow masks were first being designed and implemented. In bsnes, you should be able to just increase the gamma in the picture settings to compensate. You can download this shader variation from my mediafire account.

Phosphorish

A simple, single-pass shader that makes a nice phosphor effect. This shader runs fast and works with both bsnes and SSNES. It is available here or in my mediafire.

Quilez

This fast, crisp interpolation filter is totally new to the emulation scene. It's based on some fancy math demonstrated by Inigo Quilez and represents a good compromise between the pixelate2x and bicubic shaders.

Simple TV Blur

This one's rather subtle, but is intended to do the minimum amount of work required to reproduce the pseudo-hires transparency.

Beam4+NTSC

Just for fun, I used SSNES' shader stacking support to combine the new NTSC shader with the Beam4 shader. It's almost indistinguishable from Beam4 alone (except for some really slight changes to the color palette), so I wouldn't bother trying it yourself.

CRT+NTSC

As above, I tried stacking the NTSC shader with the new CRT shader and this was the result. It's kinda cool in a way, like newsprint. :P According to cgwg, this is happening because it's only picking up the first pass of the NTSC shader, which has no color values.

CRT-Flat+Caligari's Scanlines - RGB Triad

When the regular CRT shader (edited to have 0.0 for the distortion value) is paired with caligari's scanlines - RGB triad variant, you end up with a pretty neat result:

The colors are off by a good bit (I think because of the double gamma correction) and it's very dark, but the phosphor triads from caligari's are still clearly discernible over the CRT shader's already-awesome result. Still not perfect, obviously, but getting close in a lot of ways.

Barkeeper's Friend for Cleaning Stainless Steel Cookware

2011-04-14T21:21:00.000-07:00

I don't normally do this sort of post on my blog, but I figured people might find it useful, so...

Barkeeper's Friend is an abrasive cleaning powder, similar to Comet, that is renowned for its ability to clean stainless steel pots and pans. I've always heard that it can clean stains you would think were there forever, so I figured I'd give it a shot with my well-worn tea kettle:

As you can see, there are some pretty nasty black stains flecked around the bottom of the kettle, quite a bit of brown crud caked on underneath that, and an overall cloudiness to the finish everywhere else.

By reading the directions on the side of the Barkeeper's Friend label, you can see that it recommends a couple of different ways to use the product:

1. wet the item to be cleaned so the powder will stick to it better, sprinkle on some Barkeeper's Friend, then scrub vigorously with a damp rag

2. mix Barkeeper's Friend with water to make a paste and then spread that onto the surface of the item to be cleaned and let it sit for a minute or so, then scrub vigorously with a damp rag.

I tried both methods.

The first method is faster, obviously, but I found its performance underwhelming. While cloudiness was greatly reduced after scrubbing, much of the brown crud remained and the black stains were completely unaffected. Unfortunately, I wasn't able to take a picture after this treatment. You'll have to just take my word for it.

The second method is kind of a hassle, but it's worth the extra time and effort. In addition to clearing up the cloudiness, this method also removed the vast majority of the brown crud and helped somewhat with the black stains, though a noticeable amount of black staining still remains after scrubbing.

Here's how it looked after cleaning:

Substantially improved, but far from perfect.

I also scrubbed the scorched bottom surface of the kettle using both methods and left a section cleaned only with regular soapy water as a control:

Again, method 1 certainly helped, but method 2 was much more effective. However, even method 2 wasn't able to completely clean up everything.

If you have any questions, drop me a comment.

Configuring Lenovo TrackPoint Mouse Wheel Emulation Scrolling in Ubuntu

2011-03-24T18:01:00.000-07:00

I have a Lenovo X120e and have grown accustomed to using the once-loathed TrackPoint (also known as the nubbin, the navigation nipple, the eraserhead, and others) for scrolling through Web pages, windows, etc. as I would with a mousewheel. Here is how you would do it in Ubuntu (in this case 11.04 Natty Narwhal, but it should apply to anything Maverick or later:

Open up a terminal and type:

gpointing-device-settings

UPDATE (8/13/11): The package isn't installed by default in 11.10 Oneiric Ocelot, so you'll have to install it first, either through Synaptic package manager or by typing

sudo apt-get install gpointing-device-settings

Select the TrackPoint device from the pane on the left. Mine is called "TPPS/2 IBM TrackPoint." In the middle of the window, you'll see a checkbox labeled "Use wheel emulation." Check the box, along with the ones labeled "Enable vertical scroll" and "Enable horizontal scroll" as you see fit.

You'll also need to select your scroll button from the pull-down menu. In my case, it was button 2, but YMMV.

While you're here, you can also switch to the TrackPad options and disable your trackpad, if that's what you're into.

Ubuntu Natty on Lenovo ThinkPad X120e

2011-03-23T08:16:00.000-07:00

If you've read my earlier post regarding Maverick on this machine, you'll know I ran into a few annoying issues.

The biggest problem was that my Broadcom wireless driver kept getting deactivated with every reboot, so I decided to try installing Natty instead.

The first issue I ran into with Natty was that the installer kept crapping out before the partitioning phase with an error about ubi-partman failing to start due to error 141. There are a couple of Launchpad bugs filed for this error, but a claimed fix that was checked in a few days earlier did not seem to help things. What fixed me up, though, was using the alternate install image, which uses an ncurses-based installer rather than the fancy Ubiquity installer.

So, moving on, everything installed fine and, upon booting into the new system, the hardware driver manager detected my wireless card and recommended the proprietary Broadcom SLA driver. Click to enable, reboot and wireless should be fine and dandy.

If you opted for the default Ralink card, it should be detected and supported out-of-the-box, without even needing to consult the driver manager.

By default, the system utilizes the open source "radeon" driver, with 3D support provided by the Gallium3D backend. This should be fine for light 3D duties, such as Compiz, though it does have a show-stopping bug that will cause crashes, loops and reboots under heavy stress, such as 3D games. As long as you don't play any games, though, you should be fine. If you want to play games and/or use video decoding acceleration, you'll have to install the proprietary Catalyst driver, but it is not yet compatible with the X Server included in Natty. This will be resolved before final release in April.

Update 3/30/11: The updated proprietary fglrx driver should be available from the Natty repos now.

At this point, my system works pretty well, except for an odd dependency hell issue that is preventing Unity from installing/running because of some Compiz virtual package conflict B.S., though I suspect this will be sorted out in a couple of days. UPDATE (3/23/11): fixed now.

I haven't tried suspend/hibernate yet, but will update with results as soon as possible.

UPDATE (3/23/11): waking from suspend seems fine, though my notification stuff isn't updating (wireless is showing that it's disconnected, even though it's not, etc). Hibernate, in contrast, seems totally b0rked. It just sits there blowing its fan and blinking the sleep LED on the front edge until you do a hard poweroff. :(

UPDATE (4/1/11): To get multitouch working on your trackpad, install the package gsynaptics (not to be confused with the synaptic package manager):

sudo aptitude install gsynaptics

and then type:

gpointing-device-settings

You should be able to enable two-finger scrolling from the trackpad menu. While you're there, you can configure the navigation nub for mousewheel emulation, if that's what you're into.

Everything else I've tested, including audio and webcam, work just fine. Even the function volume keys work.

Things I haven't tested:
HDMI-out
audio over HDMI
VGA-out

The middle scroll button works too, it just takes a little configuration.

My First Mid-horns for Hifi

2011-03-18T08:34:00.001-07:00

I've spent a lot of time on audiophile forums reading about the advantages of horns over purely cone-based speakers, including crisp sound reproduction, consistency, "realism" and extremely high sensitivity. The drawbacks, of course, being high cost (sometimes ridiculously so), a dearth of non-vintage models to choose from, few places to demo products before buying and, perhaps most importantly, the tremendous size requirements for horns that will reach lower frequencies. Horns are also known for their "honkiness" and directivity, which can be a problem if you often listen to music outside of your stereo's "sweet spot."

While any driver can be horn-loaded, when people talk about horns, they usually mean a compression driver with a horn attached to the front, either through bolting (the standard for audiophile equipment) or via a threaded, screw-on junction (the standard for professional equipment). Relative to normal drivers, compression drivers have very low distortion due to the small size of the membrane and the relatively short distance the membrane needs to travel.

So, as I began looking into mid-horns, most of the information available online suggests that you will need to purchase vintage equipment, such as 1950s-era JBL compression drivers and similarly aged JBL or Altec Lansing horns or else build your own horns, which can be a daunting task to say the least. If you go on eBay and look for these products, you'll see that very little is available for less than $1,000, as they have reached the status of collectors' items and are priced as such.

However, I also noticed that horns and compression drivers are still used quite extensively in professional audio settings, such as stage monitors and PA speakers. In fact, Selenium's D250-X compression driver has performance specs that looked very similar to those of the multi-thousand-dollar, vintage compression drivers I was seeing on eBay, including an uncrossed frequency response from 400 Hz to approximately 9 kHz and a sensitivity of 107 db at 1w/1m, but with a power handling capability of 150w (vs. very low power handling on vintage equipment). The biggest difference, though, is the price: ~$35!

These MCM drivers are also a good, cheap option, with a low frequency range down to 100 Hz!

Likewise, when looking into mid-horns, the prices for newly constructed or high-quality vintage equipment usually range from ~$750+ up to tens of thousands of dollars. This is simply too expensive for me, so I began looking for other options, including DIY solutions and professional audio. At this point, I had to make some decisions, including which horn curve I wanted to use.

Deciding on horn curves is basically a matter of weighing a series of compromises and figuring out what matters to you most/least. While conical horns tend to have the least honky horn coloring and are also easy to construct, owing to their straight-angled sides, they are also the least space-friendly and also tend to be very ugly, in my opinion. Exponential horns take up considerably less space than conical horns for a given frequency response, but they are more difficult to construct, due to their curved sides. Similarly, square/rectangular horns tend to have better dispersion and listening angles than round horns, while round horns impart less distortion to the sound wave.

I decided that a round exponential, while difficult to construct, would be my best bet, since I want to experience the horn sound and my space is limited (my listening room is less than 200 sq feet).

While weighing my options, I came across some potentially good options in the pro realm, including the Dayton Audio H12RW 12" waveguide and the Selenium HL14-25 exponential horn. The waveguide was attractive to me because it can easily drop right into an existing speaker cabinet designed to house a 12" woofer. However, waveguides are a little different from traditional horns, and that's really what I wanted to try. That in mind, I went with the HL14-25 horns, which have a suggested frequency range from approximately 600 Hz to 5 kHz, well inside the range of the driver.

When I received the horns, I first tested them by wiring them in series with my Phase Technology Teatro 7.5s (8 ohm, 90 db sensitivity, freq. resp. of 40 Hz to 20 kHz), but the sensitivity of the horns was too far off from that of the Teatros, such that the horns were ear-splittingly loud by the time the volume was high enough to hear the Teatros comfortably. With that in mind, I resurrected my old Sony solid state receiver (100w per channel) and wired it to push the Teatros and my subwoofer while my Dared VP-20 pushed the Selenium horns. This way, I could independently adjust the volumes to achieve a good balance between the horns and the Teatros, and then use my preamp's volume control as a sort of 'master volume.'

To run my initial tests, I left the horns uncrossed and expected a good bit of distortion below the 400 Hz mark, since that's as low as the drivers are supposed to go. I cautiously kept the volume very low as I didn't wish to blow my new drivers on their first go 'round. However, I was pleasantly surprised to find that the horns handled the lower frequencies quite gracefully, with no distortion that I could notice--even when playing as loud as I could comfortably stand--and with a fairly smooth (though rapid) rolloff below around 600 Hz. I'm assuming this success is largely due to the fact that the horns are probably receiving only a handful of watts instead of the 100+ watts that are normally shoved through them in professional applications.

Based on this experience, I have decided not to bother with a crossover at this time, though I may revisit the issue in the future.

I guess the real question now is: "How does it sound?" In short, it sounds fantastic. The frequency range covered by the horns encompasses guitar solos, most vocals and organs, which all sounded a bit anemic on my Teatros alone. The clarity and definition in these frequencies is truly astounding and must be experienced. If you've only ever heard cone drivers for this range (like me before I bought these horns), it's honestly impossible to imagine how rich the sound reproduction can truly be.

My setup is designed to allow for extensive A/B testing (in addition to the independent volume control for the Teatros and horns, the VP-20 has independent volume control for each channel), and this is where the improvements really shine. Even my wife (who is very honest about differences she can and can't hear, often to my chagrin) was blown away by the disparity between Teatro+horn vs. Teatro alone.

The horns admittedly have some strong directivity, but they also have a good--though different--sound off-axis, such that listening outside of the sweet spot is still nice, just not the same as getting right there in the middle.

Here are a couple of pictures of the horns sitting on top of my Teatros:

In the first picture, you can see the VP-20 that pushes them, as well a little bit of my disc changer, preamp and crummy solid state amplifier.

Ubuntu Maverick on Lenovo X120e Fusion Laptop

2011-03-15T13:08:00.000-07:00

UPDATE 3/23/11: Natty seems to work much better with these systems, so I recommend skipping Maverick and going straight for 11.04, even thought it's still in Alpha stage at the time of this writing. Check out my post about it here.

Original Post:

Due to a wonderful pricing error at Lenovo, I got a really sweet deal on a Thinkpad X120e laptop, featuring AMD's new Zacate Fusion chipset.

When trying to install Ubuntu 10.10 Maverick on it, though, the Ubiquity installer kept failing with this error:

grub-install efi-dummy failed. This is a fatal error.

To fix this, you need to go into the computer's BIOS and, under the boot tab, change the uEFI settings to try 'legacy' first. This will allow Ubuntu to install grub successfully.

After you make that change, installation should be able to complete and you can reboot into your new system.

That's as far as I've gotten so far, so I'll update this post as I find out more.

Update (3/15/11): I ran into a few more issues that I had to muddle through: wireless networking and waking up after closing the lid of the computer.

First, we'll fix the suspend issue, since it's the easier of the two.

Update 3/23/11: Actually, this doesn't fix anything. It still has problems after a few seconds of having the lid closed (i.e., when it actually goes to sleep). Sorry for any inconvenience. I'll add a real solution if/when I find one.

Open up a terminal and type:

gconf-editor

It will bring up a window with lots of configuration items. Navigate to apps > gnome-power-manager > actions, then change the default entry for sleep_type_battery from 'hibernate' to 'suspend.'

This should get you fixed up.

Now for the tedious one...wireless.

If you have the default Ralink wireless card, for now you'll have to get the driver from the manufacturer's website, build it and install it (download it here). However, the driver *should* work out-of-the-box in Natty.

UPDATE 3/21/11: annoyingly, my system keeps deactivating the driver. I give up on Maverick and have to recommend skipping to Natty instead.

On the recommendation of others, I purchased my machine with the optional Broadcom 802.11 a/b/g/n wireless card instead of the default Ralink card. Unfortunately, the Broadcom card isn't much better. It uses the 802.11 Linux STA driver, but the device isn't supported by the version available in the official Ubuntu repos. Instead, we'll have to download and install it directly from Broadcom.

To get it going, first you want to download the driver from this page. The drivers are specific to your CPU architecture, so make sure you get the right one. After that, we need to install some prerequisites to build the driver:

sudo apt-get install build-essential linux-headers-`uname -r`

Now, we'll navigate to wherever you downloaded the driver (I'm going to assume it's located in the default ~/Downloads directory):

cd ~/Downloads

Decompress the archive:

tar -xvf hybrid-portsrc_x86_64-v5_100_82_38.tar.gz

and then build and install the driver:

make && sudo make install

The driver is now installed, but we need to activate it and tie up some loose ends. So, still in a terminal, type:

sudo depmod -a

This will fetch all of the dependencies for drivers located in /lib/modules (including our newly installed driver).

Now, we'll make sure no conflicting drivers are in use by typing:

sudo rmmod bcm43xx
sudo rmmod b43
sudo rmmod b43legacy

and then try our new driver out by typing:

sudo modprobe lib80211_crypt_tkip && sudo insmod wl.ko

At this point, your wireless should start working. If it does, we need to make sure conflicting drivers don't start bothering us again by typing:

sudo gedit /etc/modprobe.d/blacklist

and adding these lines:

blacklist b43
blacklist b43legacy
blacklist bcm43xx

Save and exit. Then, back in the terminal, type:

sudo gedit /etc/modules

and add:

ieee80211_crypt_tkip

at the bottom. Then, type:

sudo gedit /etc/rc.local

and add this:

sudo insmod /lib/modules/[whatever your kernel revision is]/wlan/wl.ko

to the end of the file, but before it says "exit 0."

You should be all set at that point. If you need to reverse these steps for whatever reason, just go back through these steps and delete the lines we added.

Last, we'll talk a bit about graphics drivers. The open source drivers do not support our fancy new APU graphics, so we'll have to use the proprietary fglrx driver binary blob from AMD, which you can install through the 'Additional Drivers' applet, located under the System > Administration menus. However, after rebooting, you'll see (at the time of this writing) a translucent black square in the bottom-right corner of your screen that shows an AMD logo and says 'Unsupported hardware.'

This can be avoided by manually installing a newer fglrx driver directly from AMD instead of using the package from the official repos, but that adds its own hassles that I didn't feel like dealing with, such as needing to manually reinstall the driver after every kernel update. If you would rather go that route, you can find detailed instructions here.

Filter and Shader Stacking In SSNES

2011-03-08T09:51:00.000-08:00

Themaister just added support for multipass shader application--a.k.a. shader stacking--to SSNES, his excellent (and recently GUI-fied) frontend for libsnes. His implementation includes some interesting and fancy options, including configurable scale factors for the first pass (i.e., the first shader). This allows hq2x to be scaled to its expected scale factor during the first pass and then scaled up again to fit the desired resolution, resulting in much better retention of detail (see this post for a side-by-side comparison of the two scaling methods). Additionally, we can use the second pass to stack a scanline shader on top of the resulting image, or even cgwg's CRT shaders:

As you can see, this combination greatly smooths out the jaggies and rounds the curves without blasting out all of the details, like hq2x can often do on its own.

This two-pass shader implementation also allows users to control the amount of bloom applied by a bloom shader in the first pass simply by modifying the scale factor. Here are two examples in which I've stacked blargg's NTSC filter, cgwg's CRT-Flat v3 shader, and Whateverman's simplebloom shader (rendered at 2x and 1x respectively):

In my opinion, this combination of bloom+CRT shaders+NTSC filter is exceptionally close to the Photoshop renders that inspired the CRT shader effort.

Windows binaries for this latest version of SSNES are available here, while Linux users can download deb binaries from my PPA repo. Mac users can also get in on the fun, but they'll have to compile everything themselves, as no one is providing Mac packages of SSNES yet.

As always, any shaders covered here are available in my mediafire account.

Themaister's Waterpaint and Scanline Pixel Shaders for SNES

2011-03-03T10:09:00.000-08:00

Themaister, author of the excellent libsnes interface SSNES, has been working on some really fantastic GLSL pixel shaders for use with compatible emulators, such as bsnes and SNES9x.

First, we'll take a look at the waterpaint shader, which has an effect similar to smoothing filters, such as SuperSaI, but with a little extra fattening that gives it the appearance of a watercolor painting:

This looks great already, but text can sometimes get a bit hard to read and some details get flattened out, so he also made a version that includes light scanlines (both the standard horizontal scanlines, as well as faint vertical lines, as would be found in a phospher mask):

I think this version does a better job of maintaining fine details and really looks nice, especially on Zelda:LttP.

Next, he produced a beautiful (and easily customizable) resolution-agnostic scanline shader. In contrast with my own scanline shaders, Themaister's shader will work with any scale factor instead of having one hardcoded in. Here's how his default version looks without and with bilinear filtering (smooth video), respectively:

In addition to this default, I modified the settings to create medium and dark scanline settings, as well (each shown without and with bilinear filtering enabled, respectively):

You can download these shader's from my mediafire account. If you would like to modify the scaline shaders yourself, you can play around with these figures:

const float base_brightness = 0.95;
const vec2 sine_comp = vec2(0.05, 0.15);

Beginner's Guide to Face-fixing

2011-02-05T14:43:00.000-08:00

Many of the steps in this tutorial are no longer necessary in SSF4AE. You can just copy over the donor's *.fce.ema file and overwrite the recipient's.

UPDATE (11/26/11): you can now use sloth86's MonkeyFix tool in conjunction with the replaced *.fce.ema to get fixed faces all the time, even through the cinematics.

If you've experimented with moveswapping across characters, you've certainly seen the horrible deformation that occurs to their faces, commonly known as "monkeyface."

This tutorial is going to show you how to swap movesets (we're actually swapping models, but it comes out to the same thing) without the monkeyface problem (except in cinematics, such as intro/outro and during ultras).

Background

Animations and movesets in Street Fighter 4 are stored in the ***.cmn.emz file. Specifically, facial animations are stored in the ***.fce.ema file, which is itself a component of the cmn.emz file. To transplant these face animations from one character alongside the moveset of another character, we're going to have to collect a few tools: piecemontee's Asset Explorer, Kensou's Tool and your favorite hex editor (I use the free and open source Frhed).

Getting Started

First, identify which characters we're going to mess with and backup their chara directories. I'll be using Chun Li's model (I'll refer to her as the 'donor') on Sagat's moveset (I'll refer to him as the 'receiver'), so I made copies of those files.

Next, run the donor's cos and col files through the Asset Explorer, along with both characters' cmn.emz files (in my case, CNL.cmn.emz and SGT.cmn.emz). This will decompress them and get them ready for modding.

Now, open the donor's cos and col files in a hex editor, scroll all the way down to the bottoms of the files and change the 3-letter character name references to match the receivers'. In my case, I changed the CNL instances to SGT (there will be 4 instances to change in the cos file and 2 in the col file). Then, rename the files to match (e.g., CNL_01.cos.emz to SGT_01.cos.emz and CNL_01_01.col.emz to SGT_01_01.col.emz).

At this point, you should copy those new donor model files over to the receiver's chara folder (in my case, the SGT directory) and make sure the game loads without crashing. If it loads ok, you should see some monkeyface. Good job, we're halfway there.

Extracting the CMN components

Now, open the receiver's cmn.emz file in the Asset Explorer. Click the 'plus' signs to expand the base file and the overall #EMB file, like this:

Then, left-click on the first section (#EMO (SGT.skl.emo)) to select it and then right-click on it and choose 'Raw dump...' Repeat this process for each section in the cmn.emz file except for the *.cam.ema file, which will crash the Asset Explorer if you select it. Unfortunately, we need that section, so we'll have to get it the hard way--via hex editor.

Isolating the cam.ema Component

Open the receiver's cmn.emz file in a hex editor and make your way down to the third section labeled '#EMA' (I find it easiest to search sequentially through the document for #EMA 3 times). It will be the last one in the file.

Now, write down where it starts, in my case x760e40.

Next, we need to find the end of that section, which is most easily accomplished by searching again, but this time for '#BAC.'

Now, select everything between that last #EMA (at the location we wrote down) and the beginning of #BAC

Copy it and paste it into a new file and save it with the appropriate name (in my case, SGT.cam.ema):

Ok, now that we have all of our receiver's cmn components extracted and isolated, we're ready to get our donor's face animation ready for transplantation.

Open the donor's cmn.emz file in the Asset Explorer and expand it just like we did with the receiver's cmn file earlier on. Left-click on the section labeled #EMA (***.fce.ema) and then right-click and select 'Raw dump...' just like before.

Now, we want to rename that file--in my case, CNL.fce.ema--to match the receiver's other files (you'll have to overwrite the receiver's original fce.ema file in the process, but we don't need it anyway, so no big deal). Alright, we're almost there. Time to rebuild the receiver's cmn file with the new face data using Kensou's Tool.

Repacking A New File

Open up the directory for Kensou's Tool, then navigate to 'sf4' and then the 'emz' directory (you might have to create this directory if it doesn't already exist). Take your receiver's 6 original cmn component files that we raw-dumped, along with the renamed fac.ema file from our donor, and place them all in the aforementioned 'emz' directory:

Go back into the sf4 directory and launch sf4tool.exe:

In the big pane to the right with all of the directory structure, double-click on the folder labeled 'emz,' then click on the left-hand button below that pane. It should then populate the smaller, lower-left pane with a bunch of paths referencing our cmn component files:

These files need to be in exactly the same order as the ones in the original cmn.emz file (skl.emo, skl.emm, obj.ema, fce.ema, cam.ema, bac and bcm) but they won't be by default, so we'll need to click into that pane and do a little manual reordering. Everything should be in order except for the last two, so just copy/paste their paths into the right spots.

Once that's done, click the right-hand button to combine everything. It should pop up this window:

and you should have a shiny new file named 'newpack.emz' alongside your original cmn component files in the 'emz' directory. Now we're really in the home stretch.

Testing it Out

Rename your newpack.emz file to match the receiver's cmn file--in my case, SGT.cmn.emz.

Copy that file into your receiver's chara directory and overwrite the old one (you made sure to make a backup, right? Right??) and go test it out.

If you did everything correctly, you should have a perfectly normal face:

Congratulations!

Mudlord's HLSL Shaders for BSNES

2011-02-01T21:27:00.000-08:00

I came across a set of HLSL pixel shaders from mudlord that were intended for use with snes9x, so I formatted them for use with bsnes and everything seems to work just fine. You can download the whole pack here.

Here are some screenshots from a couple of them:

1. Emboss

Looks pretty cool but gets old quickly.

2. Blur 2

There are 4 different blur settings. The first one actually looks pretty decent, but the rest are too intense for me.

3. Pixelator

Hmmm. Can't really see shit... Kinda like if your favorite SNES game came out on Atari first.

4. Toon

This one actually looks really cool. It makes everything look like Yoshi's Island :D

There are a number of others in the pack, including all of the blurs, another take on bloom, a toon shader without the black outlines and a couple that cover everything with a wave mask.

This pack gives D3D users a bit more freedom beyond the lone Sepia filter that comes with bsnes, and I hope to add more of these in the future. I'll post them here if/when I come across them.

UPDATE (2/2/11):

I fiddled around with some and came up with a couple more. They're essentially functioning just like mudlord's 'emboss' shader, but they maintain color:

1. color emboss bright

2. color emboss mild (this one requires that 'smooth video' be enabled to work properly; similar results to smooth video+mudlord's 'sharpen' shader)

BSNES on Older Distros, such as Lucid and Squeeze

2011-01-24T12:47:00.000-08:00

In addition to being on the forefront of SNES emulation, BSNES also utilizes cutting-edge programming techniques to maintain the cleanest, most easily readable code possible. Unfortunately, that means that older distros--even ones that are still well within their supported lifespan--may get left out in the cold.

However, BSNES forums user Themaister has done us all a favor and backported byuu's cutting-edge C++0x code to use the more widely supported C++98 standard, which allows it to be compiled on any version of GCC from 3.x on up. The only catch is that his work only applies to libsnes, the modular emulation core of BSNES in library form, so byuu's official Phoenix GUI is still off limits, as is his libsnes-driven Qt GUI.

Thankfully, Themaister has us covered here, too, by offering SSNES, his super-slim CLI-only interface to libsnes. Just like his C++98 port of libsnes, SSNES can be readily compiled with even extremely old versions of GCC, so any semi-modern distro should be able to use it just fine.

My PPA now contains Lucid packages for both libsnes (all three official cores, plus an snes9x-based core for legacy machines) and SSNES, which should also (hopefully) work on Debian Squeeze.

A few things I'd like to point out about SSNES:

1. It will accept a variety of audio drivers, including jack, which allows ultra-low latency :D

2. My package was built using dynamic libsnes linking, so it requires a libsnes package from my PPA to function

3. In addition to accepting BSNES-style XML shaders written in GLSL, SSNES will also accept shaders written in Nvidia's Cg language if you install the nvidia-cg-toolkit package

4. The default configuration file for SSNES is located at /etc/ssnes.cfg, but you can override this by placing another config file in ~/.config/ssnes

As always, let me know if you run into any problems with these packages.

Crimson Echoes and Flames of Eternity

2011-01-20T07:49:00.001-08:00

These two ROMhacks for the legendary SNES RPG Chrono Trigger were just leaked on Reddit the other day and I happened across some bsnes-compatible UPS patches, which you can download here. (I didn't make these patches, btw, and I didn't upload them)

I haven't played through them yet, but they seem to work fine from what I've seen. They will get past the initial intro sequence and into the playable game, but I haven't tested any further than that.

They were tested with an unheadered Chrono Trigger ROM that had been run through snespurify.

I'll update this post with anything interesting I find in my playthrough.

Setting Up Pbuilder To Act Like Launchpad Build Farm

2011-01-15T06:05:00.000-08:00

I build a lot of packages for my Launchpad PPA and I use a number of different systems to do it, so I find myself needing to set up pbuilder environments to test my build procedures pretty often. Unfortunately, documentation for this procedure is often out of date and/or goes into a lot of strange details and edge-cases that are unrelated to me, so I decided to write down my steps for future reference.

Here's what I do:
1. Install pbuilder and some other handy packages
Open up a terminal and type:

sudo aptitude install pbuilder debhelper devscripts build-essential

2. Tell the pbuilder environment that it is going to act just like the Launchpad build farm
Still in our terminal:

sudo pbuilder create --debootstrapopts --variant=buildd

This one takes a while because it's basically installing an entire system inside your existing installation, so grab a cup of coffee and watch the messages fly by.

3. Give it access to all official Ubuntu repositories

By default, your shiny new pbuilder environment won't have access to a lot of packages, so we'll want to add mirrors for common Ubuntu packages, as well as our own PPA to the pbuilder configuration file. So, still in a terminal, type:

nano ~/.pbuilderrc

and paste in:

OTHERMIRROR="deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION] main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-backports main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-security main restricted universe multiverse | deb http://archive.ubuntu.com/ubuntu [YOUR UBUNTU VERSION]-updates main restricted universe multiverse"

and we'll also pipe on a section for our PPA, so we can use our own packages as dependencies, which in my case looks like this:

| deb http://ppa.launchpad.net/hunter-kaller/ppa/ubuntu maverick main

4. Make our pbuilder trust packages from our PPA

First, we'll login to our pbuilder environment:

sudo pbuilder --login --save-after-login

Then, we'll give it the public key to our PPA, just like if we were adding it to our own keyring:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys [YOUR PUBLIC KEY HERE]

If all goes well, you can leave your pbuilder environment by typing:

exit

5. Update our environment with these new packages

Still in our terminal, type:

sudo pbuilder --update --override-config

This should get you in pretty good shape. Let me know if you run into any issues.

Bloom Pixel Shader for bsnes

2011-01-11T13:06:00.000-08:00

I did some digging around online and came across some bloom filters written in GLSL. The one on this site looked the best to my eyes, so I converted it to work with bsnes and tweaked the settings a bit to achieve the desired effects.

What I found while playing around with it is:

1. Turning on 'Smooth video' seems to amplify the bloom effect.

2. The same amount of bloom looks different on each game, depending on the overall dark/light-ness of the game.

3. Combining excessive bloom with bsnes' scanline filters can make a pretty decent approximation of a CRT. While this is in no way as accurate or as nice looking as cgwg's CRT shaders, it may be an option for the many people whose video cards don't have enough horsepower to handle that complex shader.

First, I made a simple, fairly subtle (as far as bloom is concerned...) shader, which looks like this:

Looks pretty nice, eh? Unfortunately, the exact same shader settings look awful in Super Mario World:

One big flare-out... All I need is some brown and lens flare and I'll have next-gen graphics.

However, if you add in a scanline filter, things can really get evened out. In fact, you can use the different scanline intensity filters on a game-to-game basis to attenuate the inconsistency of the bloom effect. For example, here's a shot of Super Mario World with even more bloom added and 'smooth video' checked, but with 100% scanlines to chill things out a bit:

As you can see, it kinda gives it a plasticy, oversaturated look, but it's sort of charming, if you ask me.

In contrast, those exact same settings in Chrono Trigger--an altogether darker game--produce a really nice CRT-style effect, like this:

As you can see, even the bright parts don't suffer from excessive flare-out and the color bleed into the scanlines from the bloom provides an effect that is reminiscent of the phosphor glow on a CRT display.

One more shot of Chrono Trigger, this time using heavy bloom, 25% scanlines and smooth video:

I have asked WhateverMan if he would release his shader code under a permissive license. If he does, I will post my simplebloom and heavybloom versions here for download.

Update (1/19/11): WhateverMan was nice enough to allow his work to be distributed/modified under the GPL, so you can download the heavybloom shader here and the simplebloom shader here.

Update (2/2/11):

I also made a simple scanline shader that works with or without video smoothing:

For best results, use it along with a scale factor of 4x. Otherwise, the pixels won't line up with the scanlines correctly.

UPDATE (2/28/11): I made a scanline shader that works with a 3x scale factor, as well. You can download it (and the other GLSL shaders) here.

Added NEStopia to my Ubuntu PPA

2011-01-01T20:01:00.000-08:00

I added packages for the latest Linux port of the awesome NES emulator NEStopia to my PPA. The only problem is that I don't know how to make a package create a ~/.[appname] config directory and/or put required config files into that directory at first run. If anyone knows how to do that, I'd appreciate the info. EDIT: Ok, I fixed it. I created a quick-and-dirty bash launcher script that will check for the required directory and file and create them if needed.

NO LONGER NECESSARY:

Unless/until I find out how to do that, anyone wanting to use my package will have to manually create the config directory and at least create a husk of an inputs file by opening a terminal and typing:

mkdir .nestopia ; touch .nestopia/nstcontrols

From that point on, everything should work fine. If you are super-scared of hitting the terminal and would feel better with a script, you can download and run this script and it will take care of it for you.

Let me know if you run into any issues or have any questions.

CRT Pixel Shader Filter for SNES Emulation

2010-12-28T13:46:00.000-08:00

Update 05/18/2011: More screenshots for more new filters in my new post. :-)

Update 05/02/11: After many changes, it looks like the CRT shader development has settled down, so there's less need for me to maintain the older versions of the shaders. From here on out, I recommend visiting Screwtape's git repo for all of your XML shader needs (my mediafire account will still be there, but Screwtape has all of mine and more).

CRT.OpenGL.shader and CRT-flat.OpenGL.shader are similar to the shader covered in this post, though they run slightly faster and have no visible artifacts. CRT-simple.OpenGL.shader is a simplified rewrite that should be usable on much older, slower machines.

Here is the original post for informational purposes:

This post covers the use of filters to upscale pixel art--specifically as it applies to SNES emulation--with special attention to CRT reproduction. If you just want the pictures and to download the filters, skip to the bottom of the post.

Background:

As everyone who dabbles in old-school emulation knows, artwork that was intended for a 480i CRT television that has been upscaled to an HD resolution looks like absolute garbage on an LCD monitor. The chunky sprites with their often thick, cartoony outlines just weren't designed to be reproduced with sharp edges resulting from nearest-neighbor upscaling.

To get around this ugly upscaling effect, many emulators now include upscaling interpolation filters, which apply complex mathematical algorithms to the original picture to fill in the gaps between things that are impossible to represent in chunky low-res, such as curves and smooth diagonal lines. You're probably familiar with some of the more common and popular interpolating filters, such as SuperEagle, SuperSaI and HQ2x. Unfortunately, none of these filters gets everything quite right, especially numbers and letters, which can look bubbly or overly smoothed (you can learn more about pixel art scaling algorithms here).

Purists have long been turned off by the inaccuracies of interpolating filters and have instead used scanline masks to try and capture the effect of an interlaced display, relying on the human brain's natural ability to recognize patterns and fill in the gaps between lines (you can learn everything you ever wanted to know about scanlines here). However, this too falls short from a true representation of a CRT display, as it ignores the existence of phosphors--the tiny red-, green- and blue-colored lenses that the electron gun in the back of a CRT tube shoots with a beam of electrons to recreate a colored pixel--and the color bleed that naturally occurs in these displays.

Recently, a number of determined individuals have set out to try and capture all of the different effects of a CRT display, warts and all, to truly reproduce classic pixel art the way it was meant to be viewed.

The Comparisons:

(Each of these images is presented as it would be displayed onscreen, at a resolution of approximately 800x600, then again at 400% scale without any interpolation used when scaling; as always, click the thumbnail to embiggen)

First, we should look at the baseline. This was scaled up to size using nearest-neighbor and is otherwise untouched:

Next, we'll add blargg's NTSC filter, which emulates the noise and color bleed of an NTSC video signal (this filter has several presets; I will only be showing the RGB preset, which reproduces the look of an SNES hooked up via RGB connection [not available in the U.S.], and the RF preset, which reproduces the look of the SNES RF modulator attachment, respectively):

(<- Look at that noisy RF signal!)

As a note, blargg's NTSC filter is so accurate that byuu, the author of bsnes, recommends its use along with bsnes' accuracy profile to achieve proper blending on games that use halftones to simulate transparency (Jurassic Park and Kirby's Dreamland, for example).

Next up, we'll look at cgwg's CRT shader, which includes a phosphor mask and barrel distortion to simulate the screen curvature of a CRT television (just look at those RGB phophors!):

Similarly, there is a version of cgwg's CRT shader, which doesn't include the barrel distortion and represents an idealized flat CRT (actual flat CRTs tended to have slight blurring at the edges where the tube curvature would normally be). Incidentally, this version also has no visible garbage pixels (the occasional black specs that are visible in the curved version):

Pixel Shaders vs. Software Filters

cgwg's CRT shader is a special kind of filter known as a pixel shader. Unlike regular filters, which rely on the CPU to do all of the complex upscaling calculations, pixel shaders draw on the awesome computing power of the video card to do the calculations, thereby leaving the CPU to focus on emulating the SNES. Additionally, since the pixel shader is calculated separately from the filter in bsnes, you can stack blargg's NTSC filter with cgwg's CRT shader:

Finally, for non-purists, we'll look at the combination of cgwg's CRT shader with the popular SuperSaI filter, which creates a pleasing--though not quite as accurate--output:

As amazing as cgwg's CRT shader is already, there is still some room for improvement. For example, the current implementation misses the intensity-based bloom effect on individual phosphors that can be seen in a true CRT. DOLLS (J) [!], one of the contributors to the CRT reproduction effort, intends to write a more complete CRT emulation shader in the future that will incorporate these and other idiosyncracies.

Click here to download cgwg's CRT shader (Also includes the 'flat' version for those who don't like the tube-style curvature; UPDATE: fixed dead link), which is compatible with bsnes and the newest release of snes9x. For more information on CRT emulation, you can check out this highly informative thread on the bsnes forum. For other bsnes-compatible shaders that are not included with the official download, check out my mediafire account.

UPDATE (3/4/2011): Themaister did a rewrite of the flat version of cgwg's CRT shader, moving many of the calculations from fragment to vertex, which provides a substantial ~20% increase in speed (making it usable on many older and less powerful video cards). This rewrite also appears to conform more rigidly to the GLSL shader spec, making it compatible with more cards from different vendors. I have labeled it v4 of cgwg's CRT Flat, and it is available in the aforemented mediafire account.