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.9.0, Mupen64+ plus more! (Current build: 200903)

GameShell Firmware and Apps
, , , ,
61

Here we go! Build 200128!

As of 28th of Jan 2020:

  1. Massive over haul of icons to be unified. Theme also tweaked slightly, including scroll bar colour, updated fonts, and customisation to settings widgets.
  2. Retroarch updated to 1.8.4, and configuration file rebuilt from scratch to be slightly more optimised. Mame directional controls and input addressed, adding the user cpi to input group, and controls predefined. All assets, shaders etc downloaded.
  3. Battery monitor app installed to the Utils directory.
  4. Mupen64+ rebuilt with some minor tweaks to the installation script.
  5. The .xinitrc file has had legacy file location entries removed, as they were unused. Just a cleanup. Thanks @Petrakis for the tip.
  6. Choco wrappers have been tidied up and unified, with individual icons installed for each. You will need to provide your own WAD files to run it.

As usual, this will come out in two staged forms. The first one, now, will be a larger compressed file that will expand to 16GB. It is annoyingly cumbersome I am afraid, however since I donā€™t have a valid pure linux computer to work from (Iā€™m just running small VMs) I donā€™t have the capacity to edit an image accordingly. I ask @guu to usually help me with this, then provide link to it shortly afterwards.
Likewise, it wonā€™t be automatically expanding, and will require you to do so via a small script I have included in the Utils folder.

The second staged release will have all of the above applied, if @guu is happy to give his time to my cause.

@Wizz I will let you know as soon as I have a good distributable copy when I can send you the file to host on your european server! As usual, I thank you whole heartedly. :slight_smile:

I will provide links as they come up. Watch this space!
And again, let me know if there are any issues, or requests.

The google drive link from the first post should still be valid. Iā€™ll post a link to the mega upload in the morning when I wake up.

Hereā€™s the mega link!
https://mega.nz/#!U65wkIZa!gOtV_KrpMIz2lOIv4pPrMimrT8j-1nQ3RBtGg8bhiUU
@Wizz @guu

2 Likes
62

Cool ! Iā€™ll be ready !

1 Like
63

Alright I decided to use your os image (amazing work btw) but most of the emulation has screen tearing, is there anyway to fix it? @javelinface

1 Like
64

I think the screen tearing is something that has been around for a while. Is it like a ripple that goes across the screen occasionally? Also is this something also inherent in the stock 0.5 image? The main difference Iā€™ve applied is installing Retroarch 1.8.4 (updated) and configuring it differently.

There is something else that you can try that Iā€™ve had to input different settings for on my two game shells.
This is in Retroarch.

  1. Go into settings>video>output
  2. Scroll down to the vertical refresh rate section.
  3. You will see a flickering estimates refresh rate. Potentially adjust your refresh rate to match that, taking small steps and comparing results.
  4. The reported set display refresh rate seems to be the same; 59.794. Thatā€™s what I have it set to as a base line.
  5. Go back, and enter synchronisation, and make sure V-Sync is turned on.
  6. Optionally turn on hard GPU sync, and Sync to exact content frame rate.
  7. If youā€™re using content that is being significantly scaled up, but not using an exact whole number integer value, go back and select Bi-linear filtering.

Thatā€™s a few options you can enable. I favoured frame rate and sound quality over the mild screen tearing that I learned to live with, which is why I chose the settings I did.

Which games were you experiencing tearing with? And which emulator/core?

3 Likes
65

Just the ones you had in place @javelinface

66

Waitā€¦ did I accidentally include games? Oh dear.
Well besides cave story and the ones included in Indie Games.
Cave story, 2048 and Nyan use Retroarch, so the instructions above should be valid.

This is cave story running fairly smoothly imho. Itā€™s using Retroarch settings.
https://share.icloud.com/photos/0zeV649Pr0Oq6HmpMqnxylyOA

Hereā€™s mother 3 using gpsp. Normally you get a lot of tearing with big map changes like this, but everything seems okay.
https://share.icloud.com/photos/0huEo4oeriN1yW-nEbErtcTKg

Hereā€™s tales of phantasia using pcsx+. This is what I think when people say tearing. This one canā€™t be helped. Yet.
https://share.icloud.com/photos/0OWSpEMiQTKvknox3J61SmHeg

67

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
68

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:

69

Ended up doing what you recommended it worked

1 Like
70

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.

71

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.

image
image4032Ɨ3024 3.03 MB

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.

72

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

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.)

73

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!

74

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:

75

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.

76

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

2 Likes
77

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

image
image3024Ɨ4032 3.01 MB

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.

2 Likes
78

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.
Apps: 40_D.E.O.T. Extra.zip - Google Drive
Updated Skin: DEOT Skin.zip - Google Drive

  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

/home/cpi/launcher/Menu/GameShell/10_Settings/Cores/__init__.py

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 UI.page   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):
            self.ReturnToUpLevelPage()
            self._Screen.Draw()
            self._Screen.SwapAndShow()

        if IsKeyStartOrA(event.key):
            self._Screen._MsgBox.SetText("Applying")
            self._Screen._MsgBox.Draw()
            self._Screen.SwapAndShow()
            
            pygame.time.delay(638)
            
            self.CallbackA()
            
            self.ReturnToUpLevelPage()
            self._Screen.Draw()
            self._Screen.SwapAndShow()
    
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   = ["chailove_libretro.so","nxengine_libretro.so"]
    
    def __init__(self):
        Page.__init__(self)
        self._Icons = {}
        
        if "arm" in platform.machine():
            pass
        
    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:
                continue
            
            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 = fp.read()
                    alias = alias.strip()
                    label_text = alias.decode("utf8")
                    li.Init( label_text )
                    fp.close()
                else:
                    li.Init( os.path.basename(v) )
                li._Flag = v
                ##li.SetSmallText( v )
                
                self._MyList.append(li)
                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._Scroller.Init()
        
        self._ConfirmBox = DeleteCoreConfirmPage()
        self._ConfirmBox._Screen = self._Screen
        self._ConfirmBox._Name = "Confirm to Delete?"
        self._ConfirmBox._Parent = self
        self._ConfirmBox.Init()
        
    def ReScan(self):
        self.GenList()
        self.RefreshPsIndex()
      
    def ConfirmBoxCallbackA(self):
        if len(self._MyList) == 0:
            return
            
        cur_li = self._MyList[self._PsIndex]
        
        os.system("rm %s" % CmdClean(cur_li._Flag))
        self.GenList()
        self.RefreshPsIndex()
        
    def OnLoadCb(self):
        self._Scrolled = 0
        self._PosY = 0
        self._DrawOnce = False    
        self.GenList()
    
    def OnReturnBackCb(self):
        pass
        
    def KeyDown(self,event):
        if IsKeyMenuOrB(event.key):
            self.ReturnToUpLevelPage()
            self._Screen.Draw()
            self._Screen.SwapAndShow()
        
        if event.key == CurKeys["X"]: #Scan current
           self.ReScan() 
           self._Screen.Draw()
           self._Screen.SwapAndShow()
                       
        if event.key == CurKeys["Y"]: #del
            if len(self._MyList) == 0:
                return
            
            self._ConfirmBox.CallbackA = self.ConfirmBoxCallbackA
            
            self._Screen.PushPage(self._ConfirmBox)
            self._Screen.Draw()
            self._Screen.SwapAndShow()
            
        if event.key == CurKeys["Up"]:
            self.ScrollUp()
            self._Screen.Draw()
            self._Screen.SwapAndShow()

        if event.key == CurKeys["Down"]:
            self.ScrollDown()
            self._Screen.Draw()
            self._Screen.SwapAndShow()

 

    def Draw(self):
        self.ClearCanvas()

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


class APIOBJ(object):

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

OBJ = APIOBJ()
def Init(main_screen):    
    OBJ.Init(main_screen)
def API(main_screen):
    OBJ.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:
ROM=/home/cpi/games/MegaDrive 
ROM_SO=/home/cpi/.config/retroarch/cores/picodrive_libretro.so 
EXT=bin,zip,gen,32x,smd,iso,7z 
LAUNCHER=retroarch -L 
TITLE=PicoDrive Roms 
SO_URL=ttps://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/picodrive_libretro.so.zip
  1. Reload the launcher, then attempt to run a game with Picodrive. It should update to the latest version.
5 Likes
79

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
80

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