[Launcher] New enhanced GameShell (and DevTerm?) launcher in Development - Devlog & Feedbacks

We can try to troubleshoot that, PM me anytime and I’ll help as I can!


Oh boy. Okay. I knew this was going to be a problem.
My DEOT image (I’m assuming you’re using my custom DEOT image, and not the official OLD one?) moves A LOT of the directories around, updates versions, and basically, I’d say anything the Godot launcher tries to call upon won’t be expected or found.

I will need to spend a good deal of time figuring out what the Godot launcher calls upon in order to work out what needs to be changed. I unfortunately haven’t learned to code in Godot, so would need to really spend a fair bit of time.

My best suggestion would be NOT to use my DEOT custom OS with Godot. In fact, the main reason my custom image exists was to add in a GUI akin to the stock DEOT image, along with universal volume adjustment and a bunch of extra emulators and icons. The first of the two points are covered by Godot. You can easily install the emulators yourself.

The stock image is based on Jesse afaik. My image is based on Buster. I think I recall some people installing it on Bullseye. So theoretically, the Debian distro shouldn’t make any difference.

@Samdze would it be possible to PM me re: what directory structure your launcher depends on existing, including emulators, Roms, and basically any apps it might depend on? Ideally I’d love to have it working on my custom image, but for now it looks like a lot of people will be having problems.


collaboration between @Samdze and @javelinface likely in the future?

1 Like

Ha! Well! Theoretically, we shouldn’t “need” any of the features of the DEOT image, since basically the launcher is rewritten from scratch. The only thing of note is really the custom boot screen, mupen64plus+, updated Retroarch with changed core directories, and Debian Buster.

Starting from scratch using @Joao_Manoel ’s minimal image would be logical step from here, and then consolidating a logical directory structure for Roms, apps, emulators etc would be next.

Ideally, having a different partition for “read only” foundation system apps etc, and a separate user space for Roms, configs, save files etc would be the way forward. But yes, that indeed would be A LOT of collaboration.

Perhaps this is something we should get @guu in on as well? Sounds like we’re reinventing the wheel here!

1 Like

why do i get the feeling it looks like its hobbled together with chewing gum and shoestring?

1 Like

Should not be the case, all the directories the launcher looks for are optional and are just the default directories for apps and games and they will be configurable in the future.

The only requirement right now is that the launcher itself has to be placed inside the user home directory.
I added a veeery short section on troubleshooting on GitHub, hope it helps if someone has no clue on how to understand what’s wrong.

Another thing, on the GameShell the launcher relies on the system’s stock procedure to launch itself, not sure if that’s changed on the DEOT image. I’m thinking about it because a screen like @Metonym 's is very strange if the GameShell doesn’t try repeatedly to boot the launcher and stays idle like that.

Right now the launcher should be quite robust, I just implemented a complete modules+dependencies system to easily be able to support different hardware and software configurations for system utilites (given someone writes modules for them)

1 Like

most likely a problem with the way DEOT boots, as it’s definitely different than on the stock image (the glitching effect is one thing you can easily point out)

i also flashed the stock image and installed the launcher the same way i did on DEOT, and it works perfectly


Alright, I don’t know how the DEOT image boots, but should be easy to correctly configure the initial startup scripts, on github there’s a bit of documentation on how to manually start the launcher in the Other Linux Devices section.


The screen glitch “should” be resolved in a hot fix I posted. That’s to do with basically changing the kernel.
Perhaps the kernel is to blame, with a different tclock divider? That could be conflicting with Godot.

Other than that, I also change the window manager, but that shouldn’t be a problem if you’re using Godot.

The only other thing I can think of is that I have added a startup sound. I don’t know if that would mess with startup, if it needs to wait for the file to fully be played.

When I have some time I will try everything out.


weird, I installed @Samdze’s launcher on top of @javelinface’s latest DEOT image since the first time and it booted well enough to me. I had some issues, such as: Pico-8 and gPSP+ standalone emulator not working, but it definately bootable.

1 Like

I’ve added a Switch menu item to the initial python launcher, so I can easily switch from that to the godot-launcher (contrats, it’s great) . You’ll find it here : [LauncherGodot] add switch menu item based on "Switch to LauncherGo" by arthurlutz · Pull Request #332 · clockworkpi/launcher · GitHub

This enables me to switch from python to go to python to godot launchers without the need for a terminal :tada:

I can probably spin up some commands to send this modification to your pi (maybe this could be in the README of the godot-launcher).


Great addition!
I was doing something like that in my python launcher installation for testing, but I modified the lauchergo entry instead of creating a new one.
Your solution is much more feasible in the real world, I hope it gets merged!

Regarding the development of the launcher itself, I’m currently in a pause state, mostly waiting for the DevTerm to arrive so that I can make it work great on it, refining the last details and adding documentation in the meantime.



Connect to community in telegram [URL REMOVED]

You up a topic after more than a year of inactivity to post that unrelated link?

First warning.

Sorry for being so late on the topic I just joined yesterday. First lemme tell you this launcher is really good however we loose the music player. It’s smooth and has the ability to embed other apps within it which is nothing short of Awesome.

Do you think we can rewrite it in gdscript? perhaps pull ID3 tags out of the tracks iPod Style with a cover art? I think I’m gonna try to do just that. thanks for your effort Samdze. You absolute Legend.

1 Like

Yes, absolutely!
Unfortunately, the music player is embedded into the stock launcher, so it’s not accessible using this one.

But yes, writing one in GDScript is perfectly doable!
You can even choose to make a launcher module or a standalone Godot/whatever app!

1 Like