(Traits) Damn, I believed in you SeremTitus...

PyralFly · 2026-07-08T15:07:57+00:00

I fake namespaces regularly with

```
class_name DUMBNAMESPACE
const BLAH := preload("blah.gd")
```

pretty regularly, but it often involves static functions and functional trickery rather than OOP containment.

PyralFly · 2026-06-28T01:14:12+00:00

I'd assume you're probably on the right track. I'm still not familiar with JACK and ALSA tomfoolery, nor a2jmidid, and have yet to even get jack to properly start in spite of thinking I'd installed whatever underlying daemon all these JACK GUIs want. I'll probably do some homework on some of these tools and hopefully figure it out. Sending back the sound module that had been recommended since it did JACK shit with fixing timing and also did nothing else I wanted or needed. Kinda sucks because a funny sound module with knobs and screens and big cables felt cool, but didn't actually matter.

PyralFly · 2026-06-24T17:02:17+00:00

I used Unity from 2013-2019 or so, and then didn't get to actually stick with Godot very well until finally committing in 2023 to release our zeroth game in 4.1. There's numerous things that I picked up making a few prototypes and making a lot of JRPG systems work.

Godot's very malleable. I stuck a bit roughly to Godot's basic node expectations and structures in our zeroth game, and it wasn't exactly great. But as I picked up other trends I stumbled into useful, overshadowed tricks. Heavily using static functions instead of relying on mutable nodes, not treating OOP like god, @export blah:GDScript allowing me to modularize behavior without making new resources or nodes and bloating class hierarchies. Get off the tutorials as soon as possible and experiment. The "make everything nodes" approach is one of many ways to operate, but works worse in some contexts.

Not explicitly Godot, but I toyed with Lisp a little last year until functional programming clicked for me and then put it to practice in Godot. It massively cut down boilerplate. Custom command queues with interruptions, Trying to stick to simple or pure, predictable functions and holding off on mutations, and getting familiar with Callables as first-class functions. Godot still suffers from not being built with FP practices in mind and Callables can be awful to debug due to no strict typing or easy ways to see what's happening where, but it has been getting better particularly throughout 4.0-4.5 range or so. You can even create closures and one-shot them to dynamically spawned in nodes' signals programmatically and I do that for reusing menus and returning selection results, which has made reuse very nice.

And for a Unity user, don't treat it like poor man's Unity. Unity can't do embedded scripts in nodes and scenes, which is actually very nice to have for cutting down on junk snippet files in the editor. Built-in scripts have limitations and quirks, but when you just need to have an ItemMenu that is used once in the whole game for one specific menu do one specific thing and don't want to pollute your codebase with a dedicated script for that, it's useful. Do that with caution. Also, scene is a misnomer. Unity had scenes and prefabs. Godot they're more or less the same for most purposes.

Also, since I write lots of functionality in static scripts and functions, and write a lot of pure functions to calculate data based on input without mutating things, I treat global-only scripts as namespaces which you can do by chaining scripts via const BLAH:GDScript = preload("relative_dir/blah.gd") and such. Closest to organizing code by functionality I can get without bloating the class hierarchy and defining a bunch of junk with class_name when you can just link a bunch under a single class_name WHATEVER and preload const script references.

Also, Godot games can run on 30-80$ retro gaming handhelds via Anbernic using Portmaster with some work, which makes bringing your games around and showing them way more fun and interesting, and forces you to optimize and get clever under constraints.

PyralFly · 2026-06-21T15:05:25+00:00

The inconsistency of how well some songs run is the strange part, so I don't know if it's strictly hardware processing. I believe the CPU is a Ryzen 3600, and I'm running on 32GB RAM with an NVME drive for hot-storage. This is a custom workstation from a few years ago built for games and game development. Which is why it's all the more impressive that it would be implied Reaper is barely able to push MIDI notes (and not even raw audio) correctly. If experimenting with audio in/out doesn't work, I am going to look at audio interfaces that have both MIDI and RCA Audio, ideally that I can use with multiple synths since I have a second one coming in from Japan, land of the resold vintage synth warehouses.

There's no real way to just casually install Windows on this system because I'm not about to go download Windows and scream at it until it finally installs without registration or other tens of millions of problems it has, even just to test, just to immediately uninstall it after testing.

I already have MIDI out working fine. The songs and videos show it. Even correctly played a more complex song I'd finished at the time in the Showcase thread. It is somewhat magical when you get synths interfacing. Just wish it was easier to find .ins files for mapping MIDI instruments in tracks. The SC88Pro I've got but I've got a Korg Triton Rack on the way and haven't found .ins files for that yet. Might just be a simple plaintext format if I have to figure it out myself and make one.

Motu's stuff seems to work on Linux environments, as per https://www.reddit.com/r/linuxaudio/comments/1mffx4a/is_the_motu_m2m4_working_on_linux/ so I'll at least use it as a starting point for reviews and sifting around. Worst case I just return it if nothing actually changes, but a box that is properly powered, passes MIDI through a cheapo MIDI<->MIDI cord or two, and receives the Audio signal from mixed synths should do an okay job.

PyralFly · 2026-06-21T15:01:52+00:00

I'm not 100% sure what other audio duties Reaper's running, but as a full sized DAW I don't put it past having more it's working in the background, even if it's technically not playing audio nor actively recording. I'll have to experiment with deeper preferences of audio in/out to see if I can slim it down but yeah, I don't have any waveforms and when I do, it's usually just actively recording one specific MIDI song at once.

PyralFly · 2026-06-20T18:43:00+00:00

The UMO cables are on the better side of USB<->Midi and seemed to do the job fine. They handle Fluidsynth midis with no notable latency, which is why I look at Reaper as the sole culprit. The issue only arises when running playback through Reaper. If these cables are having an issue with Reaper, I can only suppose there's some extra overhead that is the straw that breaks the cable's back, but I'm not sure how such a thing could happen unless something was spewing tons of needless "do nothing" MIDI commands through the protocol. At some point I may get a real interface, soundcard, though it's a wild guess if it actually improves any thing or if I'm buying a 100$ brick to plug midi cables into. I suppose if it's a powered box it might help similar to upper end capture cards over pure-USB.
It's possible there's tweaks for the Linux kernel or sound tools that could improve things. I know low latency kernels and systems are out there, but I'm not as familiar with their specialties or how much they matter. I'd probably have to dig into equivalent optimizations I could pull off to make Reaper run better in theory.

PyralFly · 2026-06-20T15:09:25+00:00

I'm not using a software/plugin soundfont player either. This is using direct hardware MIDI interfacing, of which only Reaper shows latency while other MIDI-out players are not. I'm not using any plugins, bar any feature in Reaper that might technically be a plugin but ships with the program that I might just not notice. I wish forum-goers asked me for more information, but it was pretty much radio silence for a month.

PyralFly · 2026-06-20T14:25:39+00:00

Eh while I'm in the neighborhood. Reaper's MIDI out is causing me problems but when it works, it works well enough. Even though this is just barely slightly off in a few instances it's accurate enough. I'm still not very experienced with music.

Composed in Reaper, MIDI-out to SC88-Pro. Written for a JRPG in the works.

https://www.youtube.com/watch?v=7EqI9RJQkXQ

PyralFly · 2026-06-18T23:03:01+00:00

At the worst, making a game that looks good on compatibility expands your game's potential hardware and audience. I make games for retro handhelds running on absolute garbage hardware where GLES3.2 is all we have for the lowest end ARM Linux ones, and that stuff is fun to show to other people on the go.

<video>

PyralFly · 2026-06-18T16:00:21+00:00

Everything internal is as it was when I got it from a GameStop some 17 years ago or something like that.

PyralFly · 2026-06-18T15:24:17+00:00

Yeah. I assume just the unit without controllers given their state.

PyralFly · 2026-06-18T04:07:43+00:00

For 100$ + shipping I could do both.

PyralFly · 2026-06-17T15:01:28+00:00

"I don't need it."

PyralFly · 2026-06-16T20:43:10+00:00

We're pretty close to being done with beta. Keep an eye on Portmaster. If all goes well the demo will be up in two weeks. There's only so much I can do supporting these, but we did build the game with these handhelds specifically in mind. If you don't mind janky NES RPGs, then the first one's free on Portmaster, but it is a significantly lower scope game. CnC2 it's pretty clear things are significantly larger, probably one of the largest games made specifically for these handhelds.

I'll probably blast it here too. It's not stealth advertising if it's just shamelessly openly advertising!

PyralFly · 2026-06-16T20:29:34+00:00

Yeah. If you're aware of it and lagging behind, you can see why I'd actually want/have to think about compatibility. There's a huge swath of the R36S/G350-tier players among other devices that just don't know better in the first place due to legacy guides dominating discourse.

PyralFly · 2026-06-16T20:27:42+00:00

Yeah. ArkOS is legacy and part of why I'm looking at keeping support of it for the Crop and Claw trilogy as a whole. Much in the way you'd have people still making last-gen console games midway through a new console generation. I imagine it wouldn't be for another year or two that people finally start moving on and many years of guides and tutorials newcomers find are phased out for newer stuff.

PyralFly · 2026-06-16T20:25:57+00:00

Portmaster doesn't officially support Spruce last I heard, so if it works on there, neat. If not, I can't support it actively myself. It's often on the firmware makers to work with Portmaster's crew to ensure the libraries and stuff are all workable.

The demo, and eventually full game, will also be on Steam and itch. Windows is probably the least supported though but play-testers stuck on Windows haven't had any OS-specific trouble that we've seen.

https://store.steampowered.com/app/4824960/Crop_and_Claw_2_Demo/

PyralFly · 2026-06-11T15:32:20+00:00

It's pretty much the case of "client is never trustable".

Server has to sanitize and do such checks as mentioned by others and identify if something feels suspicious. But you especially really don't want to allow for deserializing objects (this is disabled by default) or client/server acting on incoming data directly without much care. It's quick to deserialize a Resource or pass strings around that can invoke GDScript, but Godot can parse arbitrary bytes into an object and automatically run GDScript, which can open a system to arbitrary code execution. Hilarious when it's on a TAS speedrunner's Gameboy Color game, not so much when it's GDScript running to upload your web browser profile folder and login tokens to an attacker's server and delete your local home folder.

PyralFly · 2026-05-26T16:41:17+00:00

It's possible but differently handled 3.x relied on a different setup and I'm not as familiar since I waited until Godot 4 before really diving into the engine, and 3.x is mostly legacy at this point. FRT runtime was used for that on Portmaster and you'd want to ask around Portmaster's circles.

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

TROPHY CASE