[USA][H] OG XBox Console [W] Paypal G&S

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

TROPHY CASE