Filthy Pants: A Computer Blog

HTC One Back Template for DIY Case Artwork

2013-06-11T14:10:00.002-07:00

I got a super-cheap, clear hardshell case (price seems to have gone up since I bought it...) for my HTC One and was interested in making some custom art to put between the case and the phone. I wasn't able to find any templates readily available online, so I spent a little bit of time with a flatbed scanner and whipped one up myself:

Note: I make no guarantees about the applicability of this template to your own case. It worked for me and I hope you find it useful, as well. The biggest potential issue would be with the cutaways for the power and volume buttons, which are pretty large on my case, but it should be easy to remove them if your case doesn't have them.

Here's how it looks when it's all finished:

Sorry about the weird picture. I didn't have another camera on hand, and there weren't any good mirrors at work, so I had to just use the reflection from an old hard drive platter...

EDIT: Here's a slightly better picture:

I made this BMO design along with a couple of other Adventure Time designs, ready to print:

Best show on television.

Setting up a Cydia Repository

2013-05-31T07:39:00.000-07:00

For RetroArch v0.9.9, the new star platform for support is/was iOS via jailbreak, so we needed to set up a Cydia repository for people to pull down the app. I followed this guide, which was helpful, but there were a few important deficiencies that required additional work. I'm going to cover those issues here.

First off, the directory structure described in the guide, with 'apps' and 'uploads' is unnecessary. All you need is a directory that contains your Packages.gz file and a subdirectory named 'deb' that holds your package. If you keep the directory structure from the guide, your Cydia URL will be http://yoursite.com/cydia/upload, which is tacky.

More importantly, if you follow the guide, your app will not install to the /Applications directory of your iOS device, and any *.info files will be broken, which was very bad news for RetroArch. To fix this, I followed this guide, the important parts from which I will summarize here:

First, you'll need to take create a new directory with the same name as your application--in my case, RetroArch. Then, inside that directory, create another new directory named Applications and one named DEBIAN. In the DEBIAN directory, place your 'control' file, which contains information about your application, and in the Applications directory, place your compiled application (in my case RetroArch.app).

At this point, you're ready to bundle your application using dpkg:

dpkg -b [your.app.name]

Once your deb is created, you can delete the directory structure and then create your Packages.gz:

dpkg-scanpackages -m . /dev/null | gzip -9c >Packages.gz

Create a directory called 'deb' and drop your deb bundle into it and you should be all set.

Fix for: Google Voice Search force closes immediately

2013-05-15T12:41:00.006-07:00

This is just a quick post and it may or may not work in your case: I installed a nightly of Cyanogenmod 10.1 on my HTC One and the Google Voice Search app force closed every time I clicked on the little microphone icon. Everything else worked fine, including Google Now and so forth.

The fix for it, in my case, was just to go to the Play Store and update the Google Search app. If that doesn't fix it for you, I would recommend uninstalling the Google Search app entirely and then reinstalling. If that doesn't help either, you probably have something more serious amiss.

Multipass Shaders - NTSC, Motion Blur and More

2013-04-25T20:56:00.000-07:00

It's been a while since I've done one of these posts and, in that time, RetroArch's multipass shader implementation has matured quite a bit, paving the way for a lot of really cool effects that simply can't be done in a single pass. At the time of this writing, higan's multipass shader implementation hasn't been released yet, but many of these shaders should be portable to it (with some substantial effort, at least) when it arrives.

As always, images were captured at 4x scale. Click the thumbnails to embiggen.

First up:
Themaister's NTSC Shader
Themaister wrote a sweet new real-time NTSC Composite shader that mimics a lot of the noise, fringing and crosstalk present in the NTSC composite signal:

This shader is a big deal because blargg's CPU-based NTSC filter was previously the only way to get this effect, which was important in some older games' art design. However, the filter had to be hardcoded to the individual consoles' specific resolution, which made it a headache to maintain in a multi-console setting. This shader should work on all of RetroArch's cores, and it is available in GLSL and Cg/cgp flavors.

I mixed it with cgwg's CRT shader and ended up with this (ntsc2-crt.shader):

You can compare that with an earlier version I cobbled together from the old NTSC shader--which tended to be finicky and not everyone liked anyway--and cgwg's CRT (crt-geom-interlaced-flat-ntsc.shader):

Digging through an old thread on byuu's forum, I also found where cgwg had written a similar shader that combined NTSC with CRT in 6 passes with barrel distortion (6-pass-ntsc+crt2.shader):

In the same thread, cgwg had posted this shader, called 'beam-dynamic,' that is essentially the same result as the beam4 shader mentioned in one of my other posts:

Out of all of these variations, I think my favorite is Themaister's NTSC with the addition of scanlines that have been softened with gaussian blur (ntsc2-maister-scanlines.shader):

Harlequin's Gameboy Shader
This shader does for Gameboy emulators what cgwg's CRT does for regular consoles, i.e., recreates the look of the original display with startling verisimilitude:

I'm not going to spend a lot of time talking about this shader here, even though it's completely badassed, since it's covered at length in a previous post. It's available in Cg/cgp format only, though you can use Themaister's handy cg-to-glsl python script to convert it to GLSL if necessary.

Harlequin's LCD Shader
Using some of the same concepts from the Gameboy shader, Harlequin is also working on a more generalized shader that mimics the low-resolution, slow-refreshing color LCD displays from a number of handheld consoles, such as Sega's Game Gear and Nintendo's Gameboy Advance:

Similarly, cgwg posted an LCD shader he's been working on that produces a regular, square pixel grid pattern, paired with some simple motion blur (lcd-cgwg.shader):

Motion Blur
Speaking of motion blur, I wrote a multipass version of this shader a while back and cgwg revised it down to a single pass (refers to previous frames, so still incompatible with higan v092 and earlier). This effect can be good for mimicking the slow response time of crummy LCDs (motion blur.shader):

I also made a version that only adds the blur during rewind, along with a little sepia-tone effect, kinda like the rewind effect in Braid (braid rewind.shader):

This shader can be added before pretty much any other shader (either manually by pasting in the code or by using the new, built-in RGUI shader stacking function and/or glslp shader configuration files) at a scale of 1.0 and the effect will only kick in when the game is rewinding :D

GTU
This shader from aliaspider is an interesting take on the CRT paradigm insofar as he didn't want to focus on phosphor emulation or heavy-handed scanlines or any of that other jazz. He was more interested in the blurring/blending effect of CRTs that enabled tricks like pseudo-hires transparency and color dithering. Later revisions include some sweet gamma correction and the ability to create mild scanlines (if you choose; GTUv031-multipass.shader):

I think this is one of the best ways to get pseudo-hires transparency working properly, and the transparency it creates is smooth and absolutely beautiful:

Aliaspider made a single-pass version of the shader that should work in higan v092 and earlier, along with the multipass version linked above for RetroArch, and a multipass version for higan v093's upcoming shader implementation.

My 4k Phosphor Shader
This is another one that I won't spend much time on, since I cover it at length in another post:

This shader currently doesn't look so hot as it's designed to work at around 10x scale (i.e., on a 4k resolution television or other high-DPI display; it gets wrecked by subpixel behavior at current normal scales [read: 1080p]). However, it brings some nice things to the table, such as easily-edited LUTs that can be created/modified in Photoshop/GIMP rather than a text editor and scale-ability to freaky-huge resolutions. I'll attempt to convert this to byuu's higan v093 format at some point, though it may take some time.

Customizing Harlequin's Gameboy Cg Pixel Shader

2013-04-24T20:31:00.001-07:00

CRT shaders are great, but they're not always appropriate for every console, seeing as handhelds' tiny LCD screens have very different characteristics, which in turn shaped the way the games for those consoles were designed. The original Gameboy handheld had these characteristics in spades, including a slow response time (manifesting as motion blur), very low resolution and a distinctive 2-color palette that ranged from yellow to green. Emulators typically represent this color palette as black and white, which can be jarring for people who spent a lot of time with the system.

Thankfully, a nice fellow named Harlequin has come to the rescue with a really great pixel shader for RetroArch that does for Gameboy displays what cgwg's CRT shader did for those displays. Like cgwg's CRT shader, Harlequin's Gameboy shader reproduces a lot of different aspects of the Gameboy display and presents a number of options to the user that are easy to modify with just a simple text editor (I use/prefer Notepad++ but almost anything will work). Unlike cgwg's, though, the Gameboy shader also uses some lookup textures (LUT) that require no text editing and can be modified using an image editor such as Photoshop or GIMP. Harlequin has included several example LUTs and I'll cover a few in screenshots.

As usual, all shots are at 4x (which is a bit small for Gameboy resolution, but oh well) and you can click the thumbnails to embiggen. All shots were taken via RetroArch with the Gambatte core unless stated otherwise.

First, here's an unfiltered shot for comparison:

And here's one of Harlequin's Gameboy shader with default parameters:

First, I'll cover the LUTs, which can be edited with an image editor. The palette files are found in the 'resources' folder and they're just two 64x64 squares of color that the shader pulls from to get the appropriate colors (i.e., to replace white and black in the emulator). One of the included samples is yellower and resembles the display in strong light, such as daylight:

Another sample mimics the higher contrast of the Gameboy Pocket revision:

Also in the resources folder, you'll find some sample backgrounds, which apply a texture to the image. The default has some angled hatching, while the included samples show some different types of texture that are possible, like this noisy bit:

Next up, we have the shader variables that are easily modified by users with a simple text editor. These are enumerated in the shader's enclosed README file and I'll include some shots here for reference.

The first one is the 'alpha' setting, which determines how dark a 'white' pixel should be. If you raise the value, everything becomes darker:

While lowering the value will make the pixel grid less visible in white areas:

The next option, response time, determines how long it takes a pixel to go from white to black and vice versa. It doesn't really translate very well into static screenshots so I didn't bother showing it here. The next option after that, though--blending mode--determines whether just the space between dots is blended (mode 0) or all texels (mode 1), which, in practical terms, is how sharp/blurry the edges of the individual pixels are:

The next option--texel alpha blending--effectively controls how defined the grid pattern is. Higher values result in round/fat-looking pixels:

While lower values give you a sharp, well-defined grid:

After that, we have 'contrast,' which works just like the slider on the side of the Gameboy. Lower values can simulate the look of low batteries:

'Background smoothing' lessens the effect of the background LUT. Higher values make the background less visible, lower values make it more visible:

'Shadow opacity' controls how dark the drop-shadows from the pixels are. Higher values mean darker shadows:

Finally, 'shadow offset' determines which direction the drop-shadows appear (i.e., for simulating a light source that isn't directly above the display). Setting both the X- and Y- values to 2.0 will offset it more:

While setting them both to 0 puts the shadows directly underneath the pixels:

Just so you know: you can use this shader with other RetroArch cores, as well, and see what your favorite games would look like in an alternate, Gameboy-centric universe:

Harlequin has made some major changes to the way the shader looks and works since he first started working on it. While the current iteration is extremely convincing, I also liked an earlier version that looked more stylized. Here's a couple of shots:

You can download it from my Mediafire.

Pixel Shaders for RetroArch 3D Cores

2013-03-14T20:55:00.002-07:00

RetroArch got its first 3D core recently in the form of TyrQuake and it seems most of the existing pixel shaders either look unimpressive or don't work at all. Thankfully, shaders written for Pete's OpenGL plugin for PSX emulators are easy to port to RetroArch's XML format and they seem to generally work well enough.

Click here to download all of the shaders covered in this post.

No Shader (for comparison)

A Lovely Bloom

One of the few conventional shaders that still functions as expected, this one looks really nice, and the screenshot doesn't really do it justice. It gives light sources a nice bloomy glow that softens things up a bit.

HDRTV

This shader saturates colors somewhat and adds faint scanlines. It has been around for a long time (it was one of the original shaders available for bsnes when it first got pixel shader support) but the scanlines weren't visible on 2D sources, so I was surprised to see them here.

NV+MSAA

This shader uses the "natural vision" algorithm to do some color adjustment with added post-proc anti-aliasing.

Cartoon

This one darkens the image too much to be very useful in an already dark game like Quake but may be good for future cores that have brighter games.

Edge Detection

While not necessarily practical, this shader draws a line at each color intersection to produce a cool, old-timey effect.

Scale4xHQ

One of the only scale/interpolation shaders that has any noticeable effect, this one is a bit blurry for my tastes but it evens out a lot of the jaggies.

Scanline3x

I'm a sucker for scanlines and these normally crummy-looking scanline filters I made a while back actually look pretty nice here. (Note: I think I got the 3x and 4x mixed up; 3x should have fewer, larger scanlines than 4x)

Scanline4x

Themaister Waterpaint Scanlines

While the effect isn't as pronounced as with 2D cores, this shader does some smoothing with scanlines and ends up with a sort of screen-door effect that nevertheless looks pretty good.

CPU Filters

Some of the bsnes-style CPU filters work, but not that well. The NTSC variants all perform their normal functions, but the the image is off-center and cuts some things off, as pictured. The scanline filters work pretty well, too, though they're sort of hard to see. Interpolation filters like HQ2X seem to have no visible effect, and SuperEagle crashed my game :/

XRandR Overscan Fix for Intel HD4000 Ubuntu

2013-03-11T15:08:00.002-07:00

I have my television hooked up to a computer running Ubuntu 12.10 Quantal and have had issues with overscan across a variety of chipsets. For Nvidia graphics, the proprietary driver sometimes has an overscan compensation slider or at least something. Intel drivers are open source and very convenient but don't seem to have much in the way of driver configuration outside of what's exposed in the normal settings applications.

If you have an Intel chipset, such as the built-in HD4000 graphics that come with Ivy Bridge CPUs, there are a few angles you can try that center around using xrandr, which stands for 'X Resize, Rotate and Reflection.' This program has a bunch of different options, and I strongly recommend spending some time with the man page. No matter which options you try first, you'll need to query the program and see which display device is being used. You can do this by typing into a terminal:
xrandr -q
For me, HDMI3 is the one that's hooked up, so it lists all of the available modelines and some other information.

Now that we know which device is being used, we can invoke xrandr with this syntax:
xrandr --output [device] --[option]

The option that worked for me is --transform, which performs some crazy matrix math that I don't understand (I'll update this post if someone tells me wtf is going on) on each pixel, apparently kinda like the pixel shader stuff I've written about elsewhere, I think...? Anyway (replace HDMI3 with whatever your device is called):
xrandr --output HDMI3 --transform 1.05,0,-35,0,1.05,-19,0,0,1
This doesn't make it fit exactly on my screen but it's much closer than it was. Unfortunately, it gets wiped out every time you logout, so we need to do something to make it stick. You can add it to your startup items or tack it onto your lightdm window manager's configuration file by typing into a terminal:
sudo nano /etc/lightdm/lightdm.conf
Navigate to the end of the file and start a new line and paste this in:
display-setup-script=xrandr --output HDMI3 --transform 1.05,0,-35,0,1.05,-19,0,0,1
Save and exit and the transform command should kick in every time you login.

Other options that may help:
The 'scale' option should ideally just scale your screen down, but in my experience, it makes everything (text, window borders , etc) bigger, similar to changing the DPI in Windows, without actually changing the visible area.

The 'border' option also seems like it should do exactly what we want, but I haven't seen it actually work anywhere. On my system, it fails with this error:

X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 11 (RRQueryOutputProperty)
Serial number of failed request: 29
Current serial number in output stream: 29

which seems to be a catch-all for unrecognized commands :/

Generally, I would recommend skipping all of this and attempting to fix it through your TV's built-in options (generally called "just scan" mode or "pixel perfect" or something like that). The only time you should attempt to do it in software is when your TV is too crummy (like mine) and doesn't have any of those options.

How to Swap Stages in SSF4AE

2013-02-21T15:41:00.001-08:00

With a lot of new stages being backported from SFxT and some brand new stages from mugenlove100, Alff suggested I write a tutorial on swapping around stages. It's a very simple process but it requires a hex editor, which makes some people uncomfortable. I use the free and open-source Frhed, which is somewhat limited in functionality but is thankfully quite simple to use. As a general note, stage mods are often built from the Training Stage (abbreviated as TRN), but I'll be using one that started from the Brazilian Jungle stage, or BRA. For reference, here's a key that shows which abbreviations go with which stages:

So, to get started, we'll first want to make backups of the stage we're going to replace. Personally, I hate the Crumbling Laboratory stage, so I copy those files to a safe place. Then, take your stage mod files, in this case BRA.emz and BRA.tex.emz, and open them each in your hex editor, like this:

Next, use the find-and-replace function (the standard shortcut for this is ctrl+H; you'll have to do it in each of the modded stage files) to replace each instance of BRA (or TRN if the mod is based on the Training Stage) with the 3-letter prefix of whichever stage you wish to replace, in this case LBX:

Click the button to replace all following occurrences and it should pop up a message telling you how many instances were replaced (it's generally a much larger number for the ***.emz files than for the ***.tex.emz files, FYI).

Once that's done, just save it and close, then rename the modded stage to match the 3-letter prefix you just swapped in. In this case, I change BRA.tex.emz > LBX.tex.emz and BRA.emz > LBX.emz.

Now you just copy those modded stage files into your [install dir]\resource\battle\stage directory and overwrite what's already there. Just make sure you backed up those original files first, in case you change your mind later.

UPDATE: If you would rather not overwrite any of the files, there is a way to supersede the original stages in a non-destructive way. Instead of adding your modded files to the above directory, instead go to [install dir]\patch 1a\battle and create a new directory named 'stage'. Put your modded files in there and the game should use them instead of the originals. (thanks to Nemesys_Syndrome for the tip)

That's it. You're done. Now, go try it out and make sure it works :)

xsession-errors Log Filling Hard Drive Ubuntu

2013-02-18T20:52:00.000-08:00

Last night, all of a sudden, I started getting poor performance out of my HTPC running Ubuntu 12.10 Quantal Quetzal, followed by a complaint that my /home partition was running low on space and only had ~350 MB of free space. A minute or so later, I got another warning that only ~35 MB were free! :O

I clicked the hard drive disk usage analyzation utility to figure out what was up, but it showed my largest directory as weighing-in at just ~29 GB.

Turns out the culprit was a gigantic, hidden file called .xsession-errors, which had ballooned to 170 GB over the course of a couple of hours, apparently. You can check if this is your problem by typing this into a terminal:
ls -a -s | grep xsession
This file is archived at every reboot, with the previous version renamed to .xsession-errors.old and a new log created in its place. If this file is the source of your troubles, you'll want to see what's been spamming your system with errors, but, obviously, such a huge file isn't going to open gracefully in a text editor. However, we can use the 'tail' command to check out the last few lines, like this:
tail -10 .xession-errors
That should give you an idea of what's causing your problems. Once you've had a good look, go ahead and delete the file and then reboot your system to free up the space:
rm .xession-errors* ; sudo reboot now
As soon as your system comes back up, look for the error log again using the first command (and then a third time to see if the size changed in between commands) and then open it in a text editor to see what's up:
gedit .xsession-errors
Scroll down to the bottom and see if you spot any errors repeating. In my case, there was a constant stream of errors from zeitgeist-daemon not being able to find file:///whatever/file.path. Zeitgeist is a program that keeps track of pretty much everything you do on your machine and uses that data to populate 'recent files' lists and so on. It also adds overhead to your system and occasionally shits the bed by making giant error logs ;)

If you don't mind getting rid of the Unity desktop, you can just flat-out remove it and its associated packages like this:
sudo dpkg -r zeitgeist*
However, if this is too invasive for you, you can use the following command to remove the read and write attributes from the zeitgeist-daemon database:
chmod -rw ~/.local/share/zeitgeist/activity.sqlite
You can test the effect out by typing:
zeitgeist-daemon --replace
It should error out with a complaint about not being able to access the database, which is exactly what we want. This essentially cripples the daemon without risking breaking any other packages, present or future.

Go about your normal tasks and make sure everything still works like it should (anything that used zeitgeist will obviously be broken, but I mean everything that you normally depend on). If all is well, you're finished. Pat yourself on the back.

UPDATE: The problem popped up again, even with zeitgeist removed, so I tailed the error log again and saw this line repeated over and over:
Authentication deferred - ignoring client message
This error appears to be a result of the vino server (Ubuntu's built-in VNC server) getting hammered with bruce-force login attempts. It appears that the server allows a few bad attempts and then ignores the rest, which is good. The attempts still get logged, though, so I thought it best just to remove vino altogether, since I never use it anyway:
sudo apt-get remove vino

Designing a Large-scale Phosphor Filter/Shader

2013-02-14T07:49:00.001-08:00

Update (5/9/2013): I ported my shader to the Cg shader language and made some improvements in the process (click here to download). It now looks decent at sane, non-4k scale factors and has some easily-modified variables to allow users to make their own adjustments more easily. See the bottom of the post for new screenshots.

Update (3/29/2013): Some other versions of the shader and more screenies at the bottom of the post.
Update (3/18/2013): I think the shader is pretty much done! You can download it here. Skip to the bottom of the post for images and some details.

With 4k TVs on the horizon and high-dpi computer monitors already here, I figured it was time to start thinking about using these screens to better recreate the look of CRT TVs.

cgwg's CRT shader is already fantastic, but it was designed with the assumption of relatively low resolution (i.e., the current HD/1080p paradigm at the upper end and 720p screens at the lower end, resulting in ~3-4x scale factors) and single-pass shader implementations, and it makes certain concessions with those limitations in mind.

At 10x scale (2240 vertical pixels for NTSC) and assuming multipass support, we can forego some of those concessions, though. For example, you can draw the shadow mask right on the screen at 1 pixel width and each phosphor lens at 3 pixels tall by 9 pixels wide, which gives you a pattern like this (blurriness comes from the bilinear upscaling; click for normal size):

In this figure, the phosphors have a horizontal orientation rather than the vertical orientation seen in all of the phosphor images I've found online (like this one). I tried both ways and the vertical orientation didn't look right to me, insofar as it had vertical scanlines rather than horizontal ones. I'll show results both ways later on and you can judge for yourself.

Update (3/18/2013): Turns out the vertical orientation is correct. I got a macro lens and took some pictures of a CRT up close (the letter 'e' followed by a heart icon from Zelda OoT):

I still think it looks better horizontally at small scales (i.e., 1080p and lower) but vertically at larger scales. Anyway, back to the original post.

With that LUT tiled up to cover the entire SNES image (you can download it here), we're ready to add in our image, scaled to 10x using nearest-neighbor, which looks like this (click thumbnails for full resolution):

Next, we need to invert the colors in the image, which looks like this:

We then need to subtract these pixel color values from our LUT matrix, which results in this:

We subtract because the phosphor LUT represents a full 100% brightness in all phosphors, which is blended by our eyes into flat white. In our image, the white pixels are inverted to black, which subtracts nothing from our LUT and leaves those parts white, while magenta blanks out the red and blue pixels, leaving just green, and so on. Likewise, brighter pixels are inverted to dim, and they subtract less brightness from our LUT phosphors, leaving them bright. At this point, we have our basic phosphor coloration and luminance values represented.

Next, we'll make a new pass using the result of the previous pass as input (or in Photoshop, create a new layer), to which we'll apply a gaussian blur that will approximate the luminance-based color bleed into neighboring phosphors (no picture here, since it looks the same, just blurry; not very exciting). According to cgwg's comments in his existing CRT shader, this blur portion may be better suited to a 2-part process of blurring, once horizontally and once vertically, but I just did one all-over blur. You can use a blur intensity of 3 pixels to keep some sharpness or increase the value to 5 pixels to get a more bloomy, halated look. I'll show examples of both in a bit.

Obviously, this is image is still waaaay too dark, so we'll also need to crank up the brightness of our blurred layer to around 150% and combine it with the underlying raw image using the 'screen' method, which lightens everything a bit more. The math for a screen combine is f(a , b) = 1- (1 - a)(1 - b), where 'a' is the base layer value and 'b' is the blend value.

That gives us this result:

At this point, it looks pretty good and we could probably call it quits, but the darkening from the shadow mask is still monkeying with our perceived colors a bit, so I played around with the levels to try and get something that looked closer to the original image. I found that moving the black point to around 23 and the white point to around 179 while keeping the gray point at 1.0 gives a good, bright result:

This adjustment also ensures that blacks are actually black and not brown and whites are white instead of gray. Here's a comparison shot:

While we're looking at this Super Metroid shot anyway, lets zoom in and take a better look at the luminance-based glow created by our blur:

You can see where the brighter pixels bleed into the adjacent phosphors, particularly on the glowing suit highlights.

Using a 5 px gaussian blur bleeds the colors even more but ends up making the entire picture more hazy (3 px blur followed by 5 px blur):

You can see from the thumbnails that the 5 px picture looks nice from a distance, while the 3 px looks a lot better up close. So, you could make a valid argument for either one depending on your preferences and intended viewing distance.

The above process could work alright at a 5x scale, using a bilinear reduction on the LUT and a 1.5 px blur, and not look too bad:

But dropping it to 4x starts to really cause some problems with the colors, giving the appearance of too much gamma:

At these scales and lower, cgwg's CRT shader looks much, much better, due to his compensation for LCD subpixel aliasing (among other things, such as gamma interpolation, screen curvature, etc.).

The last thing I want to cover is the phosphor orientation. I oriented my LUT with red at the bottom and blue at the top because doing it the opposite way looks weird up close (notice how the red pixels on the shell create a sort of halo instead of having the intended cartoony black outline, as compared with the pictures above):

Likewise, using vertical phosphors--as shown in all of the phosphor images I could find online--looks like crap close up *and* far off (eschew the cutoff edge; click to embiggen):

At the moment, I've just been playing around with Photoshop, but I hope to do some work on a legit shader that performs this process in real time. Unfortunately, I suck ass at writing GLSL, so it may never get anywhere. If anyone else would like to take a stab at it, I'm happy to provide any information I have.

Update: For the Photoshop steps, Romain Dura has helpfully converted the math functions to GLSL, and the gaussian blur steps from cgwg's halated CRT shader can drop right in.

Update 2: I cobbled together some code that works at least partially and I'm pleased with the outcome so far. I don't have a high dpi screen, so I'm stuck working at 4x, but I think the code should work fine with a larger resolution.

Currently, I can get it to the point where it has the shadow mask and phosphor lenses, as well as gaussian blur (though the blur is happening underneath the phosphors, which isn't exactly what I wanted):

This is obviously much too dark, but when I tried to lighten it up, I couldn't get things looking quite right. It would either blast out the colors underneath or make the phosphors visible on a flat black screen, which is unacceptable. When I tried adding a bloom pass, the phosphor bleed looked good (if a bit exaggerated) and the brightness was pretty close but the colors got totally wrecked >.<

Oh well... I'll keep at it. If anyone wants to play around with the code I've got so far and/or play around with my phosphor LUT, you can get it here.

Update 3: As cgwg pointed out in the comments, mapping the phosphors 1:1 on the SNES pixels, like I did above, isn't really how TVs worked. They were designed to receive a 480i signal (i.e., 2 sets of 240 lines of resolution, alternating which lines get displayed for an effective 30 fps), as per the NTSC broadcast spec, which Nintendo and others tweaked to show just 240(ish) lines, non-alternating, at 60 fps. This format goes by many names, including non-interlaced mode, 240p (not a real spec, btw) and "double-strike."

I did some more mockups using the same procedure as above, but using a phosphor array that's ~480 pixels tall (I actually went with 448; i.e., double the SNES res) and started with an image that should match the "double-strike" idea at 10x, namely, a 20x image with half of the pixels blanked out, like this (note, it looks exactly like if you added a 100% black scanline filter; if this is somehow incorrect, I'd love to hear about it in the comments):

Since the vertical resolution doubled, I also doubled the pixel radius of the gaussian blur, up to 6 px and, instead of adjusting the levels, I increased the brightness by 300% and the contrast by 25%, which resulted in this (crap: blogspot won't display that large of a file and insists on shrinking it and converting to jpg; here's a link to download the full-res if anyone wants it). And here it is shrunken bilinearly back down to 10x:

It still looks pretty nice. And here's a detail shot:

Interestingly, at this scale, the vertically oriented phosphors look a lot better and produce an image that's much less scanliney, so perhaps it is the better option:

Here's a link to download that vertically oriented shadow mask / phosphor LUT, if anyone's interested in playing around with it.

UPDATE (3/18/2013): After digging around in an old thread on byuu's forum, I came across a post from Themaister where he explained how to go about using and accessing various framebuffers in shaders, which allowed me to finish this one up, for the most part (at least to the point where I don't have to keep poking away at it). It's a real beast of a shader and doesn't run fullspeed on the Intel HD4000 I've been testing with, but it looks pretty good in slow motion :P

You can download the shader and a couple of LUTs here. (same as the link at the top of the post)

I included 240p and 480p LUTs with both horizontal and vertical phosphor orientations. The 240phoriz LUT will give you essentially the image I was going for at the start of this post:

Notice, these shots look a bit dark, due to the way the LUT gets shrunken on my 1080p/4x scale screen. In the shader, there's a line you can uncomment when you're on a low-resolution screen like this to make the colors a bit brighter, which gives you something like this:

For anyone on a larger screen (or if you'd like to play around with the higher-resolution LUTs), I also included 480p variants, the vertical version of which looks like this:

Again, these shots would be brighter with the low-res mode enabled.

Last, just for fun, I made some screenshots of Super Metroid using the low-res option with the 240phoriz LUT, just like the Photoshop renders I made above, and here's how it looks:

Not bad! :D

One thing that still needs work is that the gaussian blur is only happening vertically, I think, but I'm not really sure why. I'm assuming I didn't put the horizontal pass into the framebuffer properly, so I'll keep fiddling with that. Also, certain emulation cores (such as snes9x-next) don't really play nicely with it, presumably due to horizontal resolution issues. Genesis Plus GX seems to work fine, at least:

Update (3/29/2013): I made a couple of small changes to the shader and a few different variations. I added in a new variable called 'brightness' (toward the end of the file) that you can raise/lower to increase/decrease the brightness of the image if it's too dark (within a range). Here's a pastebin of the updated default shader (shown with 240pvert LUT):

And here's one with scanlines added (sry, no screenshot; I'll try to add one soon):

And here's a super-mega version with Themaister's multipass NTSC shader+scanlines (another missing screenshot).

GPDP made some new LUTs, too, which is awesome. The first one mimics an aperture grill (click to download the LUT; shown here with scanlines added):

This one will look best at 9x scale instead of 10x.

The second LUT is actually pretty good at smaller scales, such as 4x, and takes the same idea as cgwg's CRT shader in that it tints alternating pixels green or magenta (click to download the LUT;

I also modified cgwg's CRT shader to use the phosphor LUTs instead of the built-in pink/green pixel tint (note: screen transformation doesn't work right in this version) . It looks like this (click to download; shown with 240phoriz LUT):

Just as a warning: there's no reason to use this one instead of the regular CRT shader at less-than-huge scales. It looks significantly worse than the normal version. TBH, that's true for all of the shaders in this post...

And here's one with aliaspider's GTU shader replacing the gaussian passes (click to download; shown with 480pvert LUT):

Update (5/9/2013): Here's how the updated Cg port looks. I now consider this the best version and recommend users upgrade to it if they've been using the older GLSL version:

These shots were all taken at 4x, which would never have been possible with the GLSL version (without it looking like total garbage). It also handles pseudo-hires transparency decently well (see: Kirby shot), though you'll notice there's quite a bit of color mangling still...

You can download this shader here.

Fix for TV Overscan in Ubuntu with Nvidia Drivers

2012-12-31T16:30:00.001-08:00

Ok, this problem has been a consistent thorn in my side for as long as I've been running Ubuntu on my TV (a number of years). On a lot of HDTVs, setting your computer to display 1080p or 720p or whatever will often cut off the edges of the screen. This cutoff is known as overscan and it used to be necessary because all sorts of garbage data would be displayed in the edges of broadcast signals and video games. Nowadays, that doesn't happen and we want to see every bit of the picture but many TVs still do it.

The easiest fix on TVs of any reasonable quality is to set the TV to "just scan" or "pixel perfect" mode (it goes by many different names depending on manufacturer). However, if your TV is cheap/crappy, you won't have such an option and the only way to deal with it is via software. This works just dandy in Windows, where the Nvidia driver has a handy little "overscan compensation" option where you can adjust a slider until your entire desktop is visible.

Sometimes, depending on driver revision and apparently some other unknown (to me) factors, a similar slider is available in the nvidia-settings applications in Ubuntu. This is undependable, though, and it will sometimes be grayed out or even disappear after you've used it in the past! :O

If you run into any of this, the way to fix it is to add a line to your /etc/X11/xorg.conf files that invokes the ViewPortIn/ViewPortOut options in the driver. So, open a terminal and type:

sudo nano /etc/X11/xorg.conf

You should see:

Section "Device" Identifier "Default Device" Option "NoLogo" "True"EndSection

Or something similar. If you don't see any of that (e.g., if your file is totally empty), then just add it in manually.

Next, add a new line under the "NoLogo" line that looks like this (all one line, btw):

Option "metamodes" "DFP-0: idealxresolution { ViewPortIn=idealxresolution,ViewPortOut=desiredxresolution+excessX+excessY }"

So, if, like me, you want it to run in 720p with 24 pixels of horizontal overscan compensation added to left/right sides and 14 pixels of vertical overscan compensation added to top/bottom, your line will look like this:

Option "metamodes" "DFP-1: 1280x720 { ViewPortIn=1280x720,ViewPortOut=1232x692+24+14 }"

Now, you'll notice that the buffers I've added to the end are exactly half of the total amount of resolution I'm chopping off. That's because the specified amount is added to both sides.

You'll also notice that my line uses DFP-1 instead of DFP-0. I'm not sure why that is, but that's what it identifies as in my nvidia-settings application, so be sure to check there first to find out what yours should be labeled as.

Log out and back in and it should use the new resolution. If not, try rebooting.

Fix for Win8 Unhandled Error -1 (SSF4)

2012-10-31T04:54:00.002-07:00

Ugh, this problem was infuriating. I got a cheap copy of Windows 8 through my job and decided to go ahead and install it, just to be up-to-date. Then, I went to play SSF4AE via Steam and instead of launching, I got an ugly little window that said "An unhandled error has occurred -1."

After digging around online, it appears that the fault lies in Windows 8's default implementation of Games For Windows Live. |:-[

To get around this problem, we need to uninstall the default GFWL and download the latest installer from Microsoft.

You DO NOT have to uninstall/reinstall Steam as is suggested elsewhere online. If you try that, be aware that it ~~will~~ may uninstall all of your games at the same time (thanks to MasterPhW for the correction). It's supposed to ask before doing so, but it didn't ask me, so YMMV.

Background Shader for RetroArch

2012-09-13T12:46:00.000-07:00

UPDATE (9/18/2012): It turns out the Themaister already wrote a waaay better version of this shader that can do some cool things like move the location of the game window and scale to arbitrary scale factors (i.e., not just even integers). I also made another old TV background:

If you'd like to try Themaister's version of the shader--which I've provided as-is, as well as combined with flat and curved CRT shaders--you can download it and the above TV background here:
http://www.mediafire.com/?av2y788pn3v1b3e

UPDATE (9/26/2012): Another one by request, using Super Metroid's Japanese artwork:

Download:

http://www.mediafire.com/?ah2a1hxptte886l

Original Post:

I've been working on a fun little pixel shader for use with RetroArch that functions similarly to the Cg border shader but using GLSL and the XML shader format. The way it works is that it combines the functionality of the existing integer scale shader with a lookup texture (LUT) that loads an external texture and then combines that image with the rendered game image. The LUT then has a transparent window in the middle where you can see the game peeking through.

In the simplest application, you can put whatever fancy stuff you want around the game window, like this awesome pixel-art border created by FirebrandX (NOTE: all of these look better in actual use; the way I took the screenshots caused the game's vertical resolution to get cut off by the border a bit):

By using RetroArch's awesome multipass shader support, you can also tack on some fun effects, like cgwg's CRT shader and some high-resolution artwork:

We can also do fun stuff like this TV border:

And we can use the transparency of the background image to overlay things across the game, like this Super Mario Bros 2 border, which has the characters overlapping a bit:

You can download these and others here:

http://www.mediafire.com/?1bss7814eupav1b

To use the shader, you'll need to uncheck the 'Lock Aspect Ratio' option in RetroArch, under 'Video' and put the desired background image in the same folder as the shader with filename 'background.png.' The backgrounds only work with specific monitor resolutions, so I've included 1080p versions of the ones pictured above, while FirebrandX was kind enough to make several iterations of his sweet pixel-art backgrounds that work at their specified resolutions. I've also included several background-compatible shaders, including the raw shader, ones with cgwg's CRT+NTSC-RGB (both flat and curved varieties) and some with cgwg's CRT+NTSC-RF (both flat and curved varieties).

In case you'd like to make your own, I've also included a simple template (in PSD format) for 1080p resolutions.

Ubuntu Quantal Beta - First Impressions on x120e

2012-09-08T07:02:00.001-07:00

I just updated to the latest beta release of Ubuntu, codenamed Quantal Quetzel (or, as I call it, Quantum Pretzel), on my Lenovo x120e netbook.

Installation went smoothly and my optional broadcom wireless chipset was detected and enabled automatically during installation. This is the first time that has loaded without any hassle on my part, and I'm very pleased with the result. Users with the default atheros chipset have been enjoying this ease of installation for several releases already.

Installation went smoothly, now that they've squashed a particularly nasty bug in the installer that would crash if you tried to manually modify the partition table...

Once I booted into the actual installed system, it defaulted to use the open source driver for my integrated Radeon Fusion chipset, which provides adequate acceleration for transparency and other desktop composition goodies. Speaking of, the default Unity interface seems to have been improved further beyond the already much-improved Precise release, with the icons in the dock being smaller and less cartoony on my machine, with transparent backgrounds rather than the garish multicolored backgrounds from before (YMMV).

Virtual desktop switching also seems much improved. I never used it before because it felt clunky and laggy, but now transitions are smooth and dragging windows among desktops is effortless and intuitive. However, sometimes the windowing system gets confused and tries to maximize things inappropriately, leaving a transparent orange overlay on the screen--to show where it's trying to maximize--until you click on the window decoration and let it do its thing, then resize.

Suspend works well on this machine, faster than before and with quicker wakeups, and the wireless reconnects faster after suspend, as well. There doesn't seem to be a hibernate option anymore, so I couldn't test that.

One problem I ran into: I previously used my /etc/fstab to mount a shared folder from my network at startup via smbfs, but that package has been removed upstream, so now I use cifs as the filesystem and that seems to work just fine.

If you have any questions or anything you'd like me to test, feel free to hit me up in the comments.

Netflix Channel Installation Error on Softmodded Wii

2012-08-04T09:00:00.000-07:00

The Netflix channel on my Wii finally stopped letting me skip the nag screen and demanded that I update. So, I deleted the old Netflix channel from Wii's the built-in channel management menu and attempted to download the new version from the Shop Channel.

I was greeted with an error 204036 and given the option to try again, which gave the same results each time.

So, I tried to just download a copy of the channel wad (Netflix Channel v1024 USA) to install through a wad manager. This didn't work, either, as it kept giving me error -1022 (Content did not match hash in TMD).

I tried using a bunch of different IOSes to install, but nothing worked, though I ended up finding a solution:

Step 1. Go download a copy of the old Netflix Channel wad (NetflixChannel-v1-USA) and reinstall it via a wad manager.

Step 2. Once it's installed successfully, use the wad manager to uninstall it. (I got an error during uninstallation, but it finished okay anyway, FYI)

Step 3. Install the new Netflix Channel wad and it should complete successfully this time.

Apparently, the Wii's normal channel removal tool leaves behind some garbage that stops the new channel from installing properly. By reinstalling the old version and then uninstalling it through the wad manager, we can get rid of that garbage and end up with a clean slate.

Update: If this doesn't work for you right away, you may have to install IOS 56 and/or the Shop Channel v20 first. In my case, I'm still on a much older shop channel, but someone in the comments mentioned needing to do this before it would work.

Update2: It's asking for another update... If you follow the steps above, then uninstall Netflix via a wad manager, you should be able to download the updated Netflix channel from the Shop Channel.

Customizing cgwg's CRT Pixel Shader

2012-07-28T19:49:00.000-07:00

This document identifies some of the user-configurable options available in cgwg's GLSL CRT shader and provides some screenshots to explain their effects.

For individuals interested in recapturing the look of retro gaming consoles played on a CRT television like the ones we grew up with, cgwg's CRT shader provides the closest approximation available for modern LCD displays. The pixel shader is purely cosmetic--nothing could impart the technical advantages of a CRT, such as negligible input lag and insanely high contrast, to an LCD--but it can go a long way to displaying old games as we remember them. Since memory and nostalgia are important to the way we perceive these games, each person will have different feelings about what looks "right" to them.

We will be using the latest (as of the time of this writing, 7/28/12) and most complete version of the shader, known as CRT-Geom. This shader allows for simulated screen curvature, rounded corners, simulation of a back-tilted screen (for arcade emulation) and many other goodies. All images are captured at 4x scale, click the thumbnails to embiggen.

This is what the shader looks like with all default parameters, also known as the 'curved' variant (cgwg chose sane values for all of the variables by default):

The user-configurable parameters are primarily located in two places in the shader, starting at line 87 for the first section and line 135 for the second section. You should be able to open and edit the shader in any text editor, but I recommend Notepad++.

The first parameters, 'gamma of simulated CRT' and 'gamma of display monitor' allow the shader to determine how much gamma correction to apply to the image. CRT displays generally had higher gamma ratings than most LCD displays (2.4 for a typical CRT vs 2.2 for a typical LCD), so the shader adds 0.2 to the gamma to compensate. If you calibrate your LCD to a higher or lower gamma setting, you may wish to change the 'gamma of display monitor' to reflect your individual settings. You can also raise or lower the simulated gamma to make a darker, more saturated look:

or a lighter, desaturated look:

Next, we have 'overscan.' Each CRT showed a slightly different amount of the picture, and the cut-off portion was referred to as overscan. You can modify the amount of over- or underscan by changing this variable. Setting it to (0.00,0.00) will assume you want the picture aligned exactly with the borders of the window. Setting it to a value greater than 1.0 (for example, 1.10,1.10) will cut off a large portion of the screen (approximately 10% in this example):

while setting it to a value less than 1.0 will surround the screen with black bars (i.e., underscan):

Increasing the overscan slightly, say, to 1.02,1.02, can cut off unsightly garbage lines at the top of the screen, which is common on NES games.

Next, we have 'aspect ratio,' which controls how much our screen curvature settings will affect the top/bottom and sides of the image. The default setting of 1.0, 0.75 means the curvature will be more pronounced on the top/bottom than on the sides, to compensate for the standard 4:3 aspect ratio. Setting it to 1.0, 1.0 will make the settings affect both sides of the screen equally, which isn't quite right in that the top/bottom actually appears more curved than the sides:

If for some reason you want only the sides straight, you can set it to 1.0, 0.5:

or 0.5, 1.0 to make only the top/bottom straight:

Next up, we have 'simulated distance from viewer to monitor.' Similar to the 'aspect ratio' setting, this exaggerates the effect of the 'tilt angle' setting that we'll be covering in just a moment. The default value of 2.0 is reasonable. Increasing the value reduces the effect of the tilt angle:

while lower values magnify it:

Next, we have 'radius of curvature,' which determines how curved our simulated TV tube will be. Setting the value to 2.0 reduces the curvature to something more like what I remember.

'Tilt angle' pincushions one side of the screen. To tilt the screen back, use a negative value for the second number. The default for the 'arcade tilt' variant, (0.0,-0.15), is a sane value:

while increasing the second value tilts it back further, which can be disorienting:

After that, we come to 'cornersize,' which determines the radius of the corner arc. I think a setting of 0.03, as used in the default image, looks appropriate. Increasing the value to 0.10 makes for some silly, super-round corners:

while a value of 0.001 makes for super-pointy corners:

For the last parameter in this section, we have 'cornersmooth,' which determines how sharp (sharp as in sharp/blur, not as in pointy) the corners look. The default value is 1000.0, which looks fine, but I noticed that if you set the value insanely low (i.e., 80), you get a little vignetting around the edges, which reminds me of my crummy old TVs:

On to the next set of parameters.

The second set of options are either enabled or disabled by using 'comments,' which in this case are represented as a double-slash, like this //.

The first option is 'linear processing,' which enables interpolation of linear gamma:

The effect is subtle, but disabling it via commenting it out (//#define LINEAR_PROCESSING) can improve the framerate with some video cards.

Next, we have 'Enable screen curvature.' Pretty self-explanatory, but if you comment this line out, you'll get straight top/bottom/sides of the screen, but with the corner arcs intact (barely visible in this shot):

By commenting this out and setting 'cornersize' to 0.0, you get an idealized flat CRT tube, which is represented by the 'CRT-flat' shader variant:

The next two options work together (that is, if you uncomment one, you should comment the other). By default, the shader uses 3x oversampling of the beam profile, which makes brighter pixels bleed further into the surrounding scanlines. Here it is with the default oversampling, scaled up 400% (look closely; it's most obvious on the bright red of Mario's sleeve):

and here it is with the gaussian beam profile:

The gaussian beam profile may have better performance on some video cards.

Those are all of the options available for the standard CRT shader, but there are a few more things we can add in. The first of which is support for interlaced video. Some games did a sort of fake doubling of their vertical resolution by showing different lines of a progressive signal on alternating frames in a process known as interlacing. If handled incorrectly, you will see a ton of combing artifacts (weird horizontal lines on moving objects), as well as distorted scanlines (first image taken using this older, non-interlace-supported version):

These pictures unfortunately cannot show the jutter in the lower image that occurs from showing different lines on each alternating frame.

Next, we have support for pseudo-hires transparency--whereby games created a fake transparency effect by doubling the horizontal resolution to 512 and then covering the transparent area with thin vertical lines, which were then squished together and blurred when the CRT displayed the image--in the games that utilize it, including Jurassic Park and Kirby's Dreamland 3:

This blurring is accomplished by adding another pass to the shader that does nothing but squish the horizontal resolution from 512 to 256. Note: this variant is multipass and therefore incompatible with the official bsnes/higan GUI. Retroarch can use it just fine with bsnes-derived emulation cores, but it is incompatible with FBO/2-pass shader stacking.

Finally, to simulate the natural phosphor glow of a CRT display, cgwg created a multipass version of his CRT shader that includes a "halation" pass, which provides a soft blur that is most noticeable against a black background, such as the Nintendo logo screen in Super Mario World (it also seems to be doing some aspect ratio correction, though I'm unsure if that's intentional):

Here's a shot of Super Metroid's title screen without and with halation, respectively:

Note: Like the TV blur variant, this halation variant is multipass and thus incompatible with the official bsnes/higan GUI. It works fine with Retroarch but is incompatible with the FBO/2-pass feature.

Now, beyond the CRT display, our childhood gaming experiences were also colored by limitations of the NTSC signal standard and the lossy, analog hookups we used to connect our consoles. To capture these effects, we turn to blargg's NTSC filter, which runs on the CPU rather than the GPU and can thus be combined with our CRT shader.

The NTSC filter is available in these CPU filter packs (compatible with RetroArch but not bsnes/higan):
Win32
Win64
Linux 32-bit
Linux 64-bit
Mac OS X

The least intrusive variant of the filter is the RGB preset, which simulates a high-quality RGB connection. This variant provides NTSC color gamut correction but leaves the signal otherwise untouched:

Next, we have the S-video variant, which has color correction and some fringing, but is still relatively high-quality. This is the variant I use most of the time:

The third variant, composite, brings in a lot of signal noise and color bleed, just as you would get through a composite, RCA-cable connection:

The worst-quality variant is RF, which looks just as messy as the composite signal, but with added jutter every other frame, just like when using the RF adapter bundled with classic consoles:

One thing to be aware of, though, when using any variant of the NTSC filter is that it also does some gamma correction, which can be overwhelming to some people when combined with the CRT shader. To mitigate this effect, you can modify the CRT shader's 'gamma of simulated CRT' to match the 'gamma of display monitor' value to disable the shader's own gamma correction (shown here with the S-video variant):

My personal preferences, depending on the game/system: 'radius of curvature' of 2.0, cornersize of 0.03, cornersmooth of 80.0 and NTSC-Svideo. Sometimes I'll use the flat variant (especially on displays that have problems with moire patterns caused by curvature+scanlines), and I often use the halation variant when I'm on a machine with sufficient resources. I always use interlacing support, which has been incorporated into all of the latest versions, and TV blur when possible (i.e., when using Retroarch rather than the official bsnes/higan GUI).

SFxT: How to Duplicate A Character - Proof of Concept

2012-07-15T12:00:00.003-07:00

There are a lot of reasons why you might want to duplicate a character in SFxT, the most obvious (to me) being that you would like to play a team that consists of 2 copies of a single character that you are most skilled with. To accomplish this task, we need to edit a few files and make copies and rename a bunch of others, so lets get some tools together first.

As usual, you'll need piecemontee's Asset Explorer (aka SF4Viewer) and a text editor (I recommend Notepad++; regular Notepad WILL NOT WORK). You'll also probably want a bulk renaming utility, such as the aptly named Bulk Rename Utility. You should also take this opportunity to make backups of any files we plan to edit, as mistakes can render your game unplayable. Repeat: MAKE BACKUPS BEFORE TRYING ANY OF THIS.

NOTE: this is currently a proof of concept. ~~The duplicate character will only work in training mode unless we duplicate more files, which I'll add to the post if/when I track them all down. Fights with intro animations will crash~~. See the bottom of the post for Robhal's update! Also, duplicating characters will corrupt your save data, so be sure to back that up first.

STEP 1 - Creating our duplicate

The first step to duplicating a character is to make a copy of the target's character folder. For this tutorial, I'll be using Ken as an example. So, navigate to [install dir]\resource\CMN\battle\chara, right-click on the desired character folder, select copy, then right-click elsewhere in the directory and choose 'paste.' You should end up with a folder named '*** - copy.'

Next, rename that folder to a non-conflicting 3-letter prefix that will represent your new character duplicate. In my case, I'm going to use 'KE2.' Note: you must use exactly 3 letters for your prefix or the game will fail to even load.

Once that's done, navigate into your new folder and open your bulk renaming utility. Select all of your files in the folder and rename all of them to match your 3-letter prefix (that is, all of the KEN* files should be renamed to KE2*), then do the same for all of the files in the 'sound' folder (these steps will be different depending on which renaming utility you use, so I'm not going to go over it here).

It should end up looking like this:

Now, we'll need to make duplicate call sounds (*_CAL_*) for each character we expect to partner our duplicate with. For the sake of simplicity, I'm only going to partner KE2 with regular ol' KEN, but if you wanted to be able to partner him/her with any other character, you would need to make calls in each potential partner's 'sound' directory. So, navigate to his folder, go into 'sound' and then make a copy of his *_CAL_KEN_E and ...J files. Rename them to match your duplicate prefex, like this:

Note: Failure to create the proper calls in each partner's sound folder will result in a game crash. (It's interesting that Capcom has these duplicate calls in the first place, suggesting that single-character teams were a possibility at some point).

Ok, with that done, we're ready to move on to step 2.

STEP 2 - Telling the game about our duplicate

SFxT keeps track of the available characters and what to think about them in the const.lua file, located in the [install dir]\resource\CMN\boot\game directory. Make a copy of the file and move it to a directory where you have write permissions, such as your desktop.

Then, open the file in your text editor and you should see a section labeled "charas" at the top of the file. Navigate down to the subsection for your duplicated character (in my case, Ken) and copy everything from his/her subsection, starting with the open-curly-braces (this thing: { ) and ending with close-curly-braces-followed-by-a-comma (this part: }, ).

Now, paste that in (right after the original is fine) and change the first line, labeled "['code']" to your duplicate's code (in my case, KE2). You can change the name here, too, but I don't think it really matters. While we're here, you can also modify anything else you want, such as vitality, "official partner," default voice, etc.

Save the file and replace the original (make a backup first, if you haven't already). Now we're ready for step 3.

STEP 3 - Creating a character select slot

SFxT determines which character slots are available through the selector_layout.emz file, located in the [install dir]\resource\CMN\ui\pre_battle directory. However, if you try to open the file directly, you'll see just a bunch of gibberish because the file is compressed. To decompress it, just open piecemontee's Asset Explorer and drag the file into the left-hand window pane. It will automatically create a backup of the original file (called selector_layout.emz.compressed) in the same directory, which is convenient. Once that is done, open the now-decompressed file in your text editor and it should look something like this:

This grid represents the character select icon grid, and we can use this file to move characters around (in case you want your favorite character to be closer to the top, for instance) or create new slots altogether by overwriting blanks (#BL). You can also remove characters by replacing them with blanks.

As you can see in the above pic, I have already replaced one of the blanks with my duplicated character abbreviation, to the left of the Random Select box. Note: Make sure you place it somewhere adjacent to an existing character or else you won't be able to move the cursor to it (i.e., the far corners are not good spots).

Once you're finished making changes, save the file and replace the original, making sure to back it up first, if you haven't already.

Now we're ready to launch our game. If all goes well, you should see a new character select slot on the character select screen (to the left of the Random box, just as we stipulated in our text file), which is treated as an entirely new character as far as double-picking is concerned:

Some Current Unknowns

First, I don't know how the game determines which character portrait goes into the character select screen, which is why our dupe has a blank box. Second, I don't know why the duped character is positioned strangely when you select him/her (my KE2 always appears hanging off the screen if I select him first for some reason).

If you figure out anything cool, please leave a comment.

Have fun, share your work and ALWAYS MAKE BACKUPS.

UPDATE - Robhal figured out the missing files to make the duplicated characters usable in vs. and story modes:

And now these my instructions below are continuation from hunterk's method above, to be able to play the duplicated character in Arcade and Versus mode.
1. Go to folder "\Street Fighter X Tekken\stream\CMN\battle\chara", right-click on the desired character folder, select copy, then right-click elsewhere in the directory and choose 'paste.' You should end up with a folder named '*** - copy.' Next, rename that folder to a non-conflicting 3-letter prefix that will represent your new character duplicate. In this case, 'KE2'. Then navigate into the new folder and rename all the files (just two files) to match your 3-letter prefix (that is, all of the KEN* files should be renamed to KE2*).

2. Go to folder "\Street Fighter X Tekken\resource\CMN\ui\battle\comment\cmt", copy the desired character file (in here, KEN.cmt) and rename it to 'KE2.cmt'. OPTIONAL: You may also move the file 'KE2.cmt' to folder "\Street Fighter X Tekken\patch\CMN\ui\battle\comment\cmt" for easier maintenance.

3. Go to folder "\Street Fighter X Tekken\resource\ENG\ui\battle\comment", copy the desired character file (in here, KEN.m4s) and rename it to 'KE2.m4s'. OPTIONAL: You may also move the file 'KE2.m4s' to folder "\Street Fighter X Tekken\patch\ENG\ui\battle\comment" for easier maintenance.

4.Go to folder "\Street Fighter X Tekken\resource\ENG\ui\battle\subtitle", copy the desired character file (in here, KEN.m4s) and rename it to 'KE2.m4s'. OPTIONAL: You may also move the file 'KE2.m4s' to folder "\Street Fighter X Tekken\patch\ENG\ui\battle\subtitle" for easier maintenance.

SOME ISSUE TO NOTICED:
1. In any battle, when the duplicated character use the Cross Rush (ABC Launcher), he/she still has that zoom-in camera animation.
2. In battle with intro, the duplicated character has a weird subtitle. And in the winning screen, the duplicated character has a blank comment.
3. You can't view the quickcombo preview, the trial, and the command list of the duplicated character, otherwise it will fall back to title screen.
4. When you play the Arcade mode, make sure you pick the duplicated character as 2nd character (tag partner). The reason is if you pick the duplicated character as 1st character and when you defeat the final boss (either Akuma or Ogre), after the credit screen, it will fall back to title screen. --> (I haven't found the solution to this issue yet)

Diablo 3 Mac Installation and Unsupported Video Fixes

2012-06-02T08:08:00.000-07:00

I got my hands on an old iMac the other day and decided to install some games on it. So, I downloaded the Diablo 3 installer and tried to run it, but it just bounced in the dock for a while and then disappeared :(

The first thing I tried was to right-click on the installer and select 'Show Package Contents.' Then, under 'Contents' > 'MacOS,' you'll find the Diablo III Setup executable. Double-click it and you should see a Terminal window pop up and quickly disappear. You may not be able to see what has caused the problem, but it should have reported a permissions error ('Permission denied').

To fix this, open a Terminal window and navigate to the directory where you put your installer (for me it was Downloads; the easy way to get to it is to type 'cd ' [that's the letter c, the letter d and a space] and then drop the desired folder onto the Terminal window and hit 'enter') and type (include the quotes here):

sudo chmod -R 777 "Diablo III Setup.app"

It will ask for your password and, once authenticated, it should fix your permissions issue.

At this point, you can try double-clicking on the installer and you should be in business.

If, however, it tells you that your video card is not supported (like me), you will have to do a little more work. No biggie.

Open a terminal and type:

nano ~/Library/"Application Support"/Blizzard/"Diablo III"/D3Prefs.txt

You should see a bunch of options, followed by values, like this:

Scroll down until you see the option 'DisableTrilinearFiltering' and change its value from '0' to '1,' then do the same thing for the option 'HardwareClass.'

It may not be required for everyone, but I also had to add an option, 'DisplayModeWindowMode,' with a value of "1."

Now, save and close by hitting Ctrl+x and then 'enter.'

You should be good to go :)

And, I assure you, performance *will not* be a problem (this is meant as a joke; of course performance will be a problem; it hardly runs, ffs).

Beginner's Guide to Custom Colors in SFxT

2012-05-11T09:01:00.002-07:00

Update: The steps from this tutorial have been automated. You can now do all of it easily from sloth86's EMMEdit tool.

Street Fighter x Tekken handles colors in a completely different way from Street Fighter 4 and its derivatives as a result of the color customization feature. Instead of just pulling colors and textures directly from the texture image, the textures look like this:

and the game calculates the appropriate color based on a series of numbers, which represent a color mix from the texture image's color channels. These numbers are stored in the *.obj.emm files--specifically the 'MatCol' attributes--alongside the various other object materials and material attributes.

There are two main ways to edit *.obj.emm files, manually via hex or using NanjouJ's MatEdit tool, which is a little more user-friendly than fiddling with hex codes. In this tutorial, we'll be using MatEdit to copy colors from another color file, rather than calculating the color from scratch. If you would like to calculate an entirely new color from scratch, this post from yajirobe does a good job of explaining it.

So, first thing, we need to make backups of any of the files we plan to mess with. Once you've done that, go download MatEdit from the AE wiki's 'tools' page and identify which files you want to work with. I'm going to be copying a color from one of Ryu's *.obj.emm files into one of Poison's.

Now, create a new folder (on your desktop or wherever) and copy matedit.exe and both Ryu and Poison's *.obj.emm files into it. Then, hold ctrl+shift on your keyboard and right-click somewhere inside that folder, and choose 'Open command window here':

This will open a command line window, but don't freak out. I'm going to tell you exactly what to type in.

First thing, we want to export the materials from both of our files, using the syntax "matedit.exe export [target obj.emm file] [newfile.txt]." So, in my case, I'm going to type (replace PSN/RYU and poison/ryu as appropriate for your files):

matedit.exe export PSN_01_01.obj.emm poison.txt

and

matedit.exe export RYU_01_01.obj.emm ryu.txt

If done correctly, you should have two new files in your directory, in my case, poison.txt and ryu.txt. At this point, we're done with the command line for now, but don't close it yet because we're going to need it again later.

For now, open both files in the text editor of your choice. Notepad works, but I prefer Notepad++ (it's free and awesome; go get it).

Open both of the txt files in your text editor. You'll see a series of sections which correspond to the various objects that make up the character's model. In each section, there are a bunch of variables and values that tell the game how to render each object. The ones we're worried about today are the MatCol variables:

You'll notice that I highlighted just the *R, *G and *B MatCols, which correspond to the red, green and blue color channels, respectively, and not the *A MatCol, which corresponds to the Alpha channel. You shouldn't mess with the alpha value if you're just trying to change colors. ;)

So, lets say we want to take the color of Ryu's pants--i.e., white--and copy it over to Poison's hair. To do this, we would hop over to our ryu.txt file and search for 'pants.' Then, scroll down through his 'pants' section until we find the MatCol subsection.

In this case, I only have a single color, MatCol0 to choose from, but some models will have multiple color groups, such as MatCol1 and MatCol2. These MatCols represent the color groups that can be customized in-game, so make sure you're choosing the correct one.

Copy those values and then switch over the poison.txt file and search for 'hair.' Scroll down to the MatCol section and replace the values there with your new, copied values:

Great, we're almost done.

The last step is to import the modified text files back into the target *.obj.emm file. So, back to your command line window (if you didn't listen earlier and closed it, just open a new one) and type:

matedit.exe import poison.txt PSN_01_01.obj.emm

Now you're ready to test it out. Copy the PSN_01_01.obj.emm file into your [install directory]\resource\CMN\battle\chara\PSN folder, overwriting the one that was there (you made a backup, right??) and go check it out.

If you had calculated a new color from scratch using yajirobe's instructions instead of copying the color from some other costume, you would go through the exact same steps, only using your calculated color numbers instead of the ones from Ryu's pants.

That's it. Have fun, share your work and always make backups.

Beginner's Guide to Custom Challenges using Waterine's ClgEditor

2012-03-12T18:49:00.000-07:00

This tutorial will cover the very basics of using Waterine's ClgEditor tool to create your own combo challenges for SSF4AE. For this, we will need the ClgEditor and Dantarion et al's Ono! Editor.

When you first run the ClgEditor, click the button to 'Open...' and browse to your installation directory (usually C:\Program Files (x86)\Steam\steamapps\common\super street fighter iv - arcade edition), then go to ...\resource\battle\chara and go into the folder for the character whose Trial Mode you wish to modify. It should filter the folder contents such that the only file displayed is our desired CLG file, in my case, CMY.clg.

Once the file is loaded, you can see the list of challenge levels on the left. At the top of the window you should see a pulldown menu labeled 'Ultra Selection,' which lets you select which Ultra combo should be loaded for the challenge, and another pulldown labeled 'Target State,' which determines how the dummy (Dan) should act (for use with situational combos, like ones that must start with a counterhit or only work on jumping opponents).

The area underneath those pulldowns is where most of the fun happens.

In the 'Scripts' section, the first button from the left (looks like a sun) creates a new command, either an 'attack' or a 'script,' which you can choose between using the 'Criteria type' pulldown menu to the right. Attacks are just your normal actions while scripts are movement actions, like dashes and FADCs.

The 'Criteria indices' field tells the game which moves it should accept as a successful command. If any strength of a move will do, as is the case with many of the early challenges, you must include each index that fulfills the criteria. For a regular special move (light, medium, hard and EX), you would need entries for all four strengths.

Back in the scripts window, each command represents one discreet portion of a challenge, and you can show up to 8 on the screen. You can go beyond 8 in the list, but unfortunately the display doesn't scroll in-game, so the player won't be able to see the rest.

To the right, you can choose what on-screen instructions and input help to display from the respective pulldown menus.

So, lets say I want to change Cammy's first challenge from a simple Spiral Arrow to a Cannon Spike > FADC > EX Cannon Spike.

Step 1. Select the first trial from the levels list and hit the 'X' button under Scripts to delete the existing command. Then, click the sun button to create a new command. Our first command--Cannon Spike--is an attack, so choose that from the Criteria type pulldown.

Step 2. Next, we need to fill in the Criteria indices field with the indices for the move (I cheated and stole them from Challenge #3), in this case, 100, 101, 102, 103, 104, 105.

Step 3. Under 'On-screen command text's last pulldown menu, we want to select Cannon Spike, and under 'Help menu command text's last pulldown menu, we want to select Cannon Spike Input.

Great! There's our first command. Now, we need to make another.

Step 4. Click on the sun button again, but this time we're going to use a movement script, so select 'Script' from the Criteria type pulldown.

As in step 2, fill in the Criteria indices field with the appropriate inputs, in this case 325 (I stole that from a later challenge, as well; are you seeing a pattern here?).

Likewise, we'll fill in the On-screen command text and Help menu command text, which are a little weird for FADCs: in the first pulldown under On-screen commant text, choose 'EX,' and under the third pulldown, choose 'FocusCancel.' Then, under Help menu's first pulldown, choose 'EX' again, and under the third, choose 'MP+MK.'

Step 5. Alright, moving right along, click the sun button one more time and choose the 'Attack' criteria. Up until now, all of the moves we've wanted to use could be easily pilfered from other challenges. However, no challenge requires an EX Cannon Spike specifically, so we'll have to figure this one out on our own. To do it, open up the Ono! Editor and open Cammy's BCM file. You should see a window that looks something like this:

Click on the bottom button, labeled "Hitbox Table." It should open a new window that looks something like this:

There's a lot of really great information available in this window, but we really only need the numbers on the far left in front of the move names. So, scroll down until you find your desired move, in my case EX Cannon Spike, which is listed under #106 and #107. If the criteria type is an attack, you use the hitbox data number, if it's a script, you should use the script number (you can expand the header info in Ono! to see it).

Now, enter those numbers into the Criteria indices field, separated by commas and spaces as necessary.

Fill in the appropriate on-screen command and help menu text, and you should be all set. Click the save button and lets go check it out by copying it into our ...\resource\battle\chara\CMY folder (don't forget to make a backup!!).

Now, as a note, you can make your combos against any version of the characters' movesets you like (Super is the default, of course, but you can use movesets from AE, 2012 or even custom movesets created in Ono!), you just have to copy the appropriate BAC/BCM files into the ...\resource\battle\chara\*** folder to overwrite the ones that are already there.

If you create something cool, be sure to share your work with the community, and always always always make backups!

xBR vs HQx Interpolation Filter Comparison

2012-03-03T11:22:00.000-08:00

This post compares the popular HQx interpolation algorithm with the newer xBR, which has been covered in some of my other posts. If you just want to download the filters, you can get them from the link at the bottom of the post.

Since Maxim Stepin created the HQx interpolation algorithm more than a decade ago, it has been the favored real-time interpolation filter for the emulation scene. The way it works is it looks at each pixel and then compares its color to that of the 8 surrounding adjacent pixels. If it finds a match, the filter then compares the resulting pattern with a predefined lookup table to guess what the original pattern was trying to represent.

For example, if we take a pattern like this:

and scale it up via nearest neighbor--that is, a straight upscale with no interpolation--you end up with this checkerboard pattern:

But, if you use HQ2x, you end up with this:

The algorithm guesses that the original pattern was trying to represent a diagonal line rather than a checkerboard pattern, so it fills in the gaps to compensate.

Recently, a Brazilian programmer by the name of Hyllian (aka Jararaca) developed a new algorithm that actually improves on HQx, known as xBR (stands for "a filter that scales By Rules").

xBR works much the same way as HQx insofar as it is based on pattern recognition, and it would upscale the above pattern with the same result. However, it goes further than HQx by using a 2-stage set of interpolation rules, which better handle more complex patterns such as antialiased lines and curves.

You can read more about Hyllian's algorithm here.

Lets take a look at how they compare on a real-world example (HQ2x on the left, 2xBR on the right; click to embiggen):

As you can see, 2xBR does a much better job on smoothing curves without getting chunky (see Yoshi's nose and the dragon coin). It also does a better job on the 'eyes' of the block, which is represented as a diagonal line with 2xBR compared with the series-of-squares look with HQ2x.

Here's another comparison, using Earthworm Jim's title screen:

And here's a third comparison, using the title screen to Earthworm Jim 2:

HQ2x actually does a slightly better job at getting a smooth gradient around the highlight in Jim's eye, but the rest of the image is a mess. xBR has smoother, straighter lines at every color transition.

Additionally, the xBR algorithm scales to higher scale factors much more easily than the HQx algorithm, making 3-, 4-, 5- and higher versions faster and more effective.

At very high scale factors (5 and higher), the xBR algorithm can obliterate some small details, such as pupils in eyes, dots, and so on, so Hyllian introduced some additional calculation to compensate (5xBR-v3.5a on the left [uncompensated] vs 5xBR-v3.5b on the right [compensated]):

Of course, this compensation comes with its own drawbacks and false-positives, so which version works better varies on a game-by-game basis.

UPDATE: Hyllian has made a third variant that is even more cautious. Here's an animated GIF comparing the way each variant handles text:

Another interesting aspect of this algorithm is that it works very effectively on images already upscaled with xBR, so you can easily get absurdly large images (scaled 1x, 3x, 9x and 27x) with just a few iterations:

This puts it in direct and favorable competition with this vectorization method that recently made the rounds. xBR manages to maintain detail a bit better than the vectorizer, and it can actually operate in real-time, unlike the vectorizer.

You can download these shaders from my Mediafire repo (most are available in either XML/GLSL or Cg format, both of which are compatible with SSNES). UPDATE: KrossX ported 2xBR-v3.5a to ePSXe format and SimoneT ported 5xBR-v3.5a.

UPDATE: New Cg version of 5x variant. Runs approx. 25% faster. :)
UPDATE: new XML versions of 5xBR-v3.7. This package includes 3 variants (a, b and c), as well as the A-variant+scanlines.

UPDATE: Hyllian has been working on a new version that analyzes an image frame by frame and dynamically decides whether to apply xBR smoothing or Reverse-Anti-aliasing to produce the best picture. It handles text better than any filter/shader I've encountered, and it also excels at digitized, prerendered images and backgrounds. Here's a shot of it with Final Fantasy VI on GBA:

You can download this shader here.

UPDATE (4/19/2013): Another great update from Hyllian, this time adding 3 levels of analysis. This version runs a bit slower in my experience (unsurprisingly), but it now handles jagged edges that earlier versions simply couldn't detect, due to their 2-level analysis pattern. Compare this shot with the ones at the top of the post:

Notice that inclined bit of ground under the dragon/yoshi coin. This new version will also really help with Mega Man X games, which tended to have a lot of these sorts of gently sloping planes. You can download a Cg shader of this new version here, or a 3x scale Kega Fusion plugin here.

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.

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

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

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

Here are a couple of pics:

Cg Pixel Shaders for SSNES

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

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

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

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

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

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

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

Update (11/08/2012)

CRT-ReverseAA

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

As you can see, Clay Fighter looks really great with this shader. Too bad the game is godawful.

bsnes-gamma-ramp

As with pretty much everything else, bsnes has taken some sophisticated steps to achieve an authentic gamma ramp that reflects the actual appearance of games. Themaister was kind enough to reproduce the relevant code in Cg form. This is how it looks:

He also wrote a cgp file (just a simple file that tells RetroArch how to deal with multiple Cg shaders) that will enable pixel blending used in pseudo-hires transparency, which bsnes-derived emulation cores typically render as a series of vertical stripes instead of the intended translucent color. You can download the bsnes-gamma-ramp+hires blending bundle here.

LCD3x

A simple, fast scanline shader from Gigaherz, LCD3x is intended to evoke the look of handheld console LCD displays:

It's also a very easy shader to customize, if you want darker scanlines or to brighten the overall image. These variables are located on lines 12 and 13 of the shader, respectively.

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