Tuesday, August 22, 2017

8bitdo NES30 Arcade Stick Review and Modding Info

I like to play retro games from my couch and I prefer using an arcade stick, but I don't want to have a giant cord stretching across my living room as a tripping hazard. The obvious solution is to get a Bluetooth arcade stick. The only problem: nobody makes them. It seems the people driving the arcade stick market are distrustful of wireless communication due to latency concerns, despite data from a very reputable source suggesting otherwise.

8bitdo had put out a couple of arcade sticks in the past, the FC30 and FC30 Sanwa Edition, but those sticks never got much traction, AFAICT, and they're long-since discontinued now (and I've never seen one come up on eBay). They've revisited the concept recently, though (presumably because their devices are compatible with the Nintendo Switch*, which got a Street Fighter 2 port, and no other company has released an arcade stick for that market), and released their NES30 Arcade stick, which I preordered as soon as I heard about it.

First impressions - Build Quality and Information

The plastic used for the main body of the box feels a little flimsy. It has some flex to it, which isn't encouraging, and there's a lot of empty space inside the stick, though this is actually a good thing when it comes time to start poking around in there. It has a nice, thick, solid metal base with recessed screws and built-in rubber feet, which is a big advantage in my opinion when compared with the flimsy, easily lost rubber feet from the Mad Catz TE and SE sticks (and once the feet were lost, the non-recessed screws would scrape up wooden surfaces and get caught on fabric -_-).

The buttons are knockoff Japanese-style and feel predictably crummy, but passable if you're just going to use it casually. The stick feels pretty decent, really, with none of the gravelly, scraping feelings characteristic of the Mad Catz SE sticks as they slowly ate themselves.

There are 8 full-size (i.e. 30 mm) buttons for A, B, X, Y, R1, L1, R2 and L2 in modern, staggered arcade stick layout, and a smaller button (presumably 24 mm) for Start. There are also smaller non-arcade-style buttons on the control panel for Select, Pair and Turbo. While Select is bindable in gaming software, the Turbo and Pair buttons are not exposed, leaving users with 10 buttons and a 4-way joystick. That is, there is no dedicated "home" button for assigning to "menu_toggle" in RetroArch/MAME.

Wireless connectivity over Bluetooth is quick and painless, and there's no obvious perceptible latency. If you want to play wired and/or charge the stick, 8bitdo has supplied a full-size USB-A-to-A cable, which is, frankly, bizarre. 

Modding

The metal base is held onto the box by 6 small phillips-head screws. Once those are removed, you can pop the base off safely. That is, there is nothing attached to the base that can get yanked out, etc. Once inside, you can see that the wiring is clean and organized, with color-coded wires leading to plastic pin-headers on the board. You can also see the support structure (the hollow tubes surrounding the buttons), which provides a strong backbone where the stick will be seeing the most abuse.
A shot of the insides before I got started on it.
The good news: swapping out the buttons on this stick is a breeze. The stock buttons snap right out and the .110 quick-disconnects transfer over to Sanwa buttons, which are a perfect fit (I swapped in Sanwa 30 mm OBSFS buttons), with no trouble. The stick also has mounting screws that line up perfectly with a Sanwa JLF stick.

The bad news: THIS IS NOT A COMMON-GROUND PCB. That's not a big deal with the buttons (unless you just really like to daisy-chain grounds for tidiness), but it's a very big problem for the stick, since Sanwa and Seimitsu sticks use a common-ground PCB for their switches. In short, this stick is INCOMPATIBLE with Japanese-style sticks without doing some significant modification.

Speaking of the stick, it has a clip-in square restrictor plate/gate and has the control wires soldered directly to Lema microswitches, from Chinese company Zhejiang Lema Electrics Co. Ltd:
Since they were directly soldered, I needed to cut the wires, making this the first destructive modification so far.

The Lema switches are pretty close in size and shape to the tough-as-nails Cherry microswitches you would find in Happ/IL sticks and buttons, and I decided to swap them out for some I had in an old Happ Competition joystick.
The result is satisfyingly clicky and extremely light (that is, there's barely enough resistance to bring the stick back to center; some people will despise this). I was able to pull off 360/720-degree motions easily and reliably, but I'm not 100% convinced that I want to stick with this setup permanently, so I used insulated alligator clips rather than soldering .187 quick-disconnects to the wires in case I decide to swap it out with other switches in the future.
The extra-roomy case came in handy here for holding my insulated alligator clips
The restrictor plate/gate is held in by 4 little screws and 4 clips. Once the screws are out, the clips are nice and easy to manipulate, unlike the ones on JLF sticks, which are notoriously difficult to work with. I didn't check to see whether Sanwa plates would snap in, but it looks pretty likely. I might swap in an octo-gate at some point and will update this post if I run into any issues. Here you can see the Cherry microswitches fit in nice and snug under the stock plate:
I didn't get around to testing it, but I suspect the longer, screw-down Happ/IL American-style buttons would fit just fine in the case, since it seems to be a little taller than the Mad Catz SE boxes, which were only about a quarter of an inch too short to fit them comfortably.

*Note, the wired vs wireless issue seems to actually be in favor of wireless on the Switch, oddly enough: https://www.youtube.com/watch?v=avvmck40cIw

Friday, July 7, 2017

RetroArch shaders ported to ReShade

I've frequently gotten requests to port RetroArch's library of shaders to ReShade's format for use with other programs/games, but I'm a Linux guy for the most part, so I never had the inclination to do such a thing. Thankfully, ReShade user Matsilagi is/was so inclined and he ported a bunch of them and made them available in this github repo:

I haven't tested all of them, but the ones I've seen look perfect, so they should be ready to go with all of the low-fi CRT/NTSC/PAL goodness.
Artifact Colors
CRT-Geom and CRT-Lottes
PAL
NTSC
R57-PAL
3DFX
GTU-v50
EGA Filter


Thursday, June 22, 2017

RetroArch Tone-mapping LUT Shader

Reshade has long had a shader, LUT.fx, that enables users/designers to do tonemapping and other color adjustments without touching any code. Instead, they can do all of their adjustments in an image editing program, such as Photoshop or GIMP, which many people are familiar with already. While my image-adjustment and color-mangler shaders can be used to accomplish those same tasks (Pokefan531 did a great job modifying them to produce his handheld color shaders, after all), they're awkward to work with, since an artist has to make all of his/her changes by twiddling esoteric values in the shader settings menu.

So, I decided to port the Reshade shader to RetroArch so our users could get in on the fun. I ran into some unexpected behavior with the direct port, though, and decided to adapt another similar shader instead. This one ended up having the same weird issue, which I think is related to undefined behavior, but I put a stupid workaround in the shader to mostly deal with it.

Anyway, here's how you use it:

First, take a screenshot that you want to use as your reference (I'm going to use the Sonic the Hedgehog title screen) and then take one of the passthrough palette textures that come with the shader (they're the png files located in reshade/shaders/LUT, named for their color depth). Then, in Photoshop or GIMP or Paint.NET or whatever, open your reference screenshot and paste the palette image down below it:
I find the easiest way to do this is to go to the image menu > canvas size and then anchor it from the top and increase the canvas Y-axis measurement by the height of the palette texture (in my example, I'm using the '16' texture, so I made the image 16 px taller). Paste the palette image in there, move it to the bottom-left corner and then merge the palette layer with the screenshot layer.

Next, do whatever it is you need to do to make the picture look like you want it. That includes brightness/contrast, hue/saturation, indexed color, different lossy colorspace conversions (such as by switching to CMYK colorspace and then back to RGB). I'm going to do a simple hue shift in my example because it's easy to spot:
Once you have it all set, we need to isolate the palette from the screenshot. I think the easiest way to do this is to go back to image > canvas size, anchor from the bottom left and enter the size of the palette (the width of the passthrough palettes is the height squared; I used the 16-bit palette, so it's 16 * 16 = 256 px). Save that image under a new name (I called mine 'hedgehog-palette.png'; if you're using a different palette depth from the default 16, it's probably a good idea to put that into the filename somewhere so you don't forget it) and then drop it into your reshade/shaders/LUT directory with the other palette images.

Now, open the LUT shader preset (cgp/glslp/slangp file) in a text editor and change the line that points to the palette (probably line 7, but YMMV):
SamplerLUT = shaders/LUT/16.png
becomes
SamplerLUT = shaders/LUT/hedgehog-palette.png
Save and exit and then fire up RetroArch, load a core and some content and then load up the shader. It should apply those same color transformations to the game image, like so:
If you used a different bit-depth palette from the default 16, your colors may look crazy and messed up at first, in which case you need to go back into the quick menu > preview shader changes and then change the "LUT Size" runtime parameter to match.

This shader is available from the online updater and/or git in GLSL, Cg and slang shader formats.

Monday, June 19, 2017

RetroArch shaders on Shovel Knight

I recently played through the awesome retro-styled platformer Shovel Knight for the first time and, while the pixel art is incredible, I kept thinking "I bet this would look even more amazing on a CRT." The game runs at a higher resolution on PC, so getting the low-res scanline-y look I crave wouldn't really be possible (or at least would be a significant hassle) through a 31 khz PC monitor. However, thanks to j_selby's out-of-the-blue Citra-libretro core, we can now run 3DS games via RetroArch--including Shovel Knight--and apply all sorts of fun shaders to the output!

Here are a couple of shots (click to embiggen):
The old favorite, cgwg's CRT-Geom
xBR-lvl2

artifact-colors; horizontal scaling is a little wonky

crtglow-gaussian

ntsc-320px-gaussian-scanlines

Thursday, June 1, 2017

New NTSC Shaders

NTSC simulation/emulation is a tough nut to crack. There's a lot of math involved, and the results are very dependent on games/content having the correct resolution or else the effect falls apart. Themaister's NTSC shader does a fantastic job with both 256- and 320-pixel-wide content, which covers most modern-ish retro consoles, including S/NES, Genesis, PS1 and N64, and it handles content of arbitrary resolutions pretty well. Nevertheless, it's always good to have variety, so I was excited to find some other shaders that included different takes on the NTSC signal problem.

Artifact Colors

This shader is based on Flyguy's awesome "Apple II-Like Artifact Colors" shadertoy and is the most impressive/magical of the shaders I'm going to cover here. Where this shader excels is in reproducing the NTSC "artifact colors" that certain old computers depended on before full-color interfaces were a thing. You can find some great explanations of the phenomenon at the 8088 mph demo writeup and this post at nerdlypleasures.

This splitscreen image demonstrates just how mind-boggling this effect can be, taking a 1-bit black and white image and ending up with bright colors:
RGB output on the left, composite artifact output on the right. Those colors are all generated by the signal modulation :O
And here's an animated gif that cycles between the typical limited-palette RGB output and the full-color artifact-color version (half RGB and half composite artifact back and forth):
Notice how the magenta and black stripes turn to a rich brown
In porting this shader, I tried to make runtime parameters out of as many variables as possible because it's such a cool thing to see how they affect the emergent colors in real-time. One such parameter is the F_COL variable, which can be used to basically have another color palette that you can switch to.

I also made a preset that pairs it with T. Lottes' CRT shader, which is perfectly suited to CGA content:
I called this one c64-monitor in the 'presets' subdirectory of the shader repos
I made the presets force a 640-pixel width, since that seems to be the sweet spot for this shader, which isn't surprising seeing as many of the games that relied on artifact coloring used a 640x200 mode. I'm not very familiar with any of the classic computer cores that could take advantage of this shader, but I'd love to hear comments from anyone who gives them a shot.

This preset also looks pretty darn good for general use, though it does a strange green/magenta strobe thing on Sonic's waterfalls and probably other pseudo-transparency:

CRTSim

This one from J. Kyle Pittman / PirateHearts is similar to the CRT effect in You Have To Win the Game:
It doesn't try to be accurate, it just looks nice and runs fast. While it does the whole bevy of old TV effects, including a really nice per-channel color persistence that can be used to reproduce the characteristic red smear of a failing CRT, my favorite part of it is the LUT-based NTSC effect. It uses a simple texture of diagonal colored lines:
This looks gray, but it's actually red, green and blue diagonal lines
and mixes it in with the main image based on differences in brightness between each pixel and its neighbors. For such a simple concept, the result is very convincing, and it even does a reasonable job of "passing" the NTSC crosstalk test-ROM (with certain settings):
Also of interest with this shader is the choice of permissive public domain licensing, so people can integrate it into their games and other programs without fear of licensing conflicts.

Both of these shaders are available in RetroArch's regular GLSL and slang/Vulkan formats. Artifact Colors is also available in RetroArch's Cg format and for ReShade, courtesy of user Matsilagi, who has also ported a number of other RetroArch shaders to ReShade. On-topic but not pictured are two NTSC shaders derived from MAME's NTSC shader implementation, one multipass and one single-pass. I haven't gotten them to work properly in GLSL format, only slang, and all of my Vulkan screenshots have their red and blue channels swapped for some reason right now, so I couldn't share any shots of them. You can get a taste from their shadertoy implementation, though.

Wednesday, April 5, 2017

Upscaling shaders for pre-rendered backgrounds

In the Playstation 1 / Nintendo 64 era, it was a common practice to pair low-poly 3D models with prerendered photo-realistic 2D backgrounds to give the illusion of a fully 3D-rendered game. This technique was used extensively in the Resident Evil series and Squaresoft RPGs (Final Fantasy 7, 8 and 9 and Chrono Cross), and when we emulate those games, we run into some issues related to the background.

If we use an emulator that supports increased internal resolution, the 3D polygon elements look sharp and crispy but the prerendered scenes are super-pixelated, and the contrast between the two can be jarring and distracting:
An unsettling juxtaposition.
To avoid that, you can stick to the native resolution and let everything look consistently pixelated and then use a full-screen post-processing shader remove some of the rough edges. Unfortunately, many of the algorithms we use for upscaling representational, cartoony pixel art don't always do a good job with the prerendered scenes, as the subtle gradients and natural, random dithering can trip up the pixel comparison and pattern detection methods that work so well in other applications:
Only a few pixels get smoothed; most are skipped
There are some good upscaling algorithms that are designed to deal with this sort of application, though, and we'll take a look at some of the ones available in shader form. We'll be comparing 4x upscales from two native-res captures from Final Fantasy 7:


ScaleFX-Hybrid

Sp00kyFox's scaleFX algorithm does a stellar job on cartoony stuff, and he tweaked the algorithm a bit to better handle small details. It has a rough, stipple texture on edges, unlike the regular version, and maintains details that the regular version smooths away:

It also handles gradients better than the regular scalefx, with reduced posterization.

NNEDI3

This algorithm, which utilizes a "predictor neural network architecture and local neighborhood pre-processing" (whatever that means), was recently ported to RetroArch's slang shader format by a fellow that goes by the name ZironZ. He hardcoded the huge swaths of weights derived from the neural network into the shader passes, which makes for relatively long compile times but respectable speeds once the task is done. He provides a handful of presets, some of which are much too demanding for my modest GPUs, but the basic preset runs in real-time and looks very nice:

This algorithm compares well with the popular waifu2x algorithm, which is also neural net-based but cannot run anywhere close to real-time (these shots are using the 'photo' preset with 'medium' denoising):
waifu2x, photo, medium denoise; no shader form available

waifu2x, photo, medium denoise; no shader form available
While all upscalers have a "signature" in the way their output looks (characteristic swirls or burrs on objects, etc.), much of waifu2x's magic mojo comes from its denoising routine, which gives images a surreal, painterly look when maxed out:
waifu2x, photo, max denoise; no shader form available
waifu2x, photo, max denoise; no shader form available

We can't reproduce that look exactly with real-time shaders, but we can get closer by adding a pre-pass of bilateral blur, which denoises the image by blending neighboring pixels that are close in color/intensity.

Fast-bilateral-NEDI

This combines Xin Li et al's NEDI algorithm (not to be confused with the aforementioned NNEDI3 from tritical) with a fast-bilateral pre-pass to get some of that smooth, surreal look at the cost of lost detail:

The fast-bilateral shader includes a runtime parameter to control the strength of the blending, and I modified it to go all the way up to 2.0 (default value is 0.4 with a max of 1.0), which looks nice but nearly wipes out the tile mosaic:

Fast-bilateral-super-xBR

Hyllian's xBR algorithm is now legendary in emulation circles for its ability to upscale pixel art, and the super-xBR variant is tuned to handle images and photos. The pre-pass of fast-bilateral cleans up some of the images' own built-in noise:

Again, cranking up the bilateral-blur to to 2.0 has an interesting if not useful effect:
And, just for fun/comparison, here's what waifu2x looks like in "artwork" mode (that is, a mode that throws away even more detail) with the denoising at maximum:
waifu2x, artwork, max denoise; no shader available
waifu2x, artwork, max denoise; no shader available
Hyllian's 3D detection shaders

Another alternative strategy involves using an initial shader pass to identify which elements are upscaled 3D models vs which ones are 2D textures. This lets the shader work on HUD elements and backgrounds without getting thrown off by the increased internal resolution:
super-2xbr-3d-6p-smoother (I think) 
jinc2-sharper-3d (I think)

Analytics Tracking Footer