October 2026 Brief Update

Tue, 13 Oct 2026 13:51:24 -0400

Hey everyone, just thought I’d give a brief update. Around the same time I started working on the retro shader stuff, I started getting full-day headaches every day. It’s been about 2 weeks of this and it’s made most tasks somewhat difficult. I had to take it easy and try to micro-manage my health since relatively few things would make it better and many things would make it worse. Today has been the first day in a while my brain has felt kinda normal since the headaches started.

Despite that, I’m still intent on working on shader stuff if possible, since it has been fun. I’d like to be able to use mGBA to emulate Super Game Boy games as if I was playing them on a CRT screen. You see, the Super Game Boy is a Super Nintendo add-on that allowed gamers to play their Game Boy games oon their SNES, with a couple of features (like specialized palettes and borders) added. I have the analog video filter for it basically ported over (it’s Themaister’s NTSC-256px-Composite shader), but there’s a few small problems.

mGBA always renders shader passes to an integer framebuffer

The shader I’m porting uses 2 passes. The first basically processes input RGB pixels and renders the corresponding analog signal values to a cache, and the second pass reads the cache, does some more processing to simulate the analog signal characteristics, and renders the result back into RGB pixels. When the first pass is rendered to an integer framebuffer, some information is lost, and the output pixels look very magenta-ish instead of their intended colors.
mGBA doesn’t pass information about frame count/time to shaders

The shader I’m porting uses information about the number of frames being rendered to simulate signal jitter. mGBA currently doesn’t pass any of that info to its shaders, so this effect can’t be simulated yet.
mGBA doesn’t have any aspect ratio correction features

As stated in my last post, video output from older consoles like the SNES were almost always stretched horizontally a little bit, but currently mGBA provides no way to simulate this characteristic… after all it’s technically not an SNES emulator, it’s a Game Boy (Color/Advance) emulator. (Although I remember reading that sometimes a bit of SNES emulation is needed to get the SGB features working, so the lines are blurred there.)

I’m currently doing work on the first point, and I plan on submitting a pull request to get the feature implemented in mainstream mGBA. After that, I’ll also work on the next 2 points. I expect the next few posts might still be focusing on that for a while :P

It is important to remember that while there is no right way to play an older game these days, I simply don’t want everyone to forget what the original look and feel was. “Sonic was an ugly game because the checkerboard patterns hurt my eyes” shouldn’t be the takeaway people have after playing it on a modern system, ignorant that you probably weren’t supposed to be seeing the checkerboard patterns at all (again, see the previous blog post for info about the blending of dithered patterns). I would prefer to simulate the full SNES experience when playing a game in SGB mode, and I’d like to enable that experience for myself and others, but the lines are especially blurred in this case since those are technically still Game Boy games. I wouldn’t blame anyone for playing games in SGB mode with no video filters or correction at all, since it could be argued that they simply want to play the Game Boy game and the added features are just a nice bonus.

Thank you so much for reading, have a nice day.

– Patch

Retro shaders are important

Fri, 02 Oct 2026 15:13:50 -0400

This week is a bit of a brief update. I do have something to show y’all but I spent most of the week learning about shader development for emulators, so please accept my humble ramblings for a while before I show you what I actually did.

One thing I’ve always loved about video games is the flexibility with which we can enjoy them. The older of us may remember going to arcades and popping quarters to enjoy a bit of cheap fun. Gaming has (obviously) exploded since then, to the point where we can now form communities on the internet around enjoying games without even playing them. It’s even gone full-circle. Arcades seem to be making a bit of a resurgence in my area, with some tweaks to the classic business model. But one big downside to the modernization of gaming is that we can start to lose elements that defined older games.

What I mean is, as we phase out older technology in favor of newer tech, we lose the details that the older tech held. Older tech may have been janky, but it was great until improvements came around, and their jankiness defined how people enjoyed them. The only way to experience exactly what that was like back in the day would be to actually be back in the day with no knowledge of the future… but since that’s impossible, it can be fun to aim to get as close as possible.

One obvious example of the gap between old and new is display tech. This topic has sorta been beaten to death in the last couple of years, and I’m glad it has because that’s how I learned about it. Consoles from the ’80s and ’90s (and for a little bit beyond) were typically played on CRT televisions, which had certain visual qualities. These qualities were often taken into account when the games were being designed. The most well-known example of this is that NES developers knew that despite internally using “square” tiles, their games’ video output would be stretched out a little bit horizontally, so sometimes the graphics were intentionally created a bit narrow to account for this. Check out the intro sequence from Kirby’s Adventure; Kirby is supposed to be spherical, so the first image doesn’t make sense.

This concept is famous enough that most retro game re-releases include aspect ratio correction to replicate this effect, which is fantastic to see.

But a slightly lesser-known artistic concept is dithering and blending. Game designers knew that when the console pushed the analog video signal to the CRT screen, the pixels would blend and smear a bit. This inevitability seems terrible at first glance, but limitations are often the cause of artistic innovation. Artists realized that even though the console might not have supported semi-transparency, they could take advantage of the blending to create the desired effect anyway. Sonic the Hedgehog has many examples of checkerboard or stripe patters (called dithering) throughout the game, which blur together and render as semi-transparency.

These screenshots are both taken from an emulator on a modern computer, but the second picture has a digital filter over it (or “shader” as they’re often called) that attempts to replicate the analog video signal and the CRT display. If you pay close attention, you can see that the shield over Sonic looks a lot more bubble-like and see-through. A bonus is that some of the background elements in the first image look chunky, but they’re rounded out quite a bit in the second image.

As emulation took off in the 2000s, many young gamers took it as an opportunity to play games they couldn’t quite catch when they were popular. But without shaders recreating the intended look of the games, they missed out on a big part of the experience of what playing the game is supposed to be like. Filters are almost never enabled on emulators by default, and quite often the ones with advanced effects are computationally demanding, so the internet became flooded with screenshots from old games that don’t look at all like how they actually looked on the original console.

Times are changing though. With more people able to access computers with higher specs, the use of these shaders is growing in popularity.

Porting shaders to mGBA

With that all said and done, the thing I’ve been working on is simply porting a few of my favorite shaders to mGBA, a Game Boy series emulator. So far I’ve only finished Sharp-Shimmerless… it’s a simpler shader that doesn’t do nearly as much as analog signal and CRT simulation, but it still has a desirable effect. It’s more intended for games that were displayed on digital screens, but it doesn’t really matter what you use it on. It’s basically designed to be a middle-ground between (bi-)linear filtering and nearest-neighbor filtering. Take a look at these mock-ups I threw together in an image editor.

There may be some rough coloration errors, since I couldn’t simply run the source image through the desired filters, but this should be sufficient to get my point across. Here, I’ve upscaled a 2×2 checkerboard pattern to be 5×5. “Nearest neighbor” filtering simply chooses to replicate the closest input pixel, but this can leave weird issues at non-integer ratios (like this 2.5×) where some rows/columns appear wider than others, which can cause shimmering issues when the input image scrolls across the screen. “Linear(-ish)” filtering attempts to blend between the input pixels, but it can cause a blurry look. “Sharp-Shimmerless” attempts to mix the 2, where it only blends input pixels when the output pixel straddles a border between input pixels.

This is absolutely a matter of preference, but when it comes to games for LCD screens, I prefer something like Sharp-Shimmerless to preserve the intended blockiness while also avoiding the shimmer, since I can sometimes notice the unevenness at a distance, taking me out of the game a little bit. Here’s an example from Mario Kart: Super Circuit for the Game Boy Advance. You may have to zoom in to see the difference. It’s not much, but it is there.

Sharp-Shimmerless wasn’t available for mGBA, so I decided to learn a bit and port it from libretro’s slang shader format to mGBA’s format. It was both very easy and very difficult. I’ve never had to give serious thought when handling shaders before, so there was a lot to figure out, since the files aren’t directly compatible. Maybe I’m missing something, but I couldn’t find direct answers to questions that arose during development (this is becoming a common theme around here).

I ended up finding most of my answers in other shaders that were available in both mGBA and libretro, or the mGBA source code, digging in to find keywords used in the files, and then snooping around to find related keywords and resources. I struggled to understand some parts of it, so I also ended up making a sort of mockup in Google Sheets to figure out the internal workings of the shader.

… It turned out that the language between the 2 formats is almost identical, and a lot of my problems were simply caused by trying to use a variable that didn’t exist. The latest version of mGBA is v0.10.5, but outputSize wasn’t available in that version. Simply switching to a development build fixed almost all my problems. I wasted a lot of time figuring that out. Oh my. …

I posted the code up on my GitHub if you wanna check it out.

Thank you so much for reading, have a nice day.

– Patch

Emulators on PatchSalts.com

October 2026 Brief Update

Retro shaders are important

Porting shaders to mGBA