N64 3-Point Texture Filtering in mupen64plus-libretro

The Nintendo 64 console used a lot of weird hardware that contributed to its distinct look. For example, N64s used bilinear filtering when scaling some textures, similar to how modern GPUs handle texture resizing, but instead of using 4 sampling points like modern hardware, the N64 only used 3 (current texel, upper-left and bottom-right).

Update (12/29/18): I thought it would be helpful to post some text from Nintendo's patent filing regarding the N64's texture filtering:

Texture filter 532 in this example can perform three types of filter operations: point sampling, box filtering, and bilinear interpolation. Point sampling selects the nearest texel to the screen pixel. In the special case where the screen pixel is always the center of four texels, the box filter can be used. In the case of the typical 3-D, arbitrarily rotated polygon, bilinear filtering is generally the best choice available. For hardware cost reduction, display processor texture filter unit 532 does not implement a true bilinear filter. Instead, it linearly interpolates the three nearest texels to produce the result pixels. This has a natural triangulation bias which is not noticeable in normal texture images but may be noticed in regular pattern images. This artifact can be eliminated by prefiltering the texture image with a wider filter.

This caused textures to have a distinctive, hexagonal "rupee" shape:

Image taken by TrekkiesUnite118 on the Sega-16 forums; see the texture pattern on the wall.

When emulating an N64, if you use modern 4-sample bilinear filtering, those textures don't render properly, which can lead to ugly artifacts, like the jagged texture under these stairs in Kakariko Village:

Way back in 2010, there was a discussion on the devmaster forums about reproducing this 3-point sampling in software with some great screenshots and code samples. Then, a couple of years later, ArthurCarvalho posted an HLSL shader that performed the same function on the Emutalk forums.

Skip to 2014 and my friend aliaspider, author of the awesome GTU shader and the guy responsible for porting RetroArch to the PSP (among many other things), ported this HLSL code to GLSL and plopped it into the rendering code for the libretro fork of mupen64plus, where it is applied on a per-texture basis. This clears up many of the texture artifacts typical of N64 emulation and provides that familiar, pointy-textured look:

To my knowledge, no other N64 emulators have implemented this texture filtering option at the time of this writing. Update (9/15/2015): looks like gonetz has added it to his crowdfunded gliden64 plugin.

Creating a Custom EDID for Arcade Monitor

Since I got my arcade cabinet up and running with my J-PAC-connected PC running RetroArch, the last finishing touch I wanted was to make it boot directly to the right resolution in a text-mode console and launch RetroArch in KMS mode, which provides the lowest latency and best experience. This ended up being easier than I expected, but it did require some steps I hadn't messed with in the past.

First thing you'll need is a working modeline. I created an ultra-wide 1920x240/60 modeline using this online calculator. Using a wide resolution like this leverages the natural blurriness of CRTs to hide fractional scaling artifacts on the horizontal axis, while the 240 vertical resolution allows perfect 1:1 scaling on the vertical axis. This provides a beautiful, "pixel-perfect" image for a large variety of games, including my favorites--Capcom's CPS-1/2.

This is the resulting modeline (negative sync options added by me):

Modeline "1920x240@60" 31.96 1920 1952 2072 2104 240 245 248 253 -HSync -VSync

I recommend testing your modeline out in a standard desktop environment using xrandr first, since it's pretty low-stakes. If something messes up, you just reboot and everything goes back to normal.

Once you've verified that your modeline works, you're ready to create your custom EDID. There are several good writeups about the process online, but I found this one most helpful. I won't rehash all the steps here, but you essentially just copy the appropriate files from the kernel tree and modify/rename one of the existing EDID source files (I used 1024x768.S) with the values from your modeline (I named mine 1920x240.S).

Here's the important part (i.e., license boilerplate removed for brevity; it's standard GPL2) from mine:

/* EDID */
#define VERSION 1
#define REVISION 3
/* Display */
#define CLOCK 31960 /* kHz */
#define XPIX 1920
#define YPIX 240
#define XY_RATIO XY_RATIO_4_3
#define XBLANK 184
#define YBLANK 13
#define XOFFSET 32
#define XPULSE 120
#define YOFFSET (63+5)
#define YPULSE (63+3)
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Ultrawide"
#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
#define HSYNC_POL 0
#define VSYNC_POL 0
#define CRC 0xf7
#include "edid.S"

Next, compile your source files, which should leave you with 1920x240.bin and 1920x240.bin.ihex (the *.ihex one is unneeded, AFAICT). Open 1920x240.bin with the edid-decode utility (available from the standard Ubuntu repos) and it should tell you something about the checksum being wrong (assuming you're making your own; mine already has the corrected checksum). Reopen your custom *.S and replace the existing, incorrect checksum where it says "#define CRC [whatever]" with the value it says it should have and then re-compile. It shouldn't complain this time.

Here's my compiled 1920x240.bin EDID, which should work for any standard-res 15 khz arcade monitor.

Once you have your shiny new EDID *.bin file, you'll need to create a new directory in /lib/firmware called 'edid,' which will require elevated privileges:

sudo mkdir /lib/firmware/edid

Then copy your *.bin file into it.

Next, you'll need to create a file named drm-kms-helper.conf, which contains only one line:

options drm_kms_helper edid_firmware=edid/1920x240.bin

and move it into your /etc/modprobe.d/ directory (again, needs elevated privs). Of course, you'll need to replace '1920x240.bin' with whatever you've named yours.

At this point, your custom EDID should be usable by your system, so a reboot will get you the desired resolution. If something goes wrong and you need to revert, just delete /etc/modprobe.d/drm-kms-helper.conf and it will put everything back the way it was.

If--like me--you'd like to go all the way and boot to a command line (instead of a standard GUI environment) that uses the new res, you'll want to edit your /etc/default/grub (needs elevated privs again) and replace the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

with

GRUB_CMDLINE_LINUX_DEFAULT="text"

Then run 'sudo update-grub' to put it into effect. Now, on subsequent reboots, it won't try to load an X-Server and desktop environment and will instead go straight to console.

Finally, I don't plan on having a keyboard connected to my cabinet all the time (kinda kills the mood, y'know?), so I wanted it to login to my user account automatically. To do this, edit /etc/init/tty1.conf in a text editor and comment out the last line:

#exec /sbin/getty -8 38400 tty1

and add this below it instead:

exec /bin/login -f username < /dev/tty1 > /dev/tty1 2>&1

Replace 'username' with the name of the user account you want to login automatically. And, if you want to have it load a frontend--like RetroArch--as soon as it finishes logging in, you can add the launch command to the end of that user account's ~/.bashrc file.

Neotec 2515c Flyback Transformer Problem

I got my new JAMMA-compatible arcade cabinet up and running with MAME via RetroArch, but I noticed that the screen is blurry and has these weird, diagonal-ish horizontal lines going across the top half of the screen:

After digging around online, it seems these are known as retrace lines, and they occur when the flyback transformer is applying too much voltage to the screen. This behavior is typically accompanied by excessive brightness, as well. Normally, the solution to this would be to find the 'screen' knob on the flyback itself and turn it down just a bit until the lines go away.

However, I also learned that my specific monitor, a Neotec 2515c, is notorious for failing flyback transformers, and the issue becomes more pronounced as the monitor warms up. It also causes the image to get excessively blurry over time, to the point that small text becomes unreadable and bright colors turn into a smeary mess.

On the bright side of this being a super-common issue is that replacements can be found pretty cheaply, like this one from Twisted Quarter ($25 for one at the time of this writing), and they're pretty easy to replace, since they're expected to fail over time. In fact, next to leaky/fried capacitors, a dicky flyback is one of the most common problems a CRT display can face.

Nevertheless, fixing it means performing surgery on a CRT, which is home to many capacitors and high-voltage loads, so it's not for the faint of heart. I intend on tapping some local expertise to prepare for the task and will post some pics as I move forward.

In the meantime, I'm just going to keep my cabinet turned off unless I'm actually playing something to minimize the issue when I'm using it.

Update (9/15/2015): I ended up not doing the repair myself. After some local (mis)adventures, I shipped my board off to Sharp Image Repair in Las Vegas at the recommendation of Jason Wilson, who owns/runs Game Galaxy Arcades in the mid-TN area. Sharp's level of communication via email wasn't stellar, but the quality of their work certainly was. I would recommend them to anyone residing in the U.S., as they were quick, thorough and very reasonably priced.

For anyone that decides to take the job on themselves, make sure you check and compare the actual thickness of the wires on the new and old flybacks rather than going by the colors of the wires, as the replacements frequently use the same colors only reversed, and getting them swapped will definitely fry some stuff... -_-

If you want to see some shots of the repaired monitor, you can check some out at the bottom of this post.

Hooking a PC to my Arcade Cabinet

As I mentioned at the end of my previous post, I traded my Super Punch Out!! cabinet for a generic Dynamo cab that I intend to drop a Street Fighter II Turbo: Hyper Fighting board into at some point. In the meantime, I decided to hook up a PC for use with emulators, specifically MAME via the RetroArch frontend.

As with my TVs and Retro Gaming post, this subject ended up being more complex than I anticipated, and the information available online is incomplete and often takes place on forums with poorly hosted pics, etc. So, I thought I'd share my experience here in the hope that others can avoid any potentially costly mistakes.

First off, it's important to realize what an arcade cabinet really is: a low-res tube television in a giant wooden box with some lights and speakers, not unlike one of those old console TVs. The major difference is that arcade monitors use an RGB connection, which--as stated in my TVs and Retro Gaming post--is the cream of the crop for video quality. That stated, if you don't already own a cabinet and you live in PAL land, you could build yourself a big wooden box and drop a SCART-capable CRT into it and have much the same results with a VGA-to-SCART adapter. To do the same thing in NTSC regions, you would need a TV with "component" (aka YPbPr) video inputs and a VGA-to-component adapter. If you decide to go this route, you'll be able to achieve a pixel-perfect arcade picture on your boxed TV using emulation, but you won't be able to connect actual arcade boards. You'll also need to take care that your PC is outputting a 15 khz horizontal sync rate video signal, which can be difficult to achieve with standard PC components (more on this later).

I wanted to be able to connect actual boards, so I went with an actual arcade cabinet, which adheres to the JAMMA video and connector standards. If you decide to go down this path, I strongly recommend going JAMMA-compatible, rather than using some funky custom cabinet (e.g., a Punch Out!! / Play Choice 10 cabinet...), as it will make switching among boards--and your PC--much easier. That was the entire purpose of the JAMMA standards, after all.

The JAMMA connector standard supports 2 players, each with an 8-way joystick (i.e., 4 switches per) and 4 buttons each (a start button and 3 action buttons for each). This is plenty of inputs for most games, but not for the 6-button fighting games that became popular toward the end of the arcade era. The JAMMA standard was extended to accommodate these additional inputs--sometimes known as JAMMA+--but this limitation to the original standard is important to keep in mind.

So, assuming you have a JAMMA/+-compatible cabinet and monitor, you have some other decisions to make. For controls, you have a number of options, including: 1.) dropping in the guts of a pair of USB joysticks, like the Mad Catz TE/SE arcade sticks, which are well-supported on PC, 2.) use the guts of a pre-made PC-to-arcade control panel, like those from X-Arcade, 3.) use a purpose-built control interface board, like Toodles' Cthulhu board or Ultimarc's I-PAC2/4 boards, or 4.) piggyback off the existing control panel connection to your cabinet's JAMMA connector via Ultimarc's J-PAC interface, which is what I chose:

The J-PAC allows you to keep the same controls whether you're on PC or actual arcade board, so you're not having to mess with a bunch of quick-disconnects every time you want to switch between the two. Moreover, the J-PAC is designed to block out incompatible video signals via the red jumpers. On a standard CGA arcade monitor, you'll want to leave only the bottom, 15 khz jumper and remove the other one, which comes defaulting to 31 khz (i.e., VGA standard, and potentially dangerous for some arcade monitors).

While the J-PAC is an excellent piece of kit, they have made a few design decisions that are...strange, to say the least, and you should be aware of them ahead of time. First, and possibly most importantly, J-PAC boards no longer come with a micro-USB port, but it seems none of the marketing shots on the websites of Ultimarc or resellers reflects this. Instead, all you get is some empty solder pads where the port should be:

Instead, they run the USB signal through the left-hand PS/2 port, so you can either connect the board to your PC using a PS/2 Male-to-Male cable, which I certainly don't have on-hand, or use a PS/2-to-USB adapter like this one (note: only "dumb," i.e., non-active, adapters will work):

in conjunction with a USB-A-male-to-USB-A-male cable, which is extremely uncommon and, again, I certainly did not have one on-hand. So, since I had to order something anyway, I went with a PS/2 Male-to-Male cable, since PS/2 is a stream protocol and doesn't have the limitation of USB polling rates.

The other strange choice is on the VGA port. Instead of attaching a VGA female port, as you might expect from monitors and so forth, they have attached a VGA male port, which means you can't use a normal VGA cable and must instead use a VGA extension cable (i.e., with one male end and one female end). This choice is made stranger still by pairing the male VGA port with *female* thumbscrew ports, which means you can't attach a normal extension cable without first removing the thumbscrew ports, which is the only thing holding the VGA port's faceplate to the board! After digging around in your cabinet for your lost faceplate, you can flip the thumbscrew ports around and screw the male ends into your VGA extension cable's female thumbscrew ports, but the on-board port gets in the way of the screws turning and basically makes it a big pain in the ass.

Andy, if you read this: please switch to a female VGA port, or at least fix the thumbscrew/faceplate issue. It's quite frustrating.

Anyway, once that's all done, you'll also need to attach your additional buttons--that is, the 3 kick buttons for each player--to the handy screw terminals on the left-hand side of the J-PAC. Ultimarc has given us 5 additional inputs per player (conveniently labeled 1SW4, 1SW5, etc.), as well as unpowered speaker ports (powered speaker ports would have been nice, of course, but it's a limitation of the JAMMA connector's power draw, apparently) and a couple of grounds. I was pleased to find that I didn't need to actually hook anything up to the provided grounds, as the existing common-ground that was already daisy-chained across my control panel buttons worked just fine. This will reduce the amount of fiddling with disconnects necessary when switching to an actual arcade board from the J-PAC.

As a result of the unpowered speaker ports, you'll need to either cannibalize the amplifier out of some cheap computer speakers and attach your cabinet's speakers to it, or else simply drop some computer speakers, amplifier and all, into your cabinet and call it a day, which is what I decided to do. It doesn't sound awesome, but it's passable.

You'll also have to decide how and where to house your PC components within the cabinet. Arcade cabinets have a substantial amount of empty space inside of them, particularly down around the coin door, but none of it is really easily accessible unless you can remove the entire back of your cabinet. On mine, the back does not remove easily,  other than a small access hatch for servicing the monitor, so I stuck my PC components in there, below the monitor cage, beside the cabinet's own power supply:

As you can see, I also rigged up an extra arcade pushbutton I had lying around to serve as the PC power switch.

Speaking of the cabinet's power supply, Ultimarc's own J-PAC installation instructions recommend completely disconnecting your cabinet's power supply from the JAMMA connector and only leaving it connected to the monitor. This is good advice for very old cabinets/power supplies, which can burn out over time if they don't see a load in the proper places. It was also good advice in case you plugged your J-PAC into the JAMMA connector upside-down, but this evidently isn't a problem anymore due to changes in the circuitry. I've also screenshotted Andy's post about it in case that link dies at some point:

Once you have everything installed and situated, you can power on your cabinet and PC and see how it treats you. As long as your J-PAC only has the 15 khz jumper attached, you can rest assured that your precious monitor will be safe, though it's likely you won't get a picture at this point due to incompatible sync in the signal. Instead, you'll just get a crazy image that looks kinda like trying to watch the scrambled premium channels on old analog cable TV.

If you're absolutely certain you can make the correct, non-damaging signal, you can skip the J-PAC and use a "dumb" VGA-to-arcade-RGB adapter like this one:

Either way, to get an image to show up, you'll need to use a compatible resolution and sync. On Windows this is achieved through a piece of software known as Soft15khz. In Linux, you can make it happen with the xrandr utility or by adding a custom modeline to your xorg.conf file (which probably doesn't even exist anymore; you'll have to create one from scratch, which is a bit of a hassle). You can also use a custom EDID, which is nice because it works with KMS consoles, but you'll have to recompile your kernel, nvm, you can specify custom EDIDs from GRUB (see this post for details). I went with the xrandr method, and I used a custom resolution of 1920x240. This aspect ratio may seem crazy, but CRTs don't really care what kind of horizontal resolution you feed them, so you can use a super-wide resolution like this and it will make fractional (i.e., non-integer) horizontal resolutions all look fine. 1920 also happens to be exactly 5x the 384 horizontal resolution of CPS-1/2, so Street Fighter games will be perfect. The JAMMA video standard calls for negative composite sync, so any custom modelines you create using modeline calculators (like this one) will need to end with "-HSync -VSync" in order for your monitor to sync up properly.

Once you finally get a picture, it should look something like this:

And that's pretty much it. I purchased an old marquee from eBay for $25 (it has some scratches, but it matches the cabinet's condition, so all the better) and printed out the bezel artwork from some high-res scans I found online. You can buy professionally printed repros for the bezel art, marquees and control panel overlays (CPOs), but they tend to cost as much as old stock for something as relatively new and common as Street Fighter games.

It's also worth noting that it's illegal to actually charge money to play games on a MAME machine, and you have to pay some taxes and be licensed to even accept quarters for any arcade game, so you'll need to hook up an extra button that goes to the coin mech to give yourself credits.

I have some additional woes with my monitor (including a failing flyback transformer, which causes the screen to get blurry, overbright and show horizontal retrace lines toward the top of the screen), which I will cover in another post, as they don't really relate to the subject at hand.

Update (9/15/2015): here are some shots of my repaired monitor playing some games at native res in RetroArch:

My Super Punch Out!! Arcade Cabinet

I just came into possession of an arcade cabinet. It's a genuine Nintendo Super Punch-Out!! cabinet from 1984 (i.e., almost as old as me).

Here it is, in its new (temporary) home on my covered back patio:

 The marquee is in good condition with just a few scratches and the speakers are still intact, surprisingly. The monitors look pretty terrible in that shot, but don't worry: that's not burn-in, just dirt and cigarette tar scuzz. The paint/vinyl on the sides has some cracking/chipping at the bottom and there's significant warping to the first few layers of plywood on top, but otherwise, it's pretty much intact, if dirty. Here's a shot of the inside, full of leaves:

 After applying equal parts rubbing alcohol and elbow grease, I got the dirt scum off the monitors to reveal some light-to-moderate burn-in on both monitors.

 But really, it's not so bad considering this old gal had nearly 50,000 games played on her, according to the analog counter inside (that's more than $10k in quarters; pretty good ROI!):

 The cabinet also came with a piece of smoked plexi that goes in front of the monitors (not pictured in the first image), and this plexi was covered with the same dirt/tar scum that coated the monitors, so it needed a deep-cleaning, as well. During the process, I took a before/after shot to illustrate how thick and nasty that stuff really was (ignore the basset hound on the floor fishing for belly-rubs):

Between the coating on the monitors and the coating on the plexi, I doubt anyone would have been able to tell whether it were turned on or not.

I haven't had a chance to get inside and poke around yet, but I plan to check the monitors' capacitors to see if they've leaked and/or dried out, which would necessitate recapping them, and I intend to pull the actual game boards and see if they've suffered any corrosion from on-board batteries. If all is well there, I'll try to actually plug it in--which will require attaching a new plug to the currently-bare wire-ends--and see if the transformer and power supply are still functional. I will also take apart and clean the coin doors, since they're a little janky, as well.

I'll update this post as I learn more :)

Update1:
I opened it up and was pleased to find that the batteries didn't seem to be terribly corroded:

I fitted a new plug onto the end of the bare wires, threw in some fresh batteries and powered it on. Everything seems to fire up okay, though there's not a lot of action:

At this point, I'm not sure if have a dicky connection to the board, a dead board or wiped eproms (their UV windows are uncovered and it's pretty bright inside my cabinet, due to the missing control panel). I know a guy who has an identical machine--in much better condition--who has offered to test the board for me, so that will be my next step, I think. In the meantime, I'll continue sprucing things up cosmetically.

Update2:
I drove my board out to test it in the aforementioned known-working cabinet and the results were less-than-great but better-than-bad:

The picture is blurry and there's a lot of glare on the plexi, but what you're looking at is some garbled graphics (no movement and no sound, unfortunately) and one perfectly-rendered '0'. This suggests to me that the board basically works--that is, it's not totally dead--but my eproms indeed need to be verified and my cabinet needs some more work to get even this far. I also need to go through and check all of my edge connectors and make sure the solder joints are secure and, if not, reflow them.

For the eproms, I'm hoping to borrow a USB programmer from a computer engineering professor at the university where I work. If that doesn't pan out, I can get one on eBay for $40.

Update3:
It was looking like getting SPO!! working was going to be more involved and expensive than I was really hoping to get into, and I didn't want to risk ruining a board that could actually make a collector very happy, so I traded the boards and cabinet to a really swell collector named Marv for this dandy of a JAMMA cabinet:

This is actually much more appropriate for my uses, since I can drop JAMMA boards in with ease (I intend to purchase a SF2: Hyper Fighting CPS-1 board in the near future) and, with the help of a J-PAC board, drop a MAME PC in with little-to-no modification. I'll be posting about this process soon.

Tomee SNES Retro Controller Review

I've been re-acquiring some old gaming consoles lately and it seems official SNES controllers are getting pretty expensive these days, commanding $15-20 at the time of this writing. I already had one official controller but wanted to get a second controller on the offhand chance anyone wanted to play a 2-player game. I wasn't too keen on paying the full price for an official one, so figured I'd try out the Tomee SNES controllers, which are super-cheap and readily available (i.e., no eBay; I got a 2-pack for ~$7 on Amazon).

To be clear: at a price of $3.50 each, these controllers are totally worth the money. They're functional and have a look and feel that's reminiscent of the official SNES controllers. I plugged them up and was able to play games just fine.

However, the plastic feels a bit flimsy and the d-pad is shaped a bit differently from the official Nintendo controller's (it's significantly fatter than the Nintendo version; Nintendo on top, Tomee below):

The four face buttons are also slightly different size and sit taller, though that's a pretty minor issue, IMO (Tomee on the left, official Nintendo on the right; the pic's blurry because my camera kept focusing on my hand instead of the controllers...):

The L/R buttons are significantly sharper-edged and clickier, though they rarely get used in games anyway, so it's also not a big deal. Perhaps more important is the fact that the Tomee controllers are thicker/fatter and don't taper the way Nintendo controllers do, which messes with the overall feel and ergonomics quite a bit (official Nintendo on the left, Tomee on the right):

The start/select buttons are much mushier than the official controller's and they're extremely prone to getting wedged under the controller face, which is more annoying than detrimental. Both of my d-pads also have an odd quirk whereby pressing down-left with a bit too much force will trigger all directions simultaneously. This can have some pretty hilarious results in games that weren't programmed to expect it, lol.

Overall, I think these controllers are a great value for someone who wants to do some casual playing or, in my case, just wants a second controller on-hand for the rare occasion that a friend/guest wants to throw down on some multiplayer action. If you're serious about your gaming, though, you'll want to have an official controller, which is more reliable, more comfortable and built to last.

If you're planning to use an SNES-to-USB adapter to use a real controller with an emulator, I suggest looking instead at the Buffalo Classic USB Gamepad, the price of which varies from around $12-20. This controller feels significantly more solid than the Tomee and actually feels extremely similar to a new official Nintendo SNES controller in weight and button-feel. Here's a (shitty) picture of mine next to one of the Tomees for comparison:

HTC One M7 Purple Camera Problem

The camera is one of the main reasons I purchased an HTC One (M7), with its awesome low-light performance, so I was really bummed when my pictures started getting a weird purple tint around the edges. The problem got progressively worse, to the point that the camera was essentially unusable:

So, I did some digging online and, while my case is abnormally serious, the purple picture problem seems to be a common issue for HTC Ones that were manufactured early on in their product run (I preordered mine and got it right at launch). No one is exactly sure what causes the problem, but people suspect it's related to heat, either in the phone itself or specifically at the "ultrapixel" camera sensor. Either way, replacing the camera module supposedly fixes it, and there have been reports of individuals sending their phones in for other warranty issues and getting them back with newer camera modules, whether they reported purple pics or not.

In my case, I went down to the local Sprint affiliate and inquired about a camera replacement. The tech started an insurance report and found that 'camera takes purple pictures' was one of the pre-defined claims, so he was able to order a refurbished phone for me on the spot at no cost (not even an insurance deductible!). A couple days later, I received my new phone and its camera works as well as I remembered. I'll update this post if it starts showing the same issues.

CRT-Royale and 3dfx Shaders

Two fairly new shaders have popped up that are worth mentioning: TroggleMonkey's CRT-Royale and leilei's 3dfx. They're both available in Cg format in libretro's common-shaders github repo, though CRT-Royale utilizes some advanced features that aren't available in RetroArch v1.0.0.2 (the most recent release at the time of this writing).

CRT-Royale is particularly exciting for me because TroggleMonkey managed to overcome some issues with shadow-mask emulation that I thought were totally intractable at current common resolutions (i.e., 1080p). The result is some really great phosphor emulation at reasonable scale factors, along with all of the bells and whistles users have come to expect from CRT shaders, including "halation"/glow, bob-deinterlacing support and curvature, along with a ton of options that are unique to this shader.

I'm not going to cover many of them here because it would take forever to get screenshots and there's not much point when TroggleMonkey has included a very informative README with the code, along with support for RetroArch's new runtime parameter support (so you can see the effect of your changes in real-time). However, I thought the shadow mask stuff was super-cool and deserved some closeups. Here's a shot of the shader with default settings (as always, click to embiggen):

First, we'll look at my favorite effect, the in-line shadow mask (called slot-mask in the code):

This is the same configuration I was shooting for with my PhosphorLUT shader, and you can see that the configuration of the phosphors has that familiar vertical, staggered orientation:

Next, we have the very similar aperture grille:

 

The main difference between this and the in-line slot mask is that it doesn't have the slight staggering (only really visible in the closeups and at super-huge resolutions). In closeup of the LUT, you can see that it just removes the crossbars between triads:

Last, we have the dot-triad shadow mask (called "shadow-mask-EDP" in the code), which was common on CRT computer monitors:

 As you can see, it looks very similar to the high-res shots I took of my Compaq CRT monitor (from my emulation/TV post). And here's the dot-triad blown up:

The other shader I wanted to show is leilei's 3dfx shader, which tries to mimic the effects of a 3dfx GPU, known for some distinctive dithering among other things. In addition to obvious applications like RetroArch's Quake core, Nintendo's N64 also used a GPU that was very similar to a 3dfx, which makes it appropriate for RA's Mupen64plus core. When run at low-ish internal resolutions and paired with RetroArch's per-texture 3-point filtering, you can get a pretty good approximation of what N64s looked like.

Here are some shots of the shader at 320x240 and 640x480 (i.e., native and double res, respectively):

Native res:

Double internal res:

 As you can see, the doubled res looks significantly sharper, but the scanlines are thinner and less pronounced (and twice as many of them) relative to the native res. I also like native res because it makes HUD/menu items look a little less "pasted-on":
Native res:

Doubled internal res:

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.