clockworkpi

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)

OH HAHAHA!! I thought you were referring to the .xinitrc in the /home/cpi/launcher!
I must have skimmed past it potentially being in /home/cpi/apps/launcher, since nothing should be there!
If there’s been pull request, it should be something that will be updated in the next git update. I’ll still get rid of it, now that I know that it’s a thing! It will haunt me if I don’t!
Thanks for letting me know about twm too. There seems to be a lot of unused assets. Thanks for looking out and cleaning them.

There are god knows how many leftover bits and pieces all over the place, like the /opt file that looked like leftover configs from an Emulation Station port attempt.
Then there’s all the leftover configs in /home/cpi/ like the .gnukem/, .hurrican/, .hydrascastlelabyrinth/ etc. I am half tempted to delete most of them, but fear doing so in case a) they’re somehow for a custom configuration, b) there are future plans for it, or c) if it is something that someone out there will be disappointed in seeing gone.
I would love to take part in an extensive audit of the entire structure of the gameshell OS.
You think that would be a worthwhile topic you’d be wanting to partake in, as a new thread? Or is it easier to submit pull requests? I guess it would come down to whatever the devs notice more readily.

My pull request does not contain that removal, as my pull request is cleaning the launcher, but that file comes from the iso file, so it can´t be removed with a pull request.

Apart from that, my pull request is not merged :stuck_out_tongue:

Edit:

but that file comes from the iso file, so it can´t be removed with a pull request.

I mean, its outside the git repo

1 Like

Right! Gotcha! I see what you mean, what with both entries being things that have moved. That said, I guess it’s still good for the loading.png screen - OH WAIT, that’s also referring to a legacy location.

~/apps/launcher/sys.py/gameshell/wallpaper/loading.png

You’re absolutely right. The .xinitrc file is completely useless. Wow. :smiley:

Its small things that I find while developing that get me confused until I realize what is going on.

1 Like

Yeah! It caught me off guard, having to do a double take.
If you catch any more in future, I am more than happy to take them on.
Also, if there are any other relics from the past that you know for certain are cull worthy, I’d love to know.
Since a lot of these are outside of the launcher git-pull request realm, is there any effective channel to communicate this to any of the devs? Things like the legacy file paths you mentioned, and the leftover directories/config files I mentioned earlier.

Ahem. Back on topic.
Another thing updated that I’ll be adding to the next release. Icons for the individual ID software WAD files. You’ll still need to provide your own WAD files in the /games/ChocoDM directory, but at least they’re a bit neater now, and matching the DEOT theme.

https://drive.google.com/open?id=1PqpKUqHEqLttI3hvYGP4aZsz9j54cuvD
Just move this to the /home/cpi/apps/Menu/20_Retro Games/ directory, and remove the

/home/cpi/apps/Menu/20_Retro Games/05_ChocoID directory.

I couldn’t work out how to have these applied to the skin file, and instead just put the icons in the same directory as their corresponding script.

These are such small updates, that I’d almost be inclined to say that they’re easy enough to do yourself to your existing installation, so you don’t need to wipe your card.

Other things I’ve done are just cleaning up the mupen.sh script a bit. It had a lot of superfluous parameters. I’ve also updated to Retroarch 1.8.4, but honestly I can’t notice any groundbreaking differences. It’s mainly pertaining to multi disk games, but personally that only applies to playstation games, and I normally just use the standalone PCSX+ emulator. If you so update to 1.8.4, here’s the config than I had to remake:

Oh and of course, the battery monitor! In the skin file Skin Development! I have included a themed DEOT coloured battery monitor. I have however moved it to the Utils directory, since the home screen was messy enough as is!

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

Cool ! I’ll be ready !

1 Like

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

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

Just the ones you had in place @javelinface

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

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

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: