New and Updated Shaders

It's been awhile since I've done any shader posts, so I figured I'd cover some updates that have happened recently. Same format as usual, the only difference this time around is that instead of zooming into screenshots using photoshop, I made them straight from RetroArch using the 'zoom' from my image adjustment shader. This gives sharper, cleaner detail shots. Anyway...

No Shaders (Nearest Neighbor)

Here is a shot with no shaders for comparison.


ScaleFx

Sp00ky Fox had been working on cleaning up artifacts from the Scalenx shaders and, in the process, worked up a similar algorithm of his own, known as ScaleFx. By cranking it up to 9x, he managed to do some pretty impressive smoothing:

Some notable things here: check out the circle-c copyright symbol, which is very hard to deal with in this sort of shader, as well as the straight lines throughout the logo and on the shallow slope below the dragon coin.

He also made a variant, known as scalefx-hybrid-9x, that uses reverse-antialiasing and creates some interesting depth and shading effects:

It does introduce some haloing, though, and is pretty heavy, performance-wise.

xBR-lv2-accuracy-multipass

For the past year or so, Hyllian has been working to improve his now-famous xBR upscaling algorithm, mostly by pairing it with other algorithms and working to improve handling of problematic edge-cases. Very recently, though, he changed the way corners are detected and added a new color diff algorithm, which fixes some weird artifacts that could occur when bright red and bright blue pixels were next to each other (artifacts not pictured):

Here is an older version of the same shader for comparison:

Again, the copyright symbol is a good example of the improvements, along with the circles inside the number 9s. The updated version also works quite well with Playstation-era antialiased images, while ScaleFx works best on bold, cartoony graphics, like Super Mario World and Shantae.

CRT-Lottes Updated

Since we first ported Timothy Lottes' scaling pixel art shadertoy, he did a couple of iterations to add bloom and a few more variations on his awesome shadow mask code. r5 incorporated those updates into our port and threw in some runtime parameters (including the aforementioned mask variations):

This is the default compressed TV-style shadow mask^^.

This is the Trinitron-style aperture grille^^.

This is the stretched VGA-style shadow mask that was used in the original shader^^.

And this is another VGA-style mask with larger phosphors^^.

CRT-Royale-Kurozumi Preset

Shmups user Kurozumi posted some really nice settings for TroggleMonkey's CRT-Royale shader that makes it look very much like a high-res broadcast monitor (e.g., Sony's BVM line or the 800-line PVMs):

I put these settings into a cgp preset, located in the 'cgp' subdirectory of the main common-shaders repo.

True Hq2x Shader Comparison With xBR

Background
I was shocked to learn recently that the shader I and others have long called Hq2x is/was actually a misnamed port of another shader entirely! guest.r originally put out a 2.0 scale shader with a suffix "HqFilter," which stands for a part of the color blending code. Over time, this shader was ported to a million different emulators (including the official Metal Slug PC releases) and, at some point, the name got confused with another popular emulation upscaling algorithm, Hq2x. As CPU filters have been supplanted over time with GPU shaders, no one seemed to notice that no true shader port of the classic Hqnx algorithm--in any scale--existed in any language. EDIT: looks like there was an attempt to port it back in 2005 but it never caught on because it was incomplete and had some bugs, but it's something.

Fast-forward to a few weeks ago, when a shader programmer named Armada brought this up in RetroArch's IRC channel. He shared some pics of the "Hq4x" shader in the common-shaders repo (which itself was based on the old XML shader in bsnes' gitorious repo, which in turn was based on guest.r's ePSXe shader) and an identical pic taken using a CPU-filter version of Hq4x. The differences were obvious and indisputable:

I started digging through old forum posts and it turns out that several people had noticed this over the years, but no one ever posted any comparison pics or were able to backup their suspicion in any way.

Armada and I did find that there was an old DOSBox renderer called OpenGL-Hq that was at least a step in the right direction, being a hardware-accelerated implementation of the Hqnx algorithm, and it was helpful insofar as it demonstrated how the algorithm can use an external lookup texture for the detection. However, it was not particularly applicable to modern shader language, so Armada set out to port directly from the CPU filter's C implementation.

After some intense work, which included creating a program to generate the LUTs that Hqnx bases its calculations on, Armada completed his shader port (also copied into the common-shaders repo) and it works beautifully! Incidentally, the requirement for LUTs means that a true Hqnx port wasn't even possible until fairly recently, as SSNES/RetroArch is/was the first emulator (that I know of, at least) to support LUTs in shaders.

Comparison Shots
If you've read over my previous comparison of Hyllian's xBR vs Hqnx, xBR won by a landslide in pretty much every comparison, which is no surprise because it wasn't really an apples-to-apples comparison. That in mind, here are updated pics that show a true comparison between the two algorithms (2xBR shader first, Hq2x shader right after and Hq2x CPU filter third):

The first thing you'll notice in those Super Mario World shots is that Hq2x does a great job of killing the jaggies. Much better, in fact, than ScaleHQ from the other comparison, and almost as good as xBR. There are a couple of rough edges (Yoshi's nose is a good example), but Hq2x is also *very* fast, so reasonable tradeoffs here. Hq2x does completely ignore the light texture blobs in the ground, leaving them as hard-edged rectangles, while xBR turns them into ovals. You can also see some slight lingering differences between the Hq2x CPU filter and the Hq2x shader, where the shader actually does a significantly better job of handling various detections.

On these digitized shots from Earthworm Jim 1 and 2, though, the comparison sort of falls apart. xBR is able to spot the jaggies and smooth them out while Hq2x doesn't spot any patterns at all, due to them being outside of its LUT's detection matrix. In fact, Hqnx's inability to work on antialiased images is one of the reasons Hyllian developed xBR in the first place.

It's also worth looking at how the algorithms differ in handling text. For this comparison, I included the two extremes of xBR's corner detection, with the 'a' variant as the most rounded and the 'c' variant as the most square:

 

In this comparison, Hq2x is essentially indistinguishable from xBR's 'c' variant, insofar as the text is concerned. The xBR 'a' variant is of course substantially more bubbly, which may be desirable for some games.

Conclusion

My previous comparison wasn't really a fair fight, and I apologize to Mr. Steppin for misrepresenting his algorithm. This is a much better comparison of the algorithms, and in ideal conditions, Hq2x is almost identical to xBR in smoothing while running much faster. However, in other cases--particularly digitized artwork--limitations in Hq2x's pattern detection can leave some images completely unsmoothed.

The speed of Hq2x makes it attractive for certain use-cases, such as mobile, where performance is still of the utmost importance and xBR either doesn't hit full speed at all or else drains your battery. xBR, on the other hand, can handle a greater variety of images and is more likely to produce a pleasing image with the digitized artwork that became more common in the PSX era.

xBR vs HQx Interpolation Filter Comparison

UPDATE: the comparisons in this post aren't a true representation of hq2x (more info in this post). The xBR shots are still valid, but don't put much weight on the comparisons without reading the other post for context.

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. The two main points that can be fine-tuned are the formula used to measure the distance between colors and the way the algorithm treats corners (more on the corners later).

Hyllian began development of xBR in 2011 as a plugin for Steve Snake's Genesis/Mega Drive emulator, Kega Fusion.

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.

Closely related to xBR are the SABR shader by Joshua Street and Zenju's xBRZ CPU filter. SABR was written by Mr. Street as part of a school project and it differs from xBR in a couple of ways, including using antialiasing on edges. It was forked from Hyllian's 5xBR v3.7c shader. xBRZ is a rewrite of the xBR algorithm in C++, with some changes to the corner detection and color distance measurement. It was forked around xBR v3.5.

There is also a standalone library written in C that incorporates both the xBR algorithm (as it appears in FFmpeg's libavfilter) and Hqx. You can browse this project's source on github.