#How To Export for a Retro Game Console?

1 messages · Page 1 of 1 (latest)

light granite
#

I'm trying to export a Godot game to my Anbernic RG35XX H running MuOS (Linux-based), but the game doesn't show up on the console. What export format or steps do I need to follow to make it playable on this device?

I've been asking Chat-GPT, google, and searching forums but I can't find the answer. It's probably a lot simpler than I think but I just don't know where to look and what questions to ask.
#Export

neon patrol
#

@light granite This is embedded coding related, right?

#

Have you tried using filetype:pdf and certain google operators to find unlisted documentation, etcetera?

#

These are the only two search results I got from this google search:

"anbernic rg35xx" filetype:pdf MuOS

#

The dinoleaf looks most promising but you probably already found it before, I assume

neon patrol
#

Hope this helps you somehow:

MuOS will only list a game if it sees (a) a Linux binary that matches the RG35XX H’s 64-bit ARM chip and (b) a little .sh launcher that tells Emulation Station how to run it.
So, export your project from Godot as a plain .pck and pair it with an ARM64 runtime—the easiest drop-in is the community-made FRT 2.x build (frt_210_403_arm64.bin, rename to godot, chmod +x). Put both files in /ports/<gamename>/, then create MyGame.sh in /roms/PORTS/ (contents: #!/bin/sh; cd "$(dirname "$0")/../../ports/<gamename>"; exec ./godot --main-pack game.pck "$@"). MuOS/PortMaster sees that script, recognises the ARM64 binary (the RG35XX H runs an H700 Cortex-A53, i.e. aarch64) and adds the title to the Ports menu after you hit Start → Refresh Lists or reboot. If nothing shows up you’re either missing the launcher script or you dropped an x86 template; on very old 32-bit MuOS images just swap in a 32-bit (armhf)
Godot build—everything else stays the same. That’s all there is to it: right binary, right folder, one launcher, done.

glossy imp
#

Ahhh, I see FRT has been discontinued. It would be nice if Godot officially supported single board ARM devices like Anbernic - they're becoming very popular and are really good little consoles.

light granite
neon patrol
#

There’s always a workaround

light granite
#

Quote from @toxic merlin

If you want a very short version:

  1. export game for arm64 linux, check etc2/astc checkbox
  2. Copy this example and paste into a file called "Your Game Name.sh":
    https://github.com/binarycounter/Westonpack/wiki/Godot-4-Example
  3. In that file, change the variable "godot_runtime" to "godot_4.3", change "godot_executable" to "godot43.$DEVICE_ARCH"
  4. change the "your_port_folder" in GAMEDIR to any folder name of your choosing, change pck_filename to the filename of the pck file from your Godot export, change gptk_filename to any filename of your choosing (this file will be used to map your controls)
  5. make a new folder with the name from above, copy the pck in that folder
  6. create a new file with the filename of gptk_filename, add your controls in it, like this
a = enter
b = esc
x = space
y = tab
``` you get the point

7. Then you put your sh file, and the folder you created in your roms/ports folder.
8. Run it!
GitHub

Contribute to binarycounter/Westonpack development by creating an account on GitHub.

light granite
#

I'm almost done with following the guide. If this works I'll create a video guide. Right now I'm waiting for my RG35xxH to update (I gave my other MuOS to a friend and needed to format another card.

neon patrol
#

Seems like you got this covered though.

toxic merlin
#

Oh hey, I've been summoned 😅

flint wyvern
#

I'm interested in this, did it work out? Any guide on this?

toxic merlin
# flint wyvern I'm interested in this, did it work out? Any guide on this?

I don't know if @light granite has got it working yet, but the process is pretty straightforward

Here's some guides
https://dinoleaf.com/pro_file_hosting/godot-retro-handheld-dev.pdf (by @simple lily )
https://github.com/Doronimmo/GodotPorts/wiki (by Doronimmo)

And an example script
https://github.com/binarycounter/Westonpack/wiki/Godot-4-Example (by me)

The general jist of setting this up is just exporting a PCK for ARM64 Linux with ETC2/ASTC enabled in the export. Then you put that pck in a folder together with a gptk file (which is a simple config file to all you to map the device buttons to keyboard and mouse).
Guide for that: https://portmaster.games/gptokeyb-documentation.html#keyboard-mapping-options
Then you copy the example script from above, change some filenames at the top to match the Godot version, folder, pck and gptk filenames, and that's pretty much it.

It runs on pretty much all devices that can run PortMaster, starting with the r36s, which you can get for like 30 bucks at this point.

It works via a compatibility layer I've made that basically translates several different Linux OpenGL context systems into SDL2 calls and runs a headless Wayland compositor. Above that layer, the normal Godot 4 Linux ARM64 runtimes are used. Your game would be running via the compatibility renderer on OpenGL ES 3. Performance is generally good for 2D, but can be hit or miss with 3D, especially if you use pixel lighting.

GitHub

How to port Godot games to Portmaster. Contribute to Doronimmo/GodotPorts development by creating an account on GitHub.

GitHub

Contribute to binarycounter/Westonpack development by creating an account on GitHub.

simple lily
#

Oh is this gaining presence here? lol

#

The dinoleaf looks most promising

I'm special.

#

The process involves a bit of an uphill battle to get it figured out, but that's more because of the variance between devices and firmwares.

#

It's easier than it used to be, even.

toxic merlin
#

You really wrote the best guide that targets Godot devs, rather than people familiar with the PortMaster project

simple lily
#

That was the intent, at least. I meant to get around to a video guide but it's a bit hard to cover all bases.

#

I'm a Godot dev targeting these devices, rather than a Portmaster cadet trying to get games to run on them.

#

Perhaps I should make a few multipart video guides so I don't date an entire thing all at once.

toxic merlin
simple lily
#

It mostly is an uphill battle starting from zero since there's a lot of assumptions and it seems easy for people to overcomplicate it. I notice the belief you need a custom runtime still exists.

#

I'll probably stress it whenever I do a video guide some.

toxic merlin
simple lily
#

That too. To some extent, the performance testing stuff I was doing is also intended to be that.

#

The idea is it would be available as a Portmaster "game" but is mostly there to feel out the power of a specific device or setup, so I'd probably also wrap it up in an example package. Albeit a larger one, due to assets.

#

Basically your average console tech demo showcase for figuring out how stuff works.

toxic merlin
simple lily
#

It might go lower level since it'd be wanting different engines and get more accurate results.

#

Tech demos are pretty useful for showing what could be done with tools devs are familiar with, so they have a useful niche in the Portmaster setup.

#

Getting dev suites together wouldn't hurt.

#

I'm still figuring out how I'd set up a reusable suite for 4.x dev to handle the various environments.

toxic merlin
#

Honestly, just target the lowest end

#

¯_(ツ)_/¯

simple lily
#

The firmwares are the issue mostly. Even the G350 has PanELEC + MuOS.

#

I'd even go as far as to say lowest end is stock, which isn't supported.

#

Since stock is the lowest effort for the end user, and thus lowest common denominator.

light granite
#

Hi guys 😃 . I haven't gotten it to work yet but this is where I'm at so far. I've created a video showing what I've done so far to help see where I went wrong.
https://youtu.be/HpedCKGbaY4

This is what I know so far on how to export a game for the RG35xxH. It didn't work, if you have any thoughts I should try let me know. Leave comments.

Here are my notes for this so far
https://docs.google.com/document/d/17XsPfBglv16FbrSoEj59mAnTXzcSsuUmkIpDFoYCov0/edit?usp=sharing

▶ Play video
simple lily
#

My assumption would've been that Emustation runs the program's bootscript as the proper shell/bash script rather than directly needing to chmod it, so unless some firmwares or their own frontends are weird, I'd think that's not needed?

Use Godot 4.2 or 4.3 for best compatibility with FRT-based runtimes.

Nah. FRT was stuff used in 3.x, which were specialized SDL builds of Godot. for 4.2+ the guy who was maintaining that made them an unusable option. Instead the compatibility layers run vanilla Godot ARM64 runtimes. 4.2+ is best for running 4.x on Godot.

Stick to 2D games for best performance. Some 3D features (like pixel lighting) may lag.

Godot 4.4 reintroduced vertex lighting, so you can do 3D fine if you keep it simple and optimized. But yeah, on a H700 device, you can't rely on Vulkan features as you're entirely working off of GLES3.

#

The builds of Godot 4.x that Portmaster supplies is identical to the official builds.

#

Also, Portmaster's example scripts output logs to the game's Port subdirectory. You can see why something's not booting in there

#

If Godot is executing, then it should be throwing Godot related errors that the runtime's encountering. Usually something like the wrong textures or imports, a missing .so that was only on x86_64, or who knows what else.

#

Otherwise it could be an issue with the system setup.

#

Also, if you do this, make sure you don't have the defaults in the example script after.

#

Because otherwise, you're setting all your values, only for them to be set to these defaults later in execution.

light granite
simple lily
#

This somewhat gives me an idea. @toxic merlin I don't imagine there'd be any issue of the base script being packed into the game subdir, and then calling it from a minimalist script with all these as arguments, yeah? Don't imagine that'd change the working directory or cause issues. I might see how that is handled.

#

Even my terrible shelling skills, I can probably feel it out.

#

Seems to not quite work the way I assume, so probably more complicated than just passing off the bloat

toxic merlin
simple lily
#

Oh, so I guess you do need to ensure the script's -x'd? I'm so used to copying the script and changing stuff that I hadn't even verified.

toxic merlin
simple lily
#

I'd figured they were run with sh/bash under the hood rather than just ./blah.sh

flint wyvern
#

I am very much a beginner, and have plans to port the game I'm making in Godot now to an ARM or raspberry pi version, and have been writing things in a way such that I can try learning to move to a custom runtime engine for example Raylib.

My main concerns are Godot 's move to vulkan in 4.x (which I think is really cool for learning vulkan features) and since it allows for different versions of the features in the game I'm working on e.g. whether I do stuff on the GPU/compute shaders and stuff (which is fun to learn) or use CPU only. So far I can test my features by moving to compatibility mode and opengl3 (but I'm not sure if this is opengl ES? @simple lily it is possible as you say?) I have singletons/autoloads that control whether certain features run in compute shaders vs CPU-side rust bindings

But I'm wondering how much custom runtime stuff exists with Godot? Am I wrong to assume that Godot's runtime can be very bloated when just working with simple beginner 2D games?

It seems Godot has some raspberry pi porting capability but I wonder if it's worth learning that (or if Godot is not that friendly for this?) or if it would be a better learning experience to try porting to something like raylib?

What do you think?

simple lily
# flint wyvern I am very much a beginner, and have plans to port the game I'm making in Godot n...

OpenGL3 is not GLES3, but Godot has support for GLES3 which is how it works here. The ARM build expects a few things that aren't available on these devices, but that's what Westonpack provides in some chimeric form.

Am I wrong to assume that Godot's runtime can be very bloated when just working with simple beginner 2D games?

The same can be said for most modern game engines. The developer's time is usually more costly. Godot's light enough as is for most modern systems and the PCK or even runtime can have features stripped out if really desired.

It seems Godot has some raspberry pi porting capability but I wonder if it's worth learning that (or if Godot is not that friendly for this?) or if it would be a better learning experience to try porting to something like raylib?

Godot editor itself runs fine on the RPi5 and I spent a few months working on it almost exclusively for 2D and basic 3D out of science. The hardware and setup's still weaker than the average PC, but 2D mostly will run fine. Worst case some shaders aren't friendly.

Raylib will likely be leaner but also have a far longer development cycle, because it's more or less a toolkit to build a game and/or engine on, rather than a full suite.

#

If it's like one of my prototypes of Crop and Claw 2, it sounds like writing asset loading and potentially game logic separate from anything Godot relies on. It's possible, but again, you'll be rewriting a lot of engine features if loading into a Raylib game. Godot's runtimes work fine on these devices so long as you learn the engine's quirks, the hardware quirks, and manage your memory and frames well enough.

#

Raylib itself with GLES3 might port fine, and there's less moving parts, but the time to actually write the game itself is going to be longer.

#

If you're super beginner and have no idea how gamedev works, then iteration with Raylib will also likely be slower because you're working at a lower level without necessarily knowing how engines typically run or how to construct core loops and tools.

neon patrol
simple lily
#

RK3326 units will be slower, but H700 CPU units like the XX-series from Anbernic, with 1GB RAM, can handle simple 3D with Godot 4.4+ since they added vertex shading back.

neon patrol
#

tfw ur a retro game console dev

simple lily
#

This is a visual demo test running on a RG35XX-SP through HDMI capture

#

If you're used to writing in C for complete projects/engines then you could have an edge writing your own tools. It depends what you're going for.

#

Though if you're able to write for legacy systems, you can probably just rely on obtuse systems emulating it.

flint wyvern
# simple lily If it's like one of my prototypes of Crop and Claw 2, it sounds like writing ass...

Thank you for the response! That gives me a lot of hope! I would really love to stick with Godot because if I can participate in adding documentation to it's quirks and stuff that would make me feel great about adding/collaborating to something like Godot.

But yeah my game is going to be pretty shader heavy, because I'm practicing learning graphics programming, so I always get nervous about Godot and opengles porting inevitably. It would be amazing if you could include that in your video guide when you release it, me and my friends have saved the Google doc guide and will definitely be looking deeper at this stuff in the coming months. Thanks!

simple lily
#

Shaders will throw curveballs due to Vulkan renderers having exclusive features not available to GLES3 and sheer performance, so you'll definitely need to manage them carefully.

#

I don't know enough about writing shaders to say in depth.

#

But you definitely don't want to just yoink general purpose shaders off of that GodotShaders site which tend to be written for PC specs and tank the framerate.

neon patrol
simple lily
#

I'd probably treat designing games for these devices as designing for the Gamecube or something.

flint wyvern
# simple lily Shaders will throw curveballs due to Vulkan renderers having exclusive features ...

As I work right now, I have been intentionally porting back and forth all my shaders between shadertoy and Godot as a test for universality. It's only with compute shaders that I have yet to deep dive on how much vulkan specific stuff is at play. But that's where I have plans to just switch between CPU side stuff with gdextension rust (or maybe C at somepoint) and compute shaders. Because compute shaders is something I really want to learn but am totally ok with abandoning for CPU-side stuff when it comes to moving to raspberry pi

simple lily
#

GPU particles work on the hardware fine. I haven't tested in depth though.

flint wyvern
#

Shadertoy is webgl I beliebe

simple lily
#

GDExtensions, the main warning is you need to be able to export the library for ARM Linux and then hope that it doesn't have some dependency that isn't available.

flint wyvern
#

I hope I can offer some use cases/demos on raspberry pi with gdextension CPU-side vs compute shader implementations of the same logic on gpu

simple lily
#

C# can't, for example, run out of the box on Godot because of reasons I'm too dumb to get even though it's been explained to me, probably, on these devices anyways.

#

RPi Raspbian and a 6000-in-1 handheld from China with a custom firmware are two different domains.

#

To some extent, I'd say Godot being available to easily* port to these systems is relatively a new and novel thing, so there's still not much formed around it. My written-in-a-day guide is the closest to a dev-centric rallying point.

#

It's been available before but Godot 4.x wasn't possible to distribute due to the SDL builds' weird licensing, and also most people working with Portmaster aren't devs that deliberately target this hardware. A lot of the effort's just trying to make games run on them despite not being meant to at all.

neon patrol
#

mm

#

Workarounds babyyyyy

simple lily
#

That's basically what that whole mechanism is.

#

Godot needs X11 to run. These firmwares except one don't have it.

#

So here comes BinaryCounter ignoring the bot in the Discord server telling him he can't port Unity games, and he goes and writes an X11 system as one of the many layers to throw in.

#

Or X11 faker, whatever.

neon patrol
#

Well, some people just think of workarounds as breathing

#

Alternatively constructed developers

#

Built differently xD

flint wyvern
#

Is openglES abandoned for core Godot engine? I really like compatibility mode and it seems like it's still being updated since 4.x for this reason?

simple lily
#

I have no idea the state of ES.

#

Compatibility/GL has been around since 4.0 despite I think it was originally going to be readded later. Maybe it has enough overlap they've kept it.

flint wyvern
#

It works in 3.x right?

simple lily
#

I don't know much about running 3.x games.

#

Pre-4.x Godot was really rough and awkward.

#

I mostly waited until 4.x before I really invested in Godot.

flint wyvern
#

I imagine, 4.x is really great though, I waited till 4.4 I guess

simple lily
#

4.4 is currently the definitive for Godot on these devices, I'd say

neon patrol
#

It’ll only keep improving! Be part of the change you want to see! FOSS, FOSS!

simple lily
#

I'm not smart enough to add typed callables to the codebase, so I cannot.

#

That'd probably be Godot 5 if I'm lucky.

simple lily
#

Godot's source probably has enough headaches. They don't need more.

#

I stand by adding more functional support will make GDScript better. I almost wish I could hack the entire GDScript module to create a functional-bias dialect.

#

Just so I could cut down some of this damn boilerplate.

neon patrol
#

And the cyclic dependencies issue keeps coming back to haunt them like the devil

#

Patch ‘em with duct tape and workarounds, bit by bit!

simple lily
#

I still have no idea what is utterly broken with Crop and Claw because Windows still crashes it and I've already fixed all culprits I could find. These cheap ARM Linux handhelds run it better than Windows.

neon patrol
#

Not to mention… this…

simple lily
#

Likely a stack issue and something with its handling of callbacks and coroutines, but it's completely non-obvious.

neon patrol
#

Wait let me share it, I find this one to be a funny issue

#

hahahahaha

simple lily
#

I only use CanvasLayer for UI, so guess I dodged the bullet.

neon patrol
#

I just love it

#

Workarounds everywhere

#

A lot of the time … you don’t even realize it

#

But you ARE using a workaround

simple lily
#

I'm pretty aware that middleware's a mess, but that's always been the case. If I had time to write a custom game VM I would, but I've not the time.

neon patrol
#

Same tbh

#

Thanks Pyral.

simple lily
#

That answers that.

#

It can't find the runtimes. This was R36S yeah? I don't think it has wifi, so you'd want to fetch the squashfs packages manually

#

I'd suggest grabbing the godot_4.3.aarch64.squashfs file and weston_pkg_0.2.aarch64.squashfs and dump them in the directory specified there (/mnt/mmc/MUOS/PortMaster/libs/)

#

Probably grab other Godot 4.x runtimes for aarch64 while you're at it.

#

In theory it should work once that's been done.

#

Portmaster usually can download runtimes on its own, or the Godot bootscript will try for the sake of convenience, but if the device has no wifi/isn't connected, you'd need to put it in yourself.

light granite
#

The RG35xxH has wifi, I hadn't setup it up yet. I'll get that setup now.

light granite
#

After connecting my RG35 to Wi-Fi, I updated PortMaster and tried launching the game. The screen stayed black for about 10 seconds, then nothing happened.

I pulled the SD card to check the log. It was too long to read easily, so I dropped it into ChatGPT for analysis. Here’s the summary:

PortMaster initialized correctly and set up its config paths.

It began downloading two runtimes:

  • Westonpack 0.2 (for UI and rendering)
  • Godot 4.3 (needed for running Godot 4 games)

Westonpack downloaded and validated successfully.
Godot 4.3 download started, but the log cuts off around 21MB of 22.43MB, so we can’t confirm if it finished.
No actual crash or error occurred—just a likely issue during or after runtime setup.

What I'll try next:
Make sure the Godot runtime fully downloaded.
Double-check that my game folder has:
the exported .pck file,
the control map .gptk file,
and a script file referencing godot43.arm64.

Here is the link to the full Log:
https://docs.google.com/document/d/1SCvTGcf_PhtV0gc34nA7XULIhEQbrpFu9eZ6een4tTg/edit?usp=sharing

light granite
#

I’m getting closer! It nows shows up but the controls don’t work and there is no sound.

It was the runtime. I had to update the sh to godot_4.4

Now Im researching why the controls don’t work.

simple lily
#

Controls are always a bit weird.

#

AI is pretty unreliable and leans more on the Artifician than the Intelligence. Especially for something so niche which it lacks training schlock.

toxic merlin
#

Yeah, please stop relying solely on ChatGPT, especially when it comes to niche topics like this. It will make many false assumptions

toxic merlin
simple lily
#

Oh I didn't think the gptk file came from that. The gptk file would be pretty inconsistent across games, yeah. You have to craft it yourself based on what inputs the game expects. Though you can recycle some common ones as Godot has default UI input built-in that you have to manually change to not comply.

#

No AI has the context to understand that.

#

It's worth noting though that I'd say input is one of the rougher parts of Godot on these firmwares and devices. A sometimes means B, Y sometimes means Start. Haven't really figured out how to work around it all.

#

I think the best way to would have to be to have multiple gptks that are manually made for each game based on each firmware and system tested, with a fallback for defaults, but I haven't really looked into how I'd do that in Portmaster.

#

That's kind of a brute-force method

#

You'll also be deliberately disabling joypad input when using Westonpack with this script (one of the options does it) and remapping to keys rather than relying on natural joypad input. Otherwise you'd get a looot of weird inconsistencies.

#

The best is to have control remapping in-game, but that's not always trivial (I still need to get to messing with it) and Portmaster definitely can't rely on a game having in-game remaps because random itch entries or something are wildcards.

toxic merlin
light granite
#

I got it working!!! Thank you for all your help. You’ve been amazing.

light granite
toxic merlin
# light granite I agree the AI made a mess of it on the first draft. I used the guide you shared...

You know, as much as I like AI as an assistance tool, I feel like you're relying on it too much.
You would have a much better experience working with this and learning programming and game development in general if you just read the guides and tutorials that people linked you instead of pasting it into an AI and waiting for it to get it right on the third try. You may have a working project now, but you have still not learned how to do it in the future, without relying on gpt to do the work.
And in the end, what could've been a 1 hour project following a guide, turned out to be a 3 day project, and required me to sniff out that your AI messed it up, because you didn't know, because you haven't actually learned how to do it. The AI did.

simple lily
#

AI's basically asking someone with a severe case of Dunning Kruger to fix the thing they screwed up prior.

light granite
# toxic merlin You know, as much as I like AI as an assistance tool, I feel like you're relying...

You have a lot of great points. Now I do want to clear up one thing, I did read through the guides. I'm not a programmer so a lot of the jargon didn't make sense to me. AI helped a lot to explain what everyone was saying. I agree there is a lot more I can learn that I may have missed because I was using AI.

My main goal was to answer the question, "Can I make a game and get it to play on a retro console?"

I wanted to test the full workflow from Godot to console before I committed to learning the engine. Now that I know I can do it I'll be diving deeper into the details that I missed. Thank you so much for the time invested in helping me through this project.

simple lily
#

Yeah, doable. You'll still need to temper some expectations because these are running with limited hardware constraints relative to the average PC, so you'll probably find yourself looking for optimizations. Stick to 2D for a long while especially if you're a beginner, and you'll probably be okay. Physics and 2D shaders would probably be the main way things will slow.

wide spire
simple lily
#

Go into where you stashed the game and find log.txt. Portmaster's default bootscripts are written to dump to the game's directory.

wide spire
simple lily
#

That could be for a number of reasons I don't know of. You'd probably be better off asking around Portmaster's crew.

wide spire
#

ok got it Thanks. I will let you know if they helped me

wide spire
simple lily
#

Impressive, since I didn't actually do anything.

wide spire
shut raptor
#

Hi im trying to get this working but i keep failing