Some Shaders I've Been Working On

“Whatever you now find weird, ugly, uncomfortable and nasty about a new medium will surely become its signature. CD distortion, the jitteriness of digital video, the crap sound of 8-bit - all of these will be cherished and emulated as soon as they can be avoided. It’s the sound of failure: so much modern art is the sound of things going out of control, of a medium pushing to its limits and breaking apart. ... The excitement of grainy film, of bleached-out black and white, is the excitement of witnessing events too momentous for the medium assigned to record them.” -Brian Eno 

I've been working on some shaders lately. 

The first one I want to talk about was inspired by some posts on the RetroArch/libretro subreddit, where a guy was using overlays (I think? might have just been photoshops) to make some really dark images of Game Boy Color games that mimicked the experience of using their technically awful front-lit LCD screens.

I never owned a GBC, and only played on a GBA very briefly in its day, but the enthusiastic response to those shots was really something, and it highlighted a significant unmet need that I had never really considered before. So, I borrowed a friend's GBA 001 and set to work on it, and here's what I came up with (as always, click to embiggen):

Rather than reinvent several wheels, I'm leaning on fishku's "authentic-gbc" LCD shader, which includes the characteristic little dog-ear on each subpixel, as well as Matt Akins lovely "pixel transparency" shader, which makes the white pixels appear transparent and adds a little drop shadow to them.

My addition darkens the image (adjustable how dark you want the ambient light), desaturates it, and then adds a point light source, the focus of which you can adjust (diffuse, like an overhead light, or more focused like a lamp or even a "worm" light attachment) and move around (by default, it's in the upper-right corner, like an overhead light). Direct light washes out whatever is under it, but indirect light fades off quickly, and some of the colors get inverted in the semi-lit area.

I also added in a "shmutz" effect using a dirty glass texture, which only really shows up when it's directly lit, along with a slight green tint that those old LCDs had under direct illumination.

There's also a "Nighttime Car Mode," which makes a bright light sweep across the screen every few seconds to simulate a car passing under streetlights in the night, which is a situation people seem to have a perverse nostalgia for.

While I was working on my shader, Matt Akins was exploring another idea that had been teased by that same redditor, of showing a rainbow pattern at certain angles due to a quirk of the GBC LCD's internal structure. He added this functionality to his pixel transparency shader, and he also submitted a patch to RetroArch to enable gyro and accelerometer control hooks to the shader backend. I was planning to work on this, too, but I'm thankful that Mr. Akins got to it first because he did a much better job than I would have.

With that in place, I added an option to control the light source using gyro control, which makes for a very uncanny gaming experience, tilting a controller to shine a virtual light source on a virtual crappy screen, but then seeing hints of rainbowing as you tilt it. Fun stuff.

I also made a modification of the 'gbc' console-border preset, which looks pretty nice, but the light source only affects the screen and would have required a lot of invasive changes to work on the border, too, so I didn't think it was worth the trouble. Ultimately, it's not my favorite, but it still works well for people who really want a border.

The other shader I've been working on is a CRT shader. Yes, another one, because there aren't enough already. This one focuses on monochrome displays, which are usually just an afterthought in CRT shaders, and monochrome modes don't usually exhibit any special characteristics vs the color-full settings. This is unfortunate, I think, because monochrome CRTs are cool devices that ruled the land for decades, even after color TVs were commonplace.

First off, monochrome CRTs don't have subpixels or masks. The entire screen surface is coated with a layer of powdered phosphor material that glows when the electron gun scans over it. Having this direct view of the beam makes the dynamic width very visible, and the beam itself has a bit of ... life to it.

I tried to capture that, and, as a result, static screenshots aren't going to look very good or capture the "magic," so I recommend trying the presets live / in person, if you have the inclination. Nevertheless, here's what it looks like:

That's the 'black and white tv' preset, which is intentionally pretty blurry, horizontally. Monochrome computer monitors could be quite sharp, though, and there's an "apple-monitor-ii" preset that handles that better:

In addition to the beam perturbations, this preset also has the scanline brightness cranked up really high, which brings in some general glow visible around the numbers, and it also makes some nice trails anywhere there's movement (courtesy of the 'glow-trails' shaders I made several years ago): 

Both of these presets include my analog service menu shader, which lets you adjust lots of physical CRT parameters, like h- and v-size, pincushioning, etc., as well as a version of crt-royale's geometry control that I isolated just for this. It allows you to tilt the monitor up/down/left/right and control the radius of its curvature, among other tweaks. I picked a really exaggerated, low-radius curvature, since these displays were often very small (sub-15 inches), but I used the pincushion control to flatten the middle out some, just as you would on such a small display.

These presets also leverage blurbusters' and Timothy Lottes' crt-beam-simulator shader whenever shader subframes are enabled, and, in addition to the motion clarity improvements, I think the flicker it introduces provides another level of verisimilitude that I wasn't able to capture properly in still shots.

The monoCRT shader also includes several different monochrome phosphor colors:

Just be sure to use integer scaling with this shader, since the scanlines look like crap otherwise. As usual, it looks better when it has more pixels to work with, and I think 5x scale is a minimum, making integer overscale on the Y axis a great way to experience these on 1080p displays. 

So that's what I've got. The 'frontlit-reflective' shader is available in handhelds/shaders, and monoCRT is available in crt/shaders, if you want to use them in your own presets. Most of the presets I've shown here (authentic-gbc-frontlit, black-and-white-tv, and apple-monitor-ii) are available in the 'presets' directory. Aside from the beam sim effect and the gyro controls, which aren't widely supported outside of RetroArch, these shaders should work fine anywhere you can load slang shaders (e.g., ares, snes9x, OpenEmu, etc.).

6-button Pads in RetroArch

For the next post in my series aiming to de-mystify using abnormal input devices in RetroArch, I'd like to take a look at gamepads with six face buttons. I touched on these briefly in my previous post about N64 mapping, but we get a lot of confused users wondering why they can't find C and Z buttons in the input menu or outright claiming RetroArch doesn't work with 6-button pads.

Ultimately, this confusion typically stems from an incomplete (or altogether nonexistent) understanding of how RetroArch handles input--specifically, through the retropad abstraction that cores and frontends use to communicate--but the most basic aspect of this misunderstanding may admittedly come from our use of Nintendo-style button names and 4-face-button images in our UI:

Now, the retropad concept is core to libretro and RetroArch, so we can't make any major changes there, like adding additional buttons or changing the names of existing buttons, without modifying every single core ever made, which would be a lot of work and just generally not worth the trouble for what is a niche input modality (no offense to 6-button peeps).

Thankfully, buttons is buttons, and changing icons for those buttons is very easy. Just download this pack of modified icons, unzip the archive and drop the 'assets' folder into your RetroArch folder, overwriting any conflicts. Again, this will not change the names of the buttons from the Nintendo-style names, but it will update all of the helper icons, like this:

Hopefully, this will help 6-button users have an easier time mapping their devices and allow them to navigate the user interface more intuitively.

These icons will get wiped out if you update your assets, but you can always just go through this process again to get them back. I've applied the icons, wiped them out by updating and then reapplied them a dozen times or so while writing this post.
 

N64 VI Filter

The N64's RDP chip includes a Video Interface (VI) stage that prepares the video for the final output. From the N64 Programming Manual:

The video interface reads the data out of the framebuffer in main memory and generates the composite, S-video, and RGB signals. The video interface also performs the second pass of the antialias algorithm. The video interface works in either NTSC or PAL mode, and can display 15- or 24-bit color pixels, with or without filtering, at both high and low resolutions. The video interface can also scale up a smaller image to fill the screen.

These functions can make a very big impact on the final image of an N64 game, and the ParaLLEl-N64 libretro core exposes the ability to toggle the postprocessing effects of this stage on and off. Turning it off nets you a few frames per second of speed but also gives us a peek behind the VI curtain:

Filtered

Unfiltered

So, you can see that the filter just barely touches the HUD elements but it does some pretty dramatic stuff to the rest of the image. It applies strong antialiasing to the outside edges of objects, which has a big, noticeable effect (so noticeable, you can see it in the thumbnail images) on Mario's hat and the silhouette of the tree, and it does some blurring that smooths out the dithering that is very visible in the unfiltered shot. On actual hardware, the blurring can be toggled off in some games (Quake II, for example, IIRC) or using Gameshark codes. I believe consoles modded with UltraHDMI or etim's N64RGB boards can also switch it off through the boards' firmwares.

RetroArch Overlay Borders

RetroArch has long had support for fun borders/backgrounds that can fill the unused black space on HDTVs using a specially crafted shader combined with an image, as described in a previous post. However, this system can be finicky and it isn't very forgiving of different screen sizes and aspect ratios. There is another way to achieve a similar outcome, though, using RetroArch's built-in overlay system.

Gameboy border pictured with Harlequin's Gameboy shader

This system was designed to provide onscreen touch controls for the Android and iOS ports of RetroArch, but we can use the same hooks on PC to display our borders. All you have to do is add this to the bottom of your retroarch.cfg:

input_overlay = "/path/to/overlay.cfg"

You can also load overlays directly from the in-game RGUI menu under Settings > Overlay Options.

The overlay.cfg file is extremely simple, containing only 4 short lines (you can either copy these into a blank text file yourself or use the one I include in the download at the bottom of the post):

overlays = 1
overlay0_overlay = border.png
overlay0_descs = 0
overlay0_fullscreen = true 

This file tells RetroArch that there will only be 1 overlay, which image to load as the border (in this case, border.png, located in the same directory as the overlay.cfg), that there will be no buttons attached to the overlay (that is, for touchscreen controls) and that it will take up the full screen, including any black space.

In addition to these border effects, you can also use this system to apply semi-transparent overlay effects, such as scanlines, which can be useful in very low-power settings, such as on Raspberry Pis, homebrew-capable Nintendo Wiis or older cell phones that can't handle even lightweight scanline shaders. Even some MAME "rgb" effects can be used with this system with minor modification.

This system will work fine with the borders from my previous post, and here's a bunch more (formatted for 1920x1200 displays) from NeoGaf user richisawesome.

Here is the download (contains border.cfg, two example borders and an integer scale Cg shader, though the shader should not be necessary now that you can force integer scaling through RGUI):

http://www.mediafire.com/download/1fpa407519jg2hu/overlay-borders.zip

UPDATE (06/02/2014): You can also check out RetroArch's overlay repository on github.

Getting Started with RetroArch

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

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

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

Once your download finishes, extract the zip file, navigate to the extracted RetroArch folder and look for retroarch-phoenix.exe. This is the graphical user interface (GUI) module that will help us get RetroArch set up and configured. Double-click it and you should see a window that looks like this:

Along the upper edge of the window, open the RetroArch menu and select Update RetroArch:

It should open a window that looks like this:

You can use this tool to automatically download updates for RetroArch, its helper libraries and any/all of the various emulation cores. First off, you'll need to select which flavor of RetroArch you're using--x86 or x64 (aka x86_64)--by clicking on the appropriate bubble next to CPU.

Then, click on the button labeled Check version. This will search for updates to RetroArch and/or its helper libraries and populate the list of available emulation cores:

After that, click on the bubble labeled Redist and then the button that says Download RetroArch. This will fetch any updated RetroArch executables, as well as fresh copies of all of the helper libraries (you can update RetroArch without the helper libraries by using the Full button instead of Redist).

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

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

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

Next, we need to tell RetroArch where to store and load its settings, via the RetroArch config file path. Click Open, and then navigate to your RetroArch folder and choose the file named retroarch.cfg. Likewise, for RetroArch path, click Open, navigate to the same folder and select retroarch.exe.

Finally, the Emulator core path lets us select which emulation core we wish to use. So, click Open, navigate to the RetroArch folder and look for your desired core that you downloaded from the Updater, such as gambatte-0.5wip1-x86_64.dll in my case. RetroArch can be paired with any emulator core that conforms to the libretro API specification, including but not limited to the original libretro (previously known as libsnes) derived from byuu's bsnes.

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

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

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

For Linux Users

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

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