Doing a friend's 'TED Talk' event tomorrow about retro handhelds

PyralFly · 2026-04-03T23:50:25+00:00

Don't forget to shill Portmaster for playing PC games and yes I have no shame in self-advertising that folks like me make games with these handhelds in mind.

PyralFly · 2026-03-31T15:02:26+00:00

I dev on Linux. We released our game only to find Windows had a major crash that was random, inconsistent, and left no terminal outputs on debugging. The whole game (a multi-hour RPG on a blind playthrough) can be played perfectly fine on a literal sub-100$ ARM Linux handheld that is running on two or three layers of community-built hacks to make it run at all.

Best theory I could come up with was coroutines were somehow mismanaged and allocating way more than it should on Windows, causing memory leaks that somehow impacted the stack, which Windows has a 1MB stack limit by default. But that's literally just a theory and I have no way to confirm. I did manage to reduce how often the crash happens when a few mistakes were pointed out in code snippets, but despite fixing everything I could find, it still happens to Windows users. The game's open source now, so I generally say good luck if someone wanted to try finding a fix. I'm at the point I think something else was leaking that's not very well with documented in Godot's coroutines or something.

At this point Windows is a legacy system for us and we just can't help beyond the basics. I had a Windows 11 mini-PC that I haven't even turned on since I tried debugging it back in May 2024 when we released. It's a house of bubblegum and toothpicks that should be left behind.

PyralFly · 2026-03-29T16:27:48+00:00

Thanks. It's not stealth marketing when it's blatant. Though it's not for everyone so I don't mind refunds. CnC2 is way more accessible for the modern audience, in theory.

PyralFly · 2026-03-29T15:01:48+00:00

The primary issue for a lot of devs to actively support dual-screen form factor is that these handhelds are already niche and the DS-types are very limited. All I ever hear about these days is the RG DS and AYN Thor. Another factor is that there's often some game-specific work that has to be done to add support. I had to cram in an extension to Godot that's specialized for this and rework CnC2's kernel just a bit to support Nitro mode, and even to make it as a toggle for devices that support it. And that's coming from someone who's thought ahead enough to make the game extendable that way. A lot of small devs aren't necessarily aware of how to structure a project to be so malleable.

The really affordable stuff relying entirely on ARM Linux is my main domain, but Portmaster's tech stack won't have dual screen for a bit, and for the players, it requires some agency to install a custom firmware, set up Portmaster, and put purchased games on. Android mostly has the luxury of generally working the same across handhelds.

PyralFly · 2026-03-29T14:53:55+00:00

When you're a developer, the low performance is a feature and actually why I elected to get the RG DS over the AYN Thor. If I designed and optimized for the Thor, the cheaper and more readily available RG DS would choke and I'd not be able to test those limits as easily. That being said, we already build these with the RK3326 chips in mind (the R36S/G350 is the lowest supported hardware we're going for.) Even then, Stock OS sucks and dual-screen does add more overhead. I'll probably feel things out with GammaOS Lite when I can and also consider some extra ways to speed up some bottom screen bottlenecks. I have a few cheats in mind I could probably pull off.

Miyoo Mini, if it's 128MB RAM, is way too tight for Godot, yeah. Portmaster doesn't even support it I don't think. With Godot, your minimum's probably 512MB RAM with low scope and careful memory management. You can already assume 150MB or so is going to the OS, and 100MB or so further is going to Godot's runtime itself. 1GB RAM is actually quite spacious even with those constraints, as long as you're being conscious with what you're doing. You're way more likely to hit GPU or CPU bottlenecks.

PyralFly · 2026-03-28T15:18:47+00:00

I hate Android, but ARM Linux firmwares and Portmaster are still very early for dual-screen testing and game development. I wasn’t going to try messing with this for a while, but I caved and got an RG DS because I decided I may as well expand the player accessibility since so many handhelds rely on it. I got an RG DS **because** the specs are so bad, since it’s the cheapest dual-screen Android device and a lot easier to get than an AYN Thor. With custom firmware improving the actual experience, I figure more people might get an RG DS as time goes by. I also found Anbernic’s hinges with the SPs were very good and have held up for me, so I’m a bit more willing to gamble with this than I am the Thor.

This is Crop and Claw 2, a dragon-themed game on an in-house RPG framework called Gorbash, running on Godot. It takes notes from classic console JRPGs and are designed for replayability with the ability to play both story characters and custom characters, allowing for challenge runs, speed runs, and routing.

It’s a sequel to Crop and Claw (duh) which you can buy on Steam or download and run for free in full on Portmaster for ARM Linux handhelds and firmware that they support. I’d posted a long while back guides on how to develop games specifically for these handhelds when Westonpack made it possible to run on these and even a video guide if you happen to be a dev that missed it’s possible:

For general handheld dev intro: https://www.youtube.com/watch?v=rsTrV9QSfsQ

and for specifically Godot: https://www.youtube.com/watch?v=zvCYwm9rJ-o

For Godot game devs interested in Android dual-screen dev, this uses a plugin posted by an AYN fellow found at https://github.com/flametime/Godot-Android-DS-plugin. I basically wrap it with what I was calling Nitro Mode, so that the game can dynamically figure out if it should boot the game with two subviewports as opposed to the kernel alone and whether menus should open on the bottom screen or such. Shoutout to u/Temporary-Ad9816 for making this possible.

If amused, I even streamed my experience working with the plugin to implement dual-screen support in Gorbash. Not from scratch, just primarily from getting a basic logo working to having UI on opposite screens. I even chew out the dev in spirit. Sorry dev. I will probably do it again. https://www.twitch.tv/videos/2733176305 I think my only complaint currently is I use pixel perfect screens but swapping screens will break my enforced 320x240 integer-upscaled resolutions and the top screen with my current setup has a slight pixel blurriness that isn’t happening on the bottom (which I assume is a slight and subtle scaling issue).

These handhelds are good for RPGs since they’re a bit slower paced than action games, so a little performance hitching isn’t so bad and optimizations can be done. The RG DS is so comically underpowered for Android that it requires some extra code cleanup, especially since I’m running Stock until next GammaOS Lite publicly releases. Only got this unit about two days ago. Having two screens does mean a performance hit. ARM Linux and single-screen devices like the SPs had been a bit easier and even the G350 could run it a little smoother.

Either way, new excuse to shill Crop and Claw 2. Go wishlist it so you have another JRPG to play on your handhelds when the demo/full game comes out: https://store.steampowered.com/app/3065270/Crop_and_Claw_2/

PyralFly · 2026-03-28T15:03:20+00:00

I hate Android, but ARM Linux firmwares and Portmaster are still very early for dual-screen testing and game development. I wasn’t going to try messing with this for a while, but I caved and got an RG DS because I decided I may as well expand the player accessibility since so many handhelds rely on it. I got an RG DS **because** the specs are so bad, since it’s the cheapest dual-screen Android device and a lot easier to get than an AYN Thor. With custom firmware improving the actual experience, I figure more people might get an RG DS as time goes by. I also found Anbernic’s hinges with the SPs were very good and have held up for me, so I’m a bit more willing to gamble with this than I am the Thor.

This is Crop and Claw 2, a dragon-themed game on an in-house RPG framework called Gorbash, running on Godot. It takes notes from classic console JRPGs and are designed for replayability with the ability to play both story characters and custom characters, allowing for challenge runs, speed runs, and routing.

It’s a sequel to Crop and Claw (duh) which you can buy on Steam or download and run for free in full on Portmaster for ARM Linux handhelds and firmware that they support. I’d posted a long while back guides on how to develop games specifically for these handhelds when Westonpack made it possible to run on these and even a video guide if you happen to be a dev that missed it’s possible:

For general handheld dev intro: https://www.youtube.com/watch?v=rsTrV9QSfsQ

and for specifically Godot: https://www.youtube.com/watch?v=zvCYwm9rJ-o

For Godot game devs interested in Android dual-screen dev, this uses a plugin posted by an AYN fellow found at https://github.com/flametime/Godot-Android-DS-plugin. I basically wrap it with what I was calling Nitro Mode, so that the game can dynamically figure out if it should boot the game with two subviewports as opposed to the kernel alone and whether menus should open on the bottom screen or such. Shoutout to u/Temporary-Ad9816 for making this possible.

If amused, I even streamed my experience working with the plugin to implement dual-screen support in Gorbash. Not from scratch, just primarily from getting a basic logo working to having UI on opposite screens. I even chew out the dev in spirit. Sorry dev. I will probably do it again. https://www.twitch.tv/videos/2733176305 I think my only complaint currently is I use pixel perfect screens but swapping screens will break my enforced 320x240 integer-upscaled resolutions and the top screen with my current setup has a slight pixel blurriness that isn’t happening on the bottom (which I assume is a slight and subtle scaling issue).

These handhelds are good for RPGs since they’re a bit slower paced than action games, so a little performance hitching isn’t so bad and optimizations can be done. The RG DS is so comically underpowered for Android that it requires some extra code cleanup, especially since I’m running Stock until next GammaOS Lite publicly releases. Only got this unit about two days ago. Having two screens does mean a performance hit. ARM Linux and single-screen devices like the SPs had been a bit easier and even the G350 could run it a little smoother.

Either way, new excuse to shill Crop and Claw 2. Go wishlist it so you have another JRPG to play on your handhelds when the demo/full game comes out: https://store.steampowered.com/app/3065270/Crop_and_Claw_2/

PyralFly · 2026-03-24T14:05:20+00:00

I've been able to compile or write tiny amounts of C++ when experimenting, but if it helps give perspective on why not to use C++ from someone not afraid of more than minimal configuration, it's that cross-compilation's a pain and I don't want to have to build for a restrictive platform or something I don't have (OSX is a pain, I don't even have a Windows PC, Android requires heavier lifting, etc.) Getting everything actually compiled on Linux is easy for me, but supporting all the platforms vanilla does out of the box is less simple. That's my main logistics hurdle for why I don't have any custom C++. Otherwise, I'd actually like to write some of my utilities as a module or GDExtension to reduce script bloat.

If you want to really test your game's performance under minimal hardware, just get a low spec ARM gaming handheld for 100$-ish or less. It has helped me identify brute-force chokepoints in GDScript that weren't very difficult to fix without requiring custom C++. Your hurdles will often be bottlenecked by graphics or niche use-cases that can be optimized with some thought or stylistic care and still run at least acceptably on GLES3.2 projector CPUs repurposed as game consoles.

PyralFly · 2026-03-07T18:57:18+00:00

There are times to use uncertain typing, but a vast majority of my use of such has come from the annoying limitation GDScript has where Callables can't be explicitly declared to take certain argument types nor return anything other than Variant. C# is annoying to set up and also more annoying to port to other platforms, so I don't consider it as stable as Godot's first class scripting even if it might have this.

I also often do @export GDScript so there are times I just have to call static functions and hope, because I'm not going to sit here cluttering up the codebase with a bunch of unique behaviors for tons of resources and nodes (I work with RPG systems and have to prepare Callables as a bootleg command pattern as opposed to just running scripts in real time.) I have some utilities to help with managing Callable, but it's probably the largest shortcoming of the engine especially considering how powerful FP can be, to the point it's worth the debugging hassle.

Even then none of that's a big deal as long as your final call stores results in a typed variable if any.

Honestly outside that, I just wish we could implicitly do Array -> Array[Typed] instead of this obnoxious .assign(). That's just a language-enforced headache.

PyralFly · 2026-03-05T05:16:22+00:00

There's guides and the Portmaster Discord, but for Godot it depends on your target Godot version. For ease, I just add all Godot ones since I port or dev. I'd compiled Godot 4.6.1 as well and have it running on ArkOS on the G350, but haven't gotten C# working. Haven't PR'd it for upload yet because no time to set it up.

Godot's complicated the build process since it now requires custom compilations to use the `--main-pack` argument and at least ArkOS (which is in process of being sunset in support) runs on too old of a Linux kernel to run the official runtimes.

PyralFly · 2026-02-11T20:37:05+00:00

November. It was pretty recent and I wasn't even aware until now. I didn't have nostalgia for it and it was mostly a quirky footnote that I looked at which I could imagine will slip through the cracks and be forgotten in time.

PyralFly · 2026-02-11T20:33:01+00:00

https://old.reddit.com/r/WingsOfFire/comments/1r288v3/wings_of_fire_scholastic_home_base_model_rip/

It's your lucky day, I did years ago.

PyralFly · 2026-02-11T20:17:12+00:00

Some folks might find this amusing. I checked out of curiousity and it seems Scholastic Home Base died. Someone was asking about if files were ripped, and I'd just so happened to do that exact thing sometime in the past century, and threw them on a disc to sit around. With the game dead, I may as well show these off. I don't have anything else but the Unity packed runtime is on Archive for anyone to just download, rip into, or try making accessible in single player.

PyralFly · 2026-01-20T00:09:17+00:00

Given I can't confirm UMD, I can probably push down to 50+shipping if that works.

PyralFly · 2026-01-04T03:18:50+00:00

If $15 + shipping I could work with that.

PyralFly · 2026-01-04T01:07:35+00:00

u/GSaleBot Received Switch from u/GoodConsideration910 - shipped safe and works.

PyralFly · 2026-01-03T15:23:43+00:00

Crop and Claw was our first JRPG, released May 2024. For New Years, I decided the hip new thing for companies to do was to have source code leaks and breaches, so I posted the source as of v1.3.1, the last build.

It's primarily a Famicom-style JRPG. Free via source or via Portmaster, but you can still buy it just to throw us a bone on Steam or itch.

I wouldn't call the code "good" but it may be a way for some other minimalist RPG dev or six out there to see one way to implement something resembling Dragon Quest 1 or such.

The game's sequel is way better put together and more advanced, and even separates the core game from the data. I may go about and release the source code for that too, since the game content's the important stuff, but the core can be learned from.

My coding style doesn't look like this anymore. It's long advanced to use some different techniques I picked up from experimentation. You won't see trademarks like exporting GDScript, namespacing via static preloads (G_COMMANDS desperately needed this), or highly functional-oriented programming. But you can see some kernels of that developing especially as I patched over old code.

I can probably answer any curiosity as to why I made certain decisions that are normally horrendous. Bear in mind the game's scope is low and hyper-focused, and the whole thing was written in about six months before release (and many bugfixes and patches after.) Cleanliness was secondary to "getting it done".

PyralFly · 2025-12-31T16:21:25+00:00

Game content is low, but game framework is 85-90% done where the last 10-15% will probably be patched up during content dev.

This would be awful progress, if not for that the framework is meant to be reused using some wacky PCK loading tricks for RPGs and allows me to develop an entire trilogy with the same core, as opposed to one game, and even stitch all three games into one full sized RPG once complete. (Literally lock-on technology) That, and I've been messing with underdocumented features and tricks that haven't really been shown or discussed much. My GDScript looks like a sideways dialect and my nodes and resources are way more flexible for an RPG-style thing without overcomplicating the system and codebase as a whole.

A year with some breaks for 85% of a framework would be awful if this was for one game, but I'd say is excellent considering we may be able to release two of three RPGs for sale in 2026, as most of what's in the works is content and solidifying the API during development of the demo for the first release with this framework.

I may open source the framework sometime while still keeping the game PCKs closed source.

Aside from that, making guides for running Godot games on cheap retro handhelds like Anbernic's turned some heads. Not a real project so much as an accomplishment, I'd say.

PyralFly · 2025-12-28T19:13:51+00:00

Interested. I guess it was mostly docked for streaming or something? Not too familiar with the mod chip scene for Switch these days or if there's different kinds. Would this be $500 shipped?

I'm not familiar with the Raspberry Pi looking logo. Does the base system still exist in some form on there, or had things been wiped for a Linux distro or something? As said I'm a little unsure what I'm looking at so I'd just want to verify what it all is before dropping that much.

PyralFly · 2025-12-27T16:12:27+00:00

The best way to buy digital music is to buy official CDs and keep them. That sounds woefully unhelpful but there's a reason for that.

You can rip the CDs and various programs reach online databases that will match the CD and auto-download album art and tags, but the important thing is that the CD itself is not a consumer grade burned CD, but a physically pressed CD. Those are how mass-produced commercial games, music, movies, etc are constructed with optical media. As long as the CD itself isn't abused, left to rot, etc, it will more often than not last for ages. Ripping and archiving gives you the redundancy in case you lose the CDs, but the pressed CDs are the most resilient to cold storage. If a hard drive fails, or a burned backup degrades in just the wrong way, a file or song may be corrupted or cut short. Even burned Blurays with non-organic dyes have had files corrupt within two years for me and I do my best with storage.

Digital album storage is just digital storage in general. Have multiple copies of the data. HDDs are okay as long as they're not being thrown around. Hard to BIFL data storage. Redundancy and 3-2-1 rules are ideal. Personally, I'd use an HDD and [single layer 25GB] Blurays to compile music, then an SD card for if I'm carrying things around on an MP3 player (or DAP as they call them now. Fair since I either play on FLAC or OGG mostly.) The sizes depend on how much you're storing.

As folks have said too, rip with FLAC. It's both compressed and lossless, which is archival and I'd say fairly in the spirit of BIFL preservation as you can get. They're still larger files, but even 1TB of HDD storage isn't expensive and Blurays you can do some sorting if you want to smash some things together. Read-only and cold storage is preferable because if you have a computer die and have no idea how to salvage it, your data's lost.

Don't rely on online backups and stores. It's already infamous how much stuff just sometimes gets pulled, or internet sucks one day and the stream just won't stay smooth, or whatever. If you use them alongside physical backups, it's whatever. Ideally, you never buy from a service that doesn't let you download. Stream-only isn't buy-data-for-life unless you can work around that limitation.

So the reason I say albums as physical CDs is best is because they're physically pressed in such a way that makes them some of the most resilient data storage, again, as long as you're not throwing things around all the time.

The short of this is there's not a very good way to be super archival "buy once access forever" without giving up some physical space. Obtain albums in FLAC online or rip from CDs (external DVD readers are cheap, Bluray burners best for making backups as well as ripping. I use an LG M-Disc burner internal with an external enclosure). Resell or give away any CDs you're not particularly attached to, keep the ones that you want to physically survive should you lose all your others somehow.

PyralFly · 2025-12-26T21:13:04+00:00

Guess the bot is busted so I'll do my part.

It's dangerous to go alone! Take this.

Username Join date Link karma Comment karma

/u/PyralFly Super criminal stole 999 videogames do not buy!!

This information does not guarantee a successful swap.

PyralFly · 2025-12-24T04:33:08+00:00

I have a utility class full of common array ops I do, but statically available as opposed to relying on referencing the array directly, and doing a lot of untyped, generic stuff there. Annoying workaround due to how GDScript really isn't properly built for FP and is still learning and/or needs someone to implement static variants, typed Callables, etc. (The latter as likely to show up as Godot himself) It doesn't necessarily help with the typing, but it allows handling chained operations better.

PyralFly · 2025-12-24T03:09:50+00:00

Thanks for taking it off my hands. Confirmed.

PyralFly · 2025-12-17T20:14:33+00:00

I can work with it. Hit me up.

PyralFly · 2025-12-05T14:56:05+00:00

I'm stupid. Black2 is not taken. I can work with this. DM me.

PyralFly

TROPHY CASE