Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.7, Optional 1400MHz OC, Debian 10 Buster, Retroarch 1.8.9, Mupen64+ plus more! (Current build: 200626)

No you didn’t haha, it’s my own, I meant the emulator itself that was already built in, I put MY own roms @javelinface

1 Like

PHEW! I was freaking out for a moment there! Which emulators and roms were you talking about? And had you tried using them in any previous OS’s, and did they have the same tearing? I’ve got a stock OS 0.5 I am itching to cross reference/check things with. Nothing should be too different, so reports like this get me thinking! :smiley:

Ended up doing what you recommended it worked

1 Like

Fantastic. Just watch out. Especially for some Mame games, you might end up with the sound crackling a bit.
That said, if you don’t use Mame, then you don’t have anything to worry about. :slight_smile:

Here’s an updated retroarch.cfg file with the above changes, as well as a few other things cleaned up.
Note: you’ll need go change the cheevos login to your own if you want to keep track of achievements.

In my own day to day build, I have installed a bunch of extra standalone emulators, namely ohboy, fceux, picodrive stand-alone, heretic, hexen, strife, quake 2, and have also installed PokeMMO.

I have installed the emulationstation GUI, and have had it set up to primarily use these standalone cores.
The question is, for a public release, would this be considered too much bloatware, and better off kept to my own personal use?

Vote for any that you use, or would like to see in the next build.

  • Ohboy
  • Fceux
  • Standalone Picodrive
  • PokeMMO
  • Heretic, Hexen, Strife
  • Quake II
  • Configured Emulationstation

0 voters

Keep in mind, you will still need to provide your own data files etc for the games that need them.
If there’s anything you would like to see removed, let me know.

If you just want say emulationstation, you can just add it to your existing build without having to wipe everything. Mind you, this configuration I made was for a stock 0.5 image. I have altered the rom location in my build.

Something I noticed right after I installed deot_V2+ 200128.img.bz2 and set up wifi – the keyboard doesn’t fit the screen and is garbled.

Here’s a screenshot:

It seems like the left side is drawn over the top of the right side.

(It’s still usable though, just doesn’t look as nice as it might.)

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. :wink:

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. :wink: 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. :frowning:

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/, 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. :frowning:
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, 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 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. :wink: So go ahead and delete VeraMono, duplicate EurostyleMN-ExtendedBold, and then rename it to VeraMono.ttf. :slight_smile: 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 :wink:
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 but should be
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. :frowning:

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. :slight_smile:
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. :wink:

As per @adcockm 's suggestion re: cleaning up the DEOT apps, I have updated some files.
Download and decompress these.
Updated Skin:

  1. Go into /home/cpi/apps/Menu and delete the existing 41_MANUAL, 42_OPERATION, AND 43_MAIL directories.
  2. Copy the new 40_D.E.O.T. Extra folder to /home/cpi/apps/Menu
  3. Copy the DEOT skin folder into /home/cpi/skins, overwriting the existing one. This updated skin also addresses the font graphical errors.

Again, thanks @adcockm :slight_smile:

While I’m here, don’t forget to update to this version of retroarch.cfg. I made a small typo in the buildbot URL.

Also, if you want the Retroarch cores manager in the gameshell launcher’s setting menu to function, update


with this:

# -*- coding: utf-8 -*-

import os
import platform
import pygame
import glob
#import math
import  commands

#from beeprint import pp
from libs.roundrects import aa_round_rect
#import gobject
#from wicd import misc 
## local UI import
from UI.constants import Width,Height,ICON_TYPES
from   import Page,PageSelector
from UI.label  import Label
from UI.util_funcs import midRect,FileExists,IsExecutable,ArmSystem,CmdClean
from UI.keys_def   import CurKeys, IsKeyStartOrA, IsKeyMenuOrB
from UI.scroller   import ListScroller
from UI.icon_pool  import MyIconPool
from UI.icon_item  import IconItem
from UI.confirm_page import ConfirmPage
from UI.multi_icon_item import MultiIconItem
from UI.lang_manager  import MyLangManager
from UI.multilabel import MultiLabel
from UI.info_page_list_item import InfoPageListItem
from UI.info_page_selector  import InfoPageSelector
from UI.skin_manager import MySkinManager

class DeleteCoreConfirmPage(ConfirmPage):
    _ConfirmText = MyLangManager.Tr("Awaiting Input")
    _FootMsg = ["Nav","","","Cancel","OK"]
    CallbackA = None
    def KeyDown(self,event):
        if IsKeyMenuOrB(event.key):

        if IsKeyStartOrA(event.key):
class CoresPage(Page):
    _FootMsg =  ["Nav","Del","Scan","Back",""]
    _MyList = []
    _ListFontObj = MyLangManager.TrFont("varela13")
    _AList = {}

    _Scrolled = 0
    _BGwidth = 320
    _BGheight = 240-24-20

    _DrawOnce = False
    _Scroller = None

    _EasingDur = 30
    _CORES_PATH = "%s/.config/retroarch/cores" % os.path.expanduser('~') 

    _Config =None
    _AllowedExts = [".so",".bin"]
    _HiddenSos   = ["",""]
    def __init__(self):
        self._Icons = {}
        if "arm" in platform.machine():
    def GenList(self):

        self._MyList = []
        ## map ini to self._AList
        files_path = glob.glob(self._CORES_PATH+"/*")
        start_x  = 10
        start_y  = 0
        counter = 0 
        for i,v in enumerate( files_path):
            if os.path.basename(v) in self._HiddenSos:
            filename, file_extension = os.path.splitext(v)

            alias_file = filename+file_extension + ".alias"
            if file_extension in self._AllowedExts:
                li = InfoPageListItem()
                li._Parent = self
                li._PosX   = start_x
                li._PosY   = start_y + counter*InfoPageListItem._Height
                li._Width  = Width-10
                li._Fonts["normal"] = self._ListFontObj
                li._Fonts["small"] = MySkinManager.GiveFont("varela12")
                li._ReadOnly = True
                if os.path.isfile(alias_file):
                    fp = open(alias_file, "r")
                    alias =
                    alias = alias.strip()
                    label_text = alias.decode("utf8")
                    li.Init( label_text )
                    li.Init( os.path.basename(v) )
                li._Flag = v
                ##li.SetSmallText( v )
                counter += 1
    def Init(self):
        if self._Screen != None:
            if self._Screen._CanvasHWND != None and self._CanvasHWND == None:
                self._CanvasHWND = self._Screen._CanvasHWND

        self._PosX = self._Index*self._Screen._Width 
        self._Width = self._Screen._Width ## equal to screen width
        self._Height = self._Screen._Height

        ps = InfoPageSelector()
        ps._PosX = 11
        ps._Parent = self
        ps._Width = self._Width-10
        self._Ps = ps
        self._PsIndex = 0

        self._Scroller = ListScroller()
        self._Scroller._Parent = self
        self._Scroller._PosX = 2
        self._Scroller._PosY = 2
        self._ConfirmBox = DeleteCoreConfirmPage()
        self._ConfirmBox._Screen = self._Screen
        self._ConfirmBox._Name = "Confirm to Delete?"
        self._ConfirmBox._Parent = self
    def ReScan(self):
    def ConfirmBoxCallbackA(self):
        if len(self._MyList) == 0:
        cur_li = self._MyList[self._PsIndex]
        os.system("rm %s" % CmdClean(cur_li._Flag))
    def OnLoadCb(self):
        self._Scrolled = 0
        self._PosY = 0
        self._DrawOnce = False    
    def OnReturnBackCb(self):
    def KeyDown(self,event):
        if IsKeyMenuOrB(event.key):
        if event.key == CurKeys["X"]: #Scan current
        if event.key == CurKeys["Y"]: #del
            if len(self._MyList) == 0:
            self._ConfirmBox.CallbackA = self.ConfirmBoxCallbackA
        if event.key == CurKeys["Up"]:

        if event.key == CurKeys["Down"]:


    def Draw(self):

        if len(self._MyList) > 0:
            for i in self._MyList:
            self._Scroller.UpdateSize( len(self._MyList)*InfoPageListItem._Height,

class APIOBJ(object):

    _Page = None
    def __init__(self):
    def Init(self,main_screen):
        self._Page = CoresPage()
        self._Page._Screen = main_screen
        self._Page._Name ="Retroarch cores manager"
    def API(self,main_screen):
        if main_screen !=None:

def Init(main_screen):    
def API(main_screen):

For consistency, I have also modified the Picodrive retroarch action.config to download from the buildbot URL.

  1. After doing the above edit to the settings menu, reload the launcher, and then run the Retroarch cores manager.
  2. Delete the picodrive for gameshell SO file.
  3. Go into /home/cpi/apps/Menu/20_Retro Games/50_PicoDrive and edit the action.config file to contain this:
LAUNCHER=retroarch -L 
TITLE=PicoDrive Roms 
  1. Reload the launcher, then attempt to run a game with Picodrive. It should update to the latest version.

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

And again, thanks!

1 Like

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.

1 Like

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?

1 Like

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 :stuck_out_tongue:

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?

you have to be in the folder to cmake FMOD.
so: cd /home/cpi/zdoom/build/
And that is if you created the folder in the first place. I feel like you missed a step or two.

Ok I just read that the folder exist…
Then maybe erase everything and try again. It might be a permission issue…

Also, read what Javelinface wrote to me below my tutorial, the build process can be simplified.

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

The issue you have is with the step 3… On which GS OS are you? 0.3, 0.4, 0.5 ?
Try another method just to see if it help, you will still have to do the other steps though.
Erase everything again.

git clone

cd zdoom

cmake . -DNO_OPENAL=ON

make -j4

1 Like