SWEET CHRISTMAS! Yup. That be a font thing! Argh. I’ll fix that up with the next release!
For now, if you just replace the font it corresponds to with the the same one as the stock font, it will be all good! Thanks for the catch!
Incidentally, good job on the DEOT continuation. I never flashed the original version, so I don’t have anything to compare it to, but it seemed to look and work well in the bit of poking around I did last night after I flashed it.
I put this DEOT on my 400GB card, which I had mostly given up on using in the Gameshell at all (but hadn’t gotten around to using for anything else), since I could never properly flash and use the official 5.0 on it. It always gave verification errors after the flash, and didn’t work in the device either. (The same 0.5 file flashed fine to my 256GB card, which is the one still currently in an uncertain state with Buster, but hopefully I can revive.) Your DEOT variant not only flashed, but the script you included to expand it to the full card also worked fine. Though it’s certainly overkill (even 256GB was kind of ridiculous, even for keeping lots of code around and building lots of things!), I’m thinking what I may do is pretty much archive the entire contents of my old card from within the system as tar.gz, and then extract it out to a temporary directory on the new card. It will still take a lot of digging and tinkering, but at least having all the contents on the card will make it easier to move stuff around and piece things together.
I think you’re already aware of the other minor bugs I’ve found: the volume and brightness controls are still partly using the background from the original firmware.
Also, is it redundant to have “Retro Games” -> “id” -> [various games] AND “ChocoDM” at the top level? I haven’t set up any of them or tried them, but I’m assuming they are essentially the same thing, with ChocoDM providing the old style list when games are available and the other menu area providing icons for each game?
There’s also an awful lot of stuff on the top level of the launcher menu. It was fun to see the old DEOT toys (since I’ve never seen them before), but it might be worth considering organizing things a bit differently. Maybe create an “Extras” entry at the top where these things, and perhaps other less used and unessential stuff could live?
Since I haven’t been following along very closely with the updates of DEOT, does the option to “update launcher” work? Or does it wreck everything? Since it probably just does a git pull in the launcher directory, I’m assuming whatever is true for one is true for both. I’m not going to try it because I’ve had my fill of wrecking systems for now, but I thought it was worth asking. If it does indeed wreck things, then it might be a good idea to remove it from the launcher code entirely. It’s less likely someone would run a git pull under launcher, but I could see folks trying to update this way and then getting into trouble. Or is this something that has issues when you change skins back to the old launcher? Or does it work everywhere now? Like I say, I haven’t really followed along closely. But if there is a way to wreck the system conveniently provided in a menu, that’s probably a bad idea.
One more question, though not really a Gameshell specific one… It seems like everyone else is already familiar with the Retroarch XMB interface. I haven’t used it or the other Retroarch menu that much. It seems like the XMB could be pretty powerful, but I confess to not really knowing how to set it up properly, in terms of adding ROMs. For the other version, I always selected a core and then selected a ROM, to launch a game. That felt clunky, and I get the feeling that it could automatically load appropriate cores for ROMs if I set it up properly, possibly even including extra information about the games, etc. Does anyone know of a good tutorial for how to setup and use Retroarch and the XMB interface? Preferably not a video, if possible, as I’d rather read and follow a guide than sit through a long video of someone fumbling through an explanation. I’m not actually looking to do a specific thing here (“OMG run whatever game on Retroarch!”), but instead looking for an overview with enough details to let me explore further if I want. I saw the Retroarch website has a decent high level overview of the interface, but I haven’t really found a sort of “suggested use” walkthrough. And I can’t imagine it’s just going to magically work if it detects ROMs in the correct places. How does it identify them and get the appropriate metadata, etc? What other things need to be set up? I followed along with the development of MAME over the years and am familiar with the ins and outs of it, but I largely ignored Retroarch, and I guess I missed out on seeing it evolve and learning where to look for how to use it and tweak it.
Oh, and by “replace the font”, do you mean track down the file and replace it with the default, or change it in the launcher script? I haven’t gone looking yet, but I assume it would be one of these two options?
Also, some good news… Since I started using DEOT, I took a look at my warehouse stuff with it, and I think I might know what was wrong with it. I think it’s somehow tying the “friendly name” given to the repository to the shell script it tries to launch. I included spaces in the friendly names to make it more legible, but removed them in the directory and script files since spaces are sometimes a bit of a pain in Linux, requiring quotes, etc. I thought only the script name needed to match the directory name, since that was true in the regular launcher menu, but it seems it might be tied to the warehouse name too.
In any case, all the warehouse items I posted do run, but unfortunately not if you run them through the warehouse. (Only Gaurodan and EFMB work that way.) As a test, I ran the file explorer app, and navigated to each script in the warehouse and executed them that way. That worked! Only one game had issues – Rom Check Fail. It runs, but comes up windowed and never seems to get past the black screen. I may have edited my config file to get it to work on my end, and that have to live in ~/.local/share so it’s not included in the warehouse. I’ll figure it out and eventually update these warehouse entries so they work in place. Anyhow, the sort of forced move to DEOT ended up helping me learn more about the warehouse issues too.
I am so moved by your happiness!! This is exactly what I was hoping the DEOT image could do. And ha! I remember the feeling of hosing my entire system, upgrading to Buster. I actually learned a lot more having to do things from scratch.
Speaking of, this image is ACTUALLY 0.5 down to its core; unlike my previous one which was based on the old DEOT V1 image that was essentially an outdated 0.4 image, with a vastly different file structure.
That image had most of the top level launcher items in separate folders etc, and honestly was organised way better. I agree. The top level of this image is insanely busy, mainly attributed to the three “edge lord apps” as I like to call them. I think i will take your advice, and put them in a separate “Extras” or “DEOT” directory.
Now here is the good news! The reason there are so many redundant directories is to keep things 100% workable and error free doing a launcher update!! Yes. You can safely do an update via the settings menu. With my original DEOT v1+ custom image, indeed I did comment out the update section, to avoid people ruining this.
That also brings up the menu items in settings; namely sound and brightness. Indeed they are just the stock ones from stock 0.5 image, just with a colour palette change. I’m limited basically by what I can force to be changed via skin. The original DEOT stock image had an incredibly modified file at /home/cpi/launcher/sys.py/UI/skin_manager.py, including fonts. This possibly ties into why I can’t use the aforementioned settings menu items. They make reference to the EurostileMN font set, which isn’t something that any of the stock images use. (Although, only though you bringing it up did I possibly make the connection!!)
The settings pages are located in /home/cpi/launcher/Menu/GameShell/10_settings/Brightness etc. As you can see, both the skin manager, and settings widgets reside in a location within the /cpi/launcher parent directory, thus making any modifications to the *.py files futile, given the way updates via the settings menu are handled, essentially purging anything within this umbrella parent directory.
I chose to keep it with a white fish background, mainly pertaining to the brightness settings, so while adjusting it, you can actually see a white point changing its brightness. I kept the sound widget the same for consistency, but the more I look at it, the more I feel compelled to change it! The original DEOT one was more of a drawn pygame script, that actually renders the boxes showing levels etc. Things outside the scope of how the skin manages things.
Onto the font! The culprit in question is /home/cpi/skins/DEOT/truetype/VeraMono.ttf
The stock 0.5 skin_manager.py, that will consequently always be overwritten as such via an update only makes reference to: NotoSansCJK, NotoSansMono, VarelaRound, and VeraMono. The DEOT stock image refers to these, AND the EurostyleMN-ExtendedBold and Medium. I had to try and incorporate the font, especially seeing as the chassis of the DEOT edition gameshell heavily features this font as well. Thank you so much for testing it, and discovering that the keyboard clipped over itself. So too did any entries in the foot bar, but I let that one slide, just to incorporate the bold font. For now, I’ve just sadly removed it from most references.
Since I can’t modify the skin_manager.py without it interfering with launcher updates, I have done the cheeky solution of essentially choosing one of the four fonts referenced, deleting it, and renaming one of the custom fonts to it. That’s pretty much how skinners have had to do it.
Currently, VeraMono is actually EurostyleMN-ExtendedBold in disguise. So go ahead and delete VeraMono, duplicate EurostyleMN-ExtendedBold, and then rename it to VeraMono.ttf. That fixes the bug you saw!
Right! So the redundancy re: ChocoDM and the id games! The stock 0.5 contains the wrappers for Heretic, Hexen and Strife in /usr/games, however makes no reference to them in the launcher. They are basically the same thing as the chocoDM wrapper; just catered to the aforementioned games. The ChocoDM wrapper included can manage most WAD files EXCEPT for these ones. I have provided a simple script to launch them on top of the ChocoDM one that’s included, simply because the tutorial that is in the forums refers to some EXTREMELY legacy file locations/structures, and has provided users with errors etc. If I had my own way, I would delete the ChocoDM entry. In fact in my day to day use version, it IS deleted. I have only kept it here to reflect the stock 0.5 config. Sure, I could apt-mark it for exclusion, but I don’t want to be taking TOO MANY liberties with altering the underlying 0.5 code/experience. In fact, if you change the skin to the stock skin, it basically reverts back to a stock 0.5. Handy
I’m glad you’re like me and talk lot. This helps with communication, with how my brain works. You’ve addressed the EXACT problems I’ve had, and I feel that with someone like you onto the case, we’ll be able to get this image EXTREMELY polished!
I’ll talk about retroarch in the next post, just because this is already an essay! I agree with you re: having a text file explaining how things work, over having a video tutorial. I CANNOT stand video tutorials! They run infuriatingly slow, compared to how my brain operates. I have a feeling, re: how much you also talk, you are exactly the same. heh. heh. heh.
Retroarch! It was built using .configure without any parameters defined, to essentially have EVERY possible feature installed. Yes, this makes it bloated and huge. My reasoning for this is, it also makes it an open canvas to test out EVERYTHING. The stock setup had a lot of things disabled; as you would as common practice. This included the XMB menu, which I am extremely fond of. This makes sense, given the previous state of the Lima drivers, essentially making the menu run like a crawl, and overheat the CPU like crazy. Not ideal. Since this was disabled for legacy reasons, i had no idea what else may have also suffered the same fate; thus why not have them all active?
You may notice also, I have copied the entire directory over to .config, including the build directories, and all scripts etc. This is so you can potentially rebuild it yourself as you see fit. It is completely redundant, seeing as I have it installed to the /usr/local/bin directory. The only thing really that is important is the config file, and the directory references to shaders/filters etc that would have needed to be manually moved to /.config/retroarch anyway. I moved the entire build directory over to allow you to have access to every possible thing.
Now. Onto how you can harness the power of the XMB! The first thing I want to point out is that I have altered the file structure of the gameshell rom directories heavily. I found it redundant to have different emulators of the same system refer to different rom directories. I also found it silly to have say gpSP+ refer to a directory called GPSP, as opposed to GBA for containing GBA roms. So I altered all the action.config files to refer to such directories. This directory structure is the same as what a stock retroarch (especially on a retropie) would expect. I did this to make synchronising games/save files between my rpi devices and the cpi more of a 1:1 experience.
With this directory audit also came the location of the retroarch SO files. The stock 0.5 image had them contained in /apps/emulators. The only things I keep in there are standalone emulators.
The problem with the stock 0.5 retroarch installation was that you couldn’t really use it to directly load games, since it didn’t have any directory properly defined for cores. It’s almost like the gameshell wasn’t intended to be used with retroarch as a base; but simply as a SO launcher. Not my cup of tea.
Part of the online updater in retroarch involves doing an “update core info files” - essentially the equivalent of an apt update. This populates whatever you have defined as your core directory with hundreds of .info files, dependent on where you have defined your builedbot URL. Oh so this is embarrassing. The builedbot URL in the version you are using has a typo! It is currently https://buildbot.libretro.com/nightly/linux/arm7-neon-hf/latest/ but should be https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/
I put arm7 instead of armv7. Anyway, either download my updated config, or edit the config file (in .config/retroarch) yourself. (a side note: My laptop is a European model, and thus doesn’t have a tilde key lol. It has a ± in its place. Just assume that I’m putting in the tilde/ before .config)
If I had retroarch refer to the /apps/emulators directory, ie where the SO files are stored by default, you can see how this directory would get flooded very quickly, using the retroarch online updater. As it is set in this OS, retroarch now shares the same locations as the launcher action.config files where applicable. You can download more retroarch cores, and they will be accessible. I have downloaded all of the stock ones in advance. There is a way to manage the cores via the gameshell settings menu, ie core management. Essentially you could delete cores via the gameshell. I originally had to edit the *.py file in /launcher/Menu/settings to reflect my directory change. Unfortunately, this got overwritten in the latest launcher update, and I forgot to restore it. Perhaps I should make a custom line in the script to reapply all my *.py changes. You’re getting me thinking!
The core files are up to date, as of the build date, and running. I have chosen to do this, since future updates to the buildbot repository could see new SO’s that are incompatible with the gameshell, since the stock 0.5 image downloads them on demand.
Now! Just using the XMB interface, you can choose to “Load Content”, and then choose whatever core you want to be the one associated on the ROM. It’s on a per rom basis, and has a list file defining this. It will come up with a list according to what cores you have installed, so go absolutely wild downloading extra cores via the online update>core updater. You can redefine what core your rom uses at any time.
The real beauty of the retroarch XMB interface comes in the form of the playlists function. It will produce a beautiful list, sorted into graphical directories of each of your roms. In addition it will also provide box art, a thumbnail of the title screen, and possibly extra information. You will need to the + sign in the retroarch launcher, and scan your rom directory in order to populate these lists. I like to store all my roms in *.7z and *.zip archives. This scans within these, listing each file contained. Great for when an archive contains a bunch of language, and the first one loaded by default is one you don’t understand! For this reason, scanning can take… hours. I leave mine overnight. This is the reason my first gameshell has an extremely washed out display.
Believe it or not, retroarch WILL in fact magically work, detecting the ROMs in the correct places. It identifies the extensions of the files, and then scrapes the appropriate information it sees them. The only setup is really initiating a scan. In fact, I’m wondering whether or not changing my directory structure to match the file extension, as opposed to the emulator used has anything to do with how it seamlessly integrates and just works.
The only reason I kept up with Retroarch development etc is fact that I delved fairly deeply into the raspberry pi development side of things. That’s actually what I was doing that made me discover the gameshell. I’ve basically jumped boats.
Anyway, I don’t think there’s much else to really say re: how to use it. In theory it should all just be very self explanatory. Just watch out re: stability. Not just in my build, but even in the stock 0.5, there have been reports of retroarch just crashing loading roms. Thankfully just booting back to the launcher, but a bug nonetheless.
This is the majority of what will be included in the next release, so you can apply it to your build 200128 DEOT image. Good news! That means you won’t need to format your card again! I could make a streamlined installation script, but I fear that will break things! Better off doing things by hand, I’d say.
Great! I really appreciate your hard work, when I have time I try to test some things hehe
Well, I still need time now to do what you said on your last post, but will do.
Also, if you could tell me what is the difference between picodrive and picodrive+, and all the rest that are like that, it’s a different core?..whith picodrive the difference that I see is the black bars or the lack of them and see the background of the launcher :S
Hi! I’m glad you’re enjoying the image! I’ve really had a lot of fun putting it together!
Right! So the ones with a + sign after them are cores that run independent of retroarch. That is to say, it’s a standalone emulator. Different roms run better/worse on different combinations.
Some people swear on using standalones only. From my experience, I can’t make a blanket clause to say one does things better than another. Some might run faster. Some might run more accurate. Some might have a higher compatibility rate. Some might have better video or audio. There are just too many combinations!
One thing that is for certain. Standalone emulators start up a lot faster, but I’m talking a saving of 2 seconds. Useful if say, you’re using emulationstation.
The good thing about retroarch emulators (the ones without the + sign) is that to access the menus, state saves, filters etc, they all use the same commands/interface. The standalones are all very different, and require you to have files stored in different locations.
I guess you could almost consider the + versions to be an advanced mode emulator.
On another note, if you don’t want to spend all the time doing the things I wrote out in the post, I’ll be uploading a new image within the next week with all of that applied. I’m just testing it like crazy to make sure I don’t have to upload another one. There were too many tiny niggly things I found I wanted to fix with my last release, that I want to really make sure I get it right this time! Keep in mind, a new image means you’ll need to erase everything and start again from scratch.
Ooook now I get it, well, right now as you said, I pretty used to retroarch so, with the old image, I used to launch retroarch and them move from core to core. I think I will try but for me, its easier to use the ones from retroarch, even though I like how it works mupen with some n64 roms.
Ok well, no problem, I will flash the new one next week, great. I will try to look for bugs or something hehe
And by the way…just if you have the time…how to do to launch Sigil.wad on the DEOT? ChocoDM is compatible with it? I think I will have to make a .sh to launch it, right?
The good news is, the retroarch has been revamped in this image a lot to allow it to be used almost exclusively. That’s the positive. With this come a slightly longer load up time, and potentially laggier interface. That’s part of the reason people may opt to use the standalones.
I would very much love it if you could test things out for bugs! In fact, I have a copy that has all of the stuff from that previous post applied I can whip up straight away, if you’re keen to just test things out right away. Let me know! (please!!)
Re: Sigil.wad, Surprise! The chocoDM in the launcher should run it, as long as you put it in the /home/cpi/games/chocoDM directory. It should appear in the list.
Otherwise, if you’re really into doom (judging by your avatar haha) check out this post that @Lix made, re: installing zdoom. You don’t need to necessarily use it with brutal doom. It’s a solid custom wrapper that runs a whole heap of things. I’m almost tempted to include it with this custom image, as a replacement for the chocoDM wrappers. Let's play Brutal Doom!
Well, I don’t want to put me in between a rock and a hard place, but I’m going to try some things with this version and hope to tell you something in the next 24h.
Yes I’m a big Doom enthousiaste
Talking about Sigil and chocoDoom, right now I do have these wads in /home/cpi/games/chocoDM:
HELL2PAY.WAD (W_GetNumForName: genmidi not found!)
PERDGATE.WAD (W_GetNumForName: genmidi not found!)
sigil.wad (Unknown or invalid IWAD file)
SIGIL_COMPAT.wad (Unknown or invalid IWAD file)
The ones working are (the others I did put up in brakets the error tha throws):
doom.wad (same as ultimate, just with different name just in case)
I did went to see the Let’s play Brutal Doom! and I’m stuck in the step:
cmake … -DNO_FMOD=ON
I do get this error:
CMake Error: The source directory “/home/cpi/zdoom/build/…” does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
I don’t know how to continue, but the home/cpi/zdoom/build directory exists.
Talking about other things.
Why is the somethings in japanese? Chinese? In Mail, Operation and Manual.
By the way, what are those?
Ok I did what you said, but still nothing, same error…and i’m in the folder…so, can’t do step 4 with the CMAKE…Also I saw what Javelinface said, that it’s possible to don’t do those steps, but I don’t get what is suppose to be the next step in his answer :S
I might include a fully configured zdoom in my next release. ;).
The tutorial from @lix is missing the install step, and leaves the build files and sources behind, so is a bit messy. I’m a bit OCD when it comes to leaving “dirty dishes” in my launcher. (And in real life!)
Back on topic. The things in Japanese (it’s actually Chinese) are the DEOT exclusive extra apps/games. I call them the edge lord apps. They’re purely decorational, and exist to make it feel like you have some kind of 1337 underground hacking unit. Nonetheless they’re things featured in the stock DEOT OS, and things that make that OS special.
You can honestly ignore them if you want, and even delete them. Since they take up so much space visually, I am going to put them in their own folder in future. I provided instructions above on his to do this.
This script is specifically for my DEOT v2 200128 build, and uses the directory structure for the launcher items, ie, Retro Games>id>zdoom. It has the DEOT style icon to match.
It’s the same as what I’d be including in a future update, basically; if I decide that it’s something worth including.