Saturday, August 1, 2015

NEC XM29 Plus Broadcast Monitor

I lucked into another broadcast monitor recently, this time the "holy grail" of retro gaming monitors, NEC's XM29 Plus. I won't rehash a whole bunch of info that's available elsewhere, but I will provide some answers to questions I had as I started using it:

Unlike the Sony PVM series, the XM29 Plus has no support for component inputs, but it supports almost everything else (Svideo, composite, RGBHV, VGA). You can get a YPbPr-to-VGA transcoder, like this thing, but most of them (including that one) don't support resolutions below 640x480, so they're not good for PS1 (which frequently jumps between 480i and "240p"), non-progressive PS2 games (admittedly, the vast majority of PS2 games are 480p-capable), or "240p"/doublestrike emulation via Wii homebrew, etc.

That said, I don't think component is a particularly useful on the XM29, which is a shame because that's what I had settled on for use with my PVM. Instead, it seems best to stick with RGB SCART, which is easily converted to RGBHV, as the XM29 has two of those inputs available. You will need a sync cleaner, though, so either get a sync strike or get a cable with a sync cleaner built-in, like this one.

There's a lot of uncertainty online about which resolutions work over SCART but I can answer definitively: 480p over RGB SCART totally works fine.

Other than that, there's not much else to say. Low-res non-interlaced content has extremely sharp scanlines with thick, black spaces between them, which some people don't care for. Likewise, interlaced content bobs very visibly when sitting close to the screen. Slight geometry issues are also apparently common on these monitors, and mine's no exception. However, it still looks great and many of the imperfections can be hidden with a teensy bit of overscan.

Here are some shots (click to embiggen):
240 noninterlaced full frame TATE
240 noninterlaced closeup TATE

Thursday, June 25, 2015

Latency Testing

My student worker, Alex, borrowed a digital oscilloscope and photoresistor from a coworker of mine and we sat down at my workstation to collect some data in an area that's often discussed (vociferously!) but rarely actually tested: latency. Most latency testing is unscientific voodoo ("I can *feel* it") that also suffers from confused terminology (see: the fighting game community's complaints about "lag" and how it makes them drop their combos). In this case, we're specifically examining input latency; that is, the difference in time between pressing a button on the controller and the action taking effect on the screen.

Here's a picture of our test bench, which consisted of a button from my trusty Happ-modded Mad Catz SE wired into the aforementioned oscilloscope:
The input from the button is compared against the voltage running through the photoresistor attached to a battery (and a momentary switch to keep the resistor from just draining the battery):
The photoresistor gets placed against my computer monitor while the button is used to make things happen in the emulators. As the brightness changes underneath the photoresistor, the resistance also changes changes, and the oscilloscope displays the difference in time between the voltage drop in the button and the change in voltage from the resistor/battery circuit, which looks something like this:
We only had the equipment for a day, so I couldn't test as much as I would have liked, but I tried to be as consistent as possible. To that end, we sampled 5 data points for each variable and did all of the testing on the same machine. All SNES comparisons used the Super Famicom Controller Test  ROM, while the arcade comparisons used Espgaluda from Cave (in hindsight, probably not the best choice, but it's what I had on-hand). I also didn't have a good way of getting a baseline latency--I'm using a modern, crappy Dell LCD setup rather than a CRT and Windows 7 64-bit, which I chose out of both convenience and the assumption that it would be similar to a typical user's setup--so I was forced to provide data for *total system latency* rather than being able to isolate the latency caused by the individual variables. In attempting to get some sort of baseline, we held up the tester to the built-in gamepad testing applet in Windows, which gave results hovering around 75 ms, which is obviously not accurate, since some of our emulators performed better than that... With that in mind, these results should only be considered relative and not absolute.

Note: my full system info is Intel i7 Sandy Bridge with AMD R7 200 series with all of the GPU control panel crap turned off except for Eyefinity.

Anyway, here are the graphs that illustrate some of the more interesting comparisons:
First off, Aero compositing is bad news for both latency and variance. The increased variance is a real kick in the pants because it makes your performance less predictable. If you want consistent behavior and generally improved latency, stick with a "classic" non-Aero theme. Interestingly, disabling Aero did not seem to help with Higan.
Overall, this graph shows us that exclusive fullscreen is significantly better than windowed for latency, which is expected based on our Aero compositing findings. You'll notice there's no benefit to fullscreen in Higan (it's worse, in fact) because it's not *exclusive* fullscreen. Instead, it's what's known as "windowed" or "borderless" fullscreen. You can also see that ZSNES in exclusive fullscreen is extremely fast; faster than my supposed baseline of 75 ms :O
Higan had the highest latency figures here, even after correcting for the shaders--which I'll talk about more in a sec--with RetroArch about a frame lower (this includes data from both the snes9x and bsnes-compatible cores, which were not significantly different [87 ms vs 92 ms, which is within the variance of USB polling rates]). This also combines both windowed and fullscreen, which hurt ZSNES and ZMZ, the clear winners in exclusive fullscreen mode from our previous graph. Note: when ZSNES and ZMZ went into exclusive fullscreen, they broke Eyefinity, which other testing suggested adds up to ~8ms (or a half-frame) of latency, so keep that in mind when looking at their results.
This one was a dagger in my heart, but I'm posting it here anyway because of SCIENCE. I had always assumed that shaders would never increase latency because, in a worst-case scenario, they would just reduce the framerate (i.e., if the shader takes >16 ms to render). This is obviously not the case, as cgwg's crt-geom increases latency considerably in both Higan and RetroArch, as does crt-lottes. Crt-hyllian, on the other hand, has almost no effect on latency. To explore whether it's just heavy-duty math that causes the latency and whether it's exacerbated by multiple shader passes, I also tested Hyllian's xBR-lvl4-multipass in RetroArch. Shockingly, this one produced lower latency than no shader at all, which I find highly dubious.
I kept this one in here because there's been a contentious debate as to which of these platforms provides the best experience for emulating arcade games. However, there are some serious caveats to keep in mind before drawing too strong of a conclusion: 1.) this used a different test ROM from the SNES emus, 2.) the test ROM I used was selected out of convenience and actually had a lot of potentially confounding noise in the form of enemy bullets passing through my test area, 3.) GroovyMAME and RetroArch are really at their best running in KMS via Linux rather than Win64, so they would likely have more pronounced benefits vs mainline MAME if I could have measured that, and 4.) in initial testing the day before I ran these measurements, mainline MAME performed incredibly badly, with GroovyMAME close behind, which suggests that there may be some other variance involved.

That all said, these data indicate that RetroArch is approximately 1.5 frames slower than GroovyMAME, while the difference between mainline MAME and GroovyMAME is within the variance of USB polling rates. However, in light of the counfounders, I think the strongest conclusion we can draw reliably from the arcade comparison is that RetroArch isn't any *better* in Win64 (i.e., a null finding), so users should go with whichever platform has the features that best suit their needs rather than worrying about slim-to-nonexistent latency differences.


While the testing was not 100% reliable due to multiple confounders in several areas, we can see some trends emerge that can inform our discussions about latency in emulation. Windowed is definitely worse than fullscreen, and enabling Aero compositing is worse than without while also increasing variance and unpredictability. Shaders can actually cause excess latency, sometimes severely so. ZSNES, which has become a bit of a punching bag among SNES emulation scenesters, has outrageously low latency in fullscreen, so if you can stomach the terrible accuracy, there's actually some justification for using it now other than OMGSNOW!1! Alcaro's ZMZ also performed very well and can utilize more accurate emulation cores, so it can be a means to leverage some of ZSNES' latency benefits without being stuck with its poor accuracy.

In the future, I would like repeat these tests with a CRT monitor, which would have a predictable baseline of near 0 ms. I would also like to test latency in other environments, namely Linux+KMS. Finally, it would be very useful to have some comparative figures for original SNES hardware (both via CRT and upscaled via XRGB-Mini) and for RetroArch running via console.

Here is a link to download the raw data in Excel format, in case anyone would like to look at the numbers in more detail and/or perform other comparisons that I didn't think of.

EDIT: I think some people are drawing more conclusions from these data than is really appropriate; specifically, some folks are trying to draw direct comparison between the emulators/frontends tested. These data are simply not extensive enough for that. Furthermore, it's important to keep in mind that I didn't test the quality of sync, which could heavily affect the results. Namely, ZSNES and ZMZ both suffer from frequent audio crackling and frame stutters, which indicate issues with vsync, while RetroArch has none of either. I didn't test RA with vsync disabled (i.e., blocking on audio with video tearing), which could have an effect, and in general gameplay, users need to decide whether improvements in sync are worth minor (potential) increases in relative latency.

Tuesday, April 14, 2015

More CRT Shaders

There have been a number of new CRT shaders written since I last did a big roundup, and some people have asked about it, so here we go! All Cg-format shaders are available in libretro's common-shaders repo on github, while all Quark shaders are available in my github repo. All shots were taken at 4x scale factor, and the closeups are scaled up 400% with nearest-neighbor. Click the thumbnails to embiggen:


I've already written about this one at length, but I figured I'd include it here anyway for reference and comparison. It's the original awesome CRT shader written by cgwg with some help from Themaister and DOLLS[!], and it's still a good choice. It has extensive customization available via code modification and/or RetroArch's runtime shader parameters.
 Many users don't care for the curvature effect and turn it off, like this:
This shader is available in Cg and Quark formats.


This one was written by a fellow from the NeoGAF forums who goes by the name Easymode. It is notable for looking nice even at non-integer scale factors and for being very lightweight considering how nice it looks. It's a good one to try on mobile platforms and desktops/laptops with weaker GPUs. It also has some nice runtime parameters for switching between cgwg-style and Lottes-style mask effects.
This shader is available in Cg format only.


This one is written by Hyllian, who is well-known for his popular upscaling interpolation algorithm known as xBR. It includes some interesting options, such as a "blue boost" that is helpful for making water in many games go from purple to blue.
This shader is available in Cg format only.


This one was written by Timothy Lottes, an engineer at Nvidia who is known for his work creating the FXAA fullscreen antialiasing GPU algorithm. This shader is adapted from the shadertoy he made and was generous enough to release into the public domain. Notably, it uses a sideways shadow mask effect that is designed to avoid chromatic aberration.
 It's easy to flatten this one out, as well, using RetroArch's runtime parameters to set the warpX/warpY values to zero or by commenting line 142 in the Quark shader:
This shader is available in Cg and Quark formats.


This is one I worked on awhile back and it only focuses on doing a phosphor/shadow mask using an external lookup texture (LUT) and a little bit of horizontal blurring.
You can adjust the scale of the phosphor mask with 1.0 looking more like a high-res CRT monitor, while 1.5 and 2.0 look more like an SDTV or CGA monitor. As you adjust the scale, the colors can get wonky, so there are runtime parameters for dialing in the right balance. Here it is at a scale of 1.5:
 There's also a preset for use with 4K displays (not pictured here). This shader is available in Cg and Quark formats.


I've raved about this shader--which was written by aliaspider--before for its ability to blur out dithering, but it also belongs on any list of good CRT shaders. While it doesn't provide any phosphor/shadow mask effects, it does allow horizontal/vertical bandwidth control (for blending things like pseudo transparency and dithering), scanline effects and NTSC color blending/bleeding.
All of these effects are user-customizeable by editing the code (he put the various options right at the tops of the files for easy access) and, with the NTSC color option disabled, it looks remarkably close to the output of Micomsoft's famed XRGB-Mini Framemeister deinterlacing/upscaling device.

This shader is available in Cg and Quark formats.


This shader was written by a guy named TroggleMonkey and it uses some intense, RetroArch-specific black magic to overcome many of the issues with CRT emulation that I thought were unavoidable, particularly using large-scale blurring passes without totally wrecking performance and making a true RGB phosphor / shadow mask that looks good at less than 4K resolution. As I said, it is Cg-only and only works on RetroArch, at that (i.e., no OpenEmu, even though it supports Cg in general).
CRT-Royale has an option (on by default and in these shots) for simulating the characteristic glow of a CRT tube. This is another common goal of CRT shaders, and I've broken those off into their own group:



Written by Themaister, this one eschews phosphor/shadow mask effects and just focuses on using special blurs to accentuate the variable beam width of a CRT (i.e., brighter pixels bleed further into the space between scanlines).
 He also made a variant that tacks on his NTSC-composite shader (looks better in motion):
This shader is available in Cg format only.


Just like regular CRT-Hyllian, but with some whole-screen blur/glow.
This shader is available in Cg format only.


Mr. Lottes made a revision to his scanline shadertoy that added a number of gaussian blur kernels to bloom out bright pixels, which increases the overall brightness of the image without getting the fullscreen haze of some of the other options.
Unfortunately, the limitations of the shadertoy format forced the blurs into a single pass, which is extremely slow. This variant is available in Cg format only.

For anyone who's curious, I took 4K screenshots of most of these, but blogspot down-rezzes them and adds jpeg compression on top of that, so I couldn't post those directly. Instead, here is a download.

Tuesday, March 17, 2015

How to Adjust Focus on Sony PVM Monitor

I just scored a Sony PVM 20m2u monitor the other day and found that the picture was extremely sharp at the edges but slightly soft toward the center, which indicates that it was a bit out of focus. There is no focus setting in the service menu (accessible by pressing the degauss and enter buttons on the front, btw), as it is a physical characteristic that must be adjusted by turning a pot inside the monitor guts, just like on an arcade monitor.

With most(?) arcade monitors, the focus pot is located on the flyback transformer, along with the screen pot that controls the voltage to the electron guns. If you remove the outside case of your PVM and look in from the left (there's a big circuit board thing blocking view from the right), you should see the flyback, which is the big black piece of plastic with wires coming out of it that lead to the neckboard:
There are no easily accessible pots to turn on this flyback, but it is connected to a small white board above and behind it, right against the back panel with all of the inputs (which I did not remove), and that board has our focus pot:
The focus pot, viewed from the back of the monitor
You'll want to turn this pot very slightly while the monitor is running until you have a more uniform sharpness all over. It's nice that they moved it off of the flyback, actually, even though it made it a little harder to track down because it can be scary messing with such a high-voltage component while the monitor is running.

UPDATE (03/20/2015): Someone in the comments asked for shots of it running, so here you go (click thumbnails to embiggen):

These are all extreme closeups, since I figured that's what people are mostly interested in. These were taken with my HTC One m7 with a Playstation 2 hooked up over component cables. The first 2 are Dodonpachi Daioujou in TATE (notice the vertical scanlines), followed by a menu shot, Mega Man X Collection and Street Fighter Anniversary Edition.

As you can see, the scanlines are very crisp and "sterile," though not as much as on a 31 kHz CRT monitor (see the pics at the bottom of this post for comparison). For "240p" non-interlaced content, the PVM sits somewhere between that extreme and a regular SD/CGA TV or monitor, where the gaps between scanlines are almost nonexistent in bright areas.

Wednesday, December 31, 2014

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

Analytics Tracking Footer