Friday, June 20, 2014

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.

Friday, May 9, 2014

Using X-Rite i1 Display Pro with Ubuntu Trusty 14.04

As mentioned in a previous post, I borrowed an X-Rite i1 Display Pro color calibration device from my job recently and have been calibrating every display I can get my hands on :P

This proved to be a bit of an issue on my various Ubuntu-powered machines, though, as the packages for dispcalGUI that are in the Trusty repos don't support the device yet! I discovered this when the program repeatedly failed with:
new_disprd() failed with 'Instrument Access Failed'
When trying to figure out what was going wrong, I opened up a terminal and ran the 'dispcal' program directly (that is, without the GUI) with the -D5 debugging switch, which gave a little more information:
init_inst returned 'Hardware Failure' (External EEPRrom checksum doesn't match)
new_disprd failed because init_inst failed
dispcal: Error - new_disprd() failed with 'Instrument Access Failed'
Evidently, the EEPRrom checksums can't be trusted and the newer version knows to ignore them, so go download the new version from the dispcalGUI website (I recommend scrolling down to the 'conventional installation' section, which has debs instead of fooling around with the default 'zero installation' business they point you toward).

With the new package, you should be able to use your device without any problems.

Thursday, May 8, 2014

Asus VG248QE Calibrated Color Profiles

Out of the box, the Asus VG248QE 144 Hz monitor has absolutely terrible color reproduction, but it doesn't have to be that way forever. I borrowed an X-Rite i1 Display Pro color calibration device from my job and used it to make some calibrated color profiles, which I'm happy to share with others who have this otherwise awesome monitor.

I had been using this color profile, which I found somewhere online (I don't remember where), but I made my own profiles for using 120 Hz refresh rate instead of 144 Hz, one for using a strobed backlight for anti-blur 60 Hz. and another calibrated at half brightness (not sure if this matters) for black-frame-insertion. For both of these profiles, my monitor had a built-in brightness setting of 24 and contrast of 53, just FYI. EDIT: I just set the monitor to the factory default 'standard' profile to keep things simple.

Also of potential interest, the dispcalGUI software suite includes a measurement of display latency, which was 15 ms for 120 Hz and 23 ms for 120 Hz with strobed backlight. I assume the increased latency was caused by the duration of the backlight blanking.

Saturday, April 26, 2014

Cx4 SNES Special Chip Image Download

Since byuu added low-level emulation support for the various special chips found in SNES games into bsnes/higan, anyone wanting to play those games has needed an image of the chips to go along with their ROMs. Most of the common SNES special chip images are available from caitsith2's SNES hardware page, except for the Cx4 image used in Mega Man X 2 and 3. Byuu is confident that the contents of the Cx4 image are non-copyrightable (it's just math tables) and hosted a copy of it on his own site for some time but that seems to be either down or missing since his various website overhauls, so I figured I'd host it here, from my mediafire account:
http://www.mediafire.com/download/9747o707ciq4lh8/cx4.rom

Tuesday, April 22, 2014

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):
x264
x265
x264
x265
However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)

Thursday, April 10, 2014

Interlacing Shader for CRTs

In the comments of my TVs and Retro Gaming post, GPDP and Monroe88 mentioned the need for a shader that would take a 480p signal from an emulator and either add 100% black scanlines on "240p" content or blank alternating fields each frame. In other words, they needed a shader that would interlace the default progressive signal, which would allow them to run their displays at 480p for all retro console emulation instead of having to switch back and forth between 320x240 (most games for NES, SNES, Genesis/Mega Drive etc.) and 640x480 (for games that utilized the added lines of resolution that interlacing provided, such as 2-player mode in Sonic 2, SNES' R.P.M. Racing, and tons of PSX games).

So, here's the shader in RetroArch-compatible Cg format:
/* COMPATIBILITY
- HLSL compilers
- Cg compilers
*/
/*
Interlacing
Author: hunterk
License: Public domain
*/
struct input
{
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
float frame_direction;
float frame_rotation;
sampler2D texture : TEXUNIT0;
};
void main_vertex
(
float4 position : POSITION,
out float4 oPosition : POSITION,
uniform float4x4 modelViewProj,
float4 color : COLOR,
out float4 oColor : COLOR,
float2 texCoord : TEXCOORD,
out float2 oTexCoord : TEXCOORD,
uniform input IN
)
{
oPosition = mul(modelViewProj, position);
oColor = color;
oTexCoord = texCoord;
}
float4 main_fragment (in float2 texCoord : TEXCOORD, uniform input IN) : COLOR
{
float4 res = tex2D(IN.texture, texCoord);
float y = 0.0;
// assume anything with a vertical resolution greater than 400 lines is interlaced
if (IN.video_size.y > 400.0) y = IN.texture_size.y * texCoord.y + IN.frame_count;
else
y = 2.0 * IN.texture_size.y * texCoord.y;
if (fmod(y, 2.0) > 0.99999) return res;
else
return float4(0.0);
}
It has two branching 'if' statements, which is horrible for performance in shaders, but this one is simple enough--and only needs to run at 2x--that it shouldn't matter.

UPDATE: In the comments, Monroe88 mentioned another very useful shader for use with 31 kHz CRT monitors: aliaspider's TVoutTweaks, which lets you add some nice effects, such as composite color correction and horizontal bandwidth (blends things like SNES' pseudo-hires transparency and other dithering effects), which will make the image a little closer to a 15 kHz TV. See Monroe88's comment below for more info and a pic.

Saturday, March 29, 2014

TVs and Retro Gaming / Emulation

INTRODUCTION

Retro gaming is a hobby of mine and, as I started looking into hooking my retro consoles up to modern displays, I found a bunch of incomplete information and dead links scattered among various enthusiast forums, along with misunderstandings and oft-repeated misinformation. So, after diving down the rabbit hole and exploring a bunch of different options, I decided to post my findings in the hopes of saving others from making any costly, avoidable mistakes.

THE ISSUES

I have a big LCD HDTV with a HTPC connected that I use for watching videos and playing emulated games, and I can use various shaders to achieve an aesthetically satisfying approximation of how my retro games looked on CRT TVs. However, there are a number of reasons to use the real hardware instead of emulation, such as emulation accuracy deficiencies--which can render some games unplayable or unenjoyable--and/or latency concerns.

Sadly, modern displays like my HDTV make retro consoles look like absolute crap and can create/exacerbate latency issues, as they recognize the consoles' double-strike/"240p" signal as 480i(nterlaced)--and rightly so, since standard NTSC signals are always 480i regardless of how they're presented; the 240p standard was not created until decades later and even then it wasn't referring to the signal from retro consoles--and attempt to deinterlace them. This adds at least 1-2 frames (16-32 ms) of latency as the deinterlacer tries to combine 2 sets of fields to create a full picture, and that's before the signal even reaches the TV's upscaling circuit, which then adds even more latency (how much is added by the scaler can vary wildly from display to display).

To avoid this whole mess, we have a couple of options:

DIGITAL VS ANALOG

If you really want to use your big, digital HDTV but want to minimize latency, you'll want to sidestep the deinterlacing/slow-scaling issue by plugging your console into an external line-doubler/scaler. The cadillac in this area is the XRGB-Mini Framemeister, which is a Japanese import and costs an arm and a leg (about $475 at the time of this writing). This sexy lady will take your "240p" input, double the lines to a true progressive signal and then upscale it to an HD resolution that gets piped to your HDTV via HDMI, all essentially laglessly (it adds ~1.5 frames of latency according to Fudoh from the shmups forum). It will even add in a scanline effect, if you want. If, like me, you don't have $500 to piss away on this sort of thing--awesome as it may be--there are some cheap Chinese boxes that can handle the upscaling and deinterlacing (but not the scanline effect) at a slightly lower quality and substantially lower price. This seems like a good compromise to me, though the loss of scanlines is unfortunate. However, if your upscaler has a VGA output (like these) and your HDTV also has a VGA input, you can put a separate scanline generator, like the SLG-3000 or Toodles' T-SLG, in between and get close to the same quality as the XRGB-Mini for much cheaper.

Another consideration, though, is that the XRGB-Mini also accepts RGB/SCART signals (see the 'Analog Signals' section below for more details), while the cheaper models like the one linked above only accept composite and S-video. :(

UPDATE: I actually did purchase an XRGB-Mini recently and it's beautiful. I highly recommend it and think it's well-worth the money for an enthusiast.

It's also worth noting that any of these upscalers will give you an extremely sharp picture, similar to what you get from unfiltered emulation with nearest neighbor scaling (i.e., super-sharp/pointy pixel edges), so this option is ideal for the pixel fetishists out there but may not be desirable to old-schoolers who grew up playing on crappy little CRT TVs.

If you chose to go the digital route, congratulations: you're done! Your upscaler is providing you with the finest picture available. However, you might still want to read the rest of the information here, as some of it may be useful to you anyway, particularly the parts about analog signal quality.

Personally, those digital, super-sharp pixels never looked good to me. I'm a big fan of the way CRT TVs look and how they handle those low-res images, so I am/was forced to purchase an analog CRT. Even on an old analog display, though, we still want to keep our picture as nice as possible, which brings us to our next concern:

ANALOG SIGNALS

As far as analog signals are concerned, the top of the heap is RGB, meaning you get an isolated signal for each color, which provides a crisp, clear picture when they're all combined. Just below that is S-video, which separates the luma signal (brightness information only; produces a black and white picture) from the chroma (color; R, G and B all together) signal so they don't interfere with each other. Far below that we have composite--the familiar yellow RCA jacks--which combines chroma and luma into a single signal where interference between the two (known as chroma/luma "crosstalk") significantly degrades the picture. Slightly below composite(!), we have RF, which takes the signal and encodes it into the same format used in over-the-air broadcasts (and you know how good those tend to look...). You can compare how these signals differ in quality by loading up an emulator with Blargg's NTSC filter, which has presets to emulate RGB, S-video, composite and RF.

MATCHING INPUTS TO SIGNALS

In the USA, high-quality inputs, such as component and S-video, are not commonly found outside of large (24" and up), high-priced televisions, such as Sony's Wega line, so if you have a big house and plenty of room (and a strong back), you'll probably want to go for a real hoss of a TV with plenty of inputs. Sadly, most small CRT TVs have only coaxial/RF and *maybe* composite/RCA, which means your picture will always look pretty crummy. I lucked out and found an Apex 14" model with an integrated DVD player that also has S-video, which is good enough quality for me, so my retro consoles are now covered.

If--like me--you are satisfied with the quality of S-video and will only be hooking retro consoles up to your analog CRT, congratulations: you're done! If, however, you are a super-picky "videophile" and you think S-video is only fit for unwashed plebs and/or you want to hook your PC up to your CRT, there's more to consider:

THE MANY FACES OF RGB

Within the RGB family, there are about a million different subsets that each serve their own purpose. For TVs in the USA/NTSC world, we have "component" video (terrible, vague name, btw), which is also referred to by the color space it occupies, YPbPr. For PCs, we have VGA, which uses the familiar--typically blue--15-pin connector. For European/PAL-land TVs, we have 21-pin SCART.

Note: Europeans are lucky enough to have SCART as a standard input for CRT televisions, and many retro consoles--SNES, for example--can output this standard directly. This is a pure RGB signal and will provide the cleanest, most crisp analog picture around. HOWEVER!!, Japanese SCART (also known as JP-21 pin) and European SCART have a different pinout and, as such, are not compatible, even though they have the same connector. If you want to use a Japanese/NTSC JP-21 pin cable with a European/PAL TV with a Euro-SCART input, you will need a pin converter like this one. The aforementioned XRGB-Mini, as a Japanese device, does not require such a converter.

Aside from SCART, it's generally pretty difficult to get RGB from retro consoles, but it's usually possible if you're determined enough.

Now, even though all of these signals and connectors are technically RGB, they are incompatible with each other due to differing sync methods and signal frequencies, which means you'll need a display that is compatible with the signal and has jacks available. This brings us to:

15 KHZ VS 31 KHZ DISPLAYS

One of the major limiting factors in a CRT is the horizontal scan rate, which is the frequency at which a display can move the electron gun from the left side of the display to the right and back again. CRT monitors, like the kind you would find attached to a crummy old Packard Bell computer, have a high horiz. scan rate of 31 kHz, while NTSC TVs have a comparatively low scan rate of 15 kHz. Furthermore, devices that expect the high scan rate of 31 kHz displays and send a high-resolution signal are not compatible with--and can actually damage--displays with the lower scan rate if connected. On the other hand, 31 kHz monitors can be coaxed into displaying a "240p" signal using driver hacks like CRT_EmuDriver or xrandr and/or custom xorg.conf modelines (for some excellent info on getting 240p in Windows, see Monroe88's comments after the post). This will produce the highest-quality image possible with an emulator:


The drawback to this setup is that each system you want to emulate needs to render in exactly its native resolution or else it looks like shit, with misshapen pixels and inconsistent scrolling everywhere. The specialized Groovy Arcade distro automates some of this, but you may still have to use your monitor's hardware calibration controls to get the image to fit/center properly. I found the constant tweaking to be a tremendous pain in my ass and not really worth it.

If you're in linux, here's how you can force your monitor to act like an NTSC TV (type into a terminal from an X-session desktop):
xrandr -q
This will tell you which display you're using and which modes are available by default. My display was hooked up to DVI-0 via a DVI-to-VGA adapter.
xrandr --newmode "240p" 5.979 320 332 368 380 240 242 246 263 +CSync
xrandr --addmode DVI-0 240p
(replace DVI-0 with whatever your card reports)
xrandr --output DVI-0 --mode 240p
Some older video cards (like my Radeon X600 pictured below) for PCs will have an S-video output next to their conventional VGA and/or DVI outputs, which allows them to connect directly to a standard 15 kHz TV with S-video input:

This is very convenient, but it comes at a price: the card presents an 800x600 resolution to the PC and then crunches that down to 480i (that is, a standard NTSC signal), and it *cannot* be convinced to do anything else under any circumstances (AFAIK). This output looks pretty good, but it's not nearly as crisp as the VGA 240p 31 kHz image, obviously:
On the other hand, it is only slightly worse than a direct S-video connection from console to 15 kHz TV:
While S-video will always be slightly blurrier than RGB, the 15 kHz display is simply not capable of producing an image as high-quality as the 31 kHz display's due to its lower resolution and larger, chunkier phosphors. If you have a TV with component/YPbPr jacks, you can use a VGA-to-component transcoder box--like this one--to keep a clean RGB signal from your PC to the TV. Since it's a 'transcoder,' you shouldn't suffer any signal degradation, ideally.

UPDATE (11/14/14): Here's a pic of a PC hooked up to a 15 kHz display (an arcade monitor, to be specific) via RGB:
The photo kinda sucks and doesn't really do it justice, but you can see that the space between scanlines is much less pronounced vs the 31 kHz monitor. There's also no NTSC color changes like you see in the S-Video shots, for better or for worse. Anyway, back to the original post...

Sometimes you want to use your actual retro consoles rather than emulating on a PC--particularly in cases where emulation quality is still relatively poor, such as Sega Saturn or Dreamcast--but you still want to get the highest quality possible, which brings us to:

BROADCAST MONITORS

Broadcast monitors are high-resolution CRTs that were used by video professionals, such as broadcasters and video editors, to preview high-quality signals during the production process. They cost thousands of dollars new but are now cheap as dirt (relatively), since those professions have moved on to digital/HD signals and formats. Sony's PVM and BVM series of monitors are the most well-known and sought-after among retro gamers and, as such, often command a higher price than some similar products from other manufacturers. Nevertheless, the *VMs and other similar broadcast monitors tend to come with a variety of high-quality inputs, including one or more RGB equivalents (though often with separate sync, which can require conversion from, say, SCART). Another nice thing about these monitors is that they tend to come with nice, flat sides, unlike most TVs, which allows them to be rolled onto their sides easily for TATE mode games, like shooters.

Broadcast monitors are available in sizes up to 30" or so, though models that large are extremely hard to find and tend to be quite expensive, even now, due to their rarity. They are also very expensive to ship, due to their weight, which means many of the auctions on eBay are local-pickup-only (and tend to be in California...). The smaller models of 20" or less are much more common, and can usually be had for between $200 and $300 dollars at the time of this writing. A direct RGB connection from a console to one of these monitors should produce a picture as glorious as the aforementioned PC-VGA-to-240p-31-kHz setup, only without the hassles of modelines, hacked drivers, etc. Unfortunately, I don't have such a monitor, so I can't share any pictures :(

In the cases of either the 31 kHz or broadcast monitors, I personally find the image to be a bit sterile and actually prefer the 15 kHz option. I have opted to use the S-video-out on my video card for the convenience it provides, and the quality degradation is only about as bad as choosing bilinear vs nearest neighbor scaling in an emulator (i.e., fine for me, unbearable for perfectionists and pixel-lovers).

UPDATE (4/13/2015): I recently picked up a PVM 20M2U 20" monitor and posted some closeup shots on this page. The picture is indeed awesome and actually sits somewhere between regular SD/CGA displays and high-res 31 kHz monitors in "sterility" and how crisp the scanlines render.

Anyway, here are some more PC-VGA-to-240p-31-kHz pics :D



Good detail shot of the scanlines and the black gaps visible between.
This is what happens to SNES pseudo-hires transparency (bsnes) for some reason :/








Some other considerations that I will add to this post soon: CRTs for 480p and higher consoles (PS2, Dreamcast, 360, etc.), 31 kHz at 1024x768 (shaders vs the real thing), I plan to add a decision-making flowchart with approximate costs at some point, as well.

Analytics Tracking Footer