Blog Posts on PatchSalts.com

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

Introducing Desktop Scrollery

Tue, 15 Sep 2026 14:21:40 -0400

Hello again! Today I’d like to introduce Desktop Scrollery. You can scatter papers all over a physical desktop and shift your gaze to whichever one you want to read. You can try to do this on a computer’s virtual desktop, but you’ll find it’s rather easy to run out of space. Your screen is usually not big enough. I’ve always thought it might be fun to try and complete the skeuomorphism. I’m building a tool that allows you to scroll your windows across your computer’s virtual desktop space to give the sense of moving spatially between windows rather than constantly alt-tabbing to raise windows over currently visible ones. Please note that I’m developing it as a KWin script, meaning it’s only available for KDE Plasma users (so as far as I know, no Mac/Windows support, sorry). Currently, the plan is to slide windows over when your mouse cursor touches the edges of the screen. Here’s a demo of the current functionality.

Your browser doesn't support HTML5 video. Here is a link to the video instead.

… As you may be able to see, it’s kinda iffy right now. The windows are supposed to slide over in both axes, not resize only vertically. I’m not comfortable putting it in the main branch yet, so to test drive it yourself you’d have to use the basic-functionality branch. You can check it out on the GitHub repository.

A little history on the development process

This is an idea I’ve had for a very long time. I’ve even tried to implement it before, but I ran into some issues between the gap in the documentation and my current knowledge on the subject.

There are some documentation pages for KWin scripting available, but every time I read them I feel like I’m missing something. For example, there’s an official “KWin scripting tutorial” page, and it provides plenty of useful info, but also omits plenty of crucial info. It describes how a KWin script project is packaged using the KPackage format, but it doesn’t actually describe how to package your script, and the KPackage link they provide doesn’t explain either, instead seeming to cover building KPackage save/load support into full-blown desktop programs. My confusion every time I opened the docs is a huge reason the project has never made it out of the ideation phase before.

This time I decided to just get something done, no matter what it takes me to do it. I went in search of some external examples and resources, and I found an example script to inspire me, Sticky Window Snapping by FLUPP. It’s really easy to follow along if I see how someone else did it. It turns out the package format is really just zipping your project and changing the extension from .zip to .kwinscript. Unbelievable… Brilliant… Look, I understand that this kind of information is probably in the docs somewhere, but when the page is titled “KWin scripting tutorial” I feel like including that information directly on the page would be pretty helpful. Perhaps I should figure out how to contribute to the page just to fix it so the project benefits from my confusion.

Being a sore loser aside, I have been able to test that my project is somewhat functional, so that’s pretty neat. I’m finding myself dreading opening it to continue working on it… This is the furthest I’ve ever gotten with the project, so I think I’m gonna take a rest on it for now and switch to a different project before I burn out too much.

Personal stuff since my last post

Touhou 6’s remaster and rebuild being available on Steam has been a total blast, I didn’t quite realize how much I missed playing these games. For the unaware (most of my audience haha), the Touhou Project is a series of Japanese bullet hell games that draw heavy inspiration from classic arcade shooters like Galaga, 1942, DoDonPachi, etc. The player dodges waves of enemy fire while progressing through the (cheesy) plot. Completing a full playthrough only takes around 30 minutes. They’re difficult, but the difficulty is secondary to the weird and classic vibes. I’m really grateful for a way to easily run the game again, it’s a bit tricky to get the old version running nicely on modern computer systems.

I watched Coyote vs. ACME last weekend with some friends, it was a blast. I didn’t really grow up watching much Looney Tunes, but I had a basic level of familiarity. There were several jokes that I didn’t really understand but they were few and far between. The basic pacing of the humor was extremely pleasant and engaging.

I’m excited for the new changes being brought into Overwatch soon, Doctrine looks like a super fun character and I’m excited for the day he’ll be added to the game in full.

Apparently I’m super susceptible to pressure fluctuations. I was feeling totally crummy yesterday, waking up with a headache and fatigue, which stayed with me all day. Checking the air quality monitor revealed that from the 19th to the 21st, the air pressure went from 1011 hPa to 1001 hPa and back up to 1011 hPa. Yippee. I guess it’s a relief to know that something did this to me rather than some sort of mysterious wind.

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

– Patch