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)

Yes it can! It is based on 0.5, and won’t need to be updated.

This is assuming things stay the same re: updates only applying to items in the ~/launcher directory.
If it updates anything in the ~/apps or ~/games directory, things might get a bit hairy. But precedence says that it should stay the same.

You may just lose the custom splash screens. I removed the custom settings menu items for this reason. I will mark the files in future to not be changed, if it becomes an issue.

@gordi711 I suppose this applies to your query too.
Everything the official 0.5 image does, this image will also do. It IS the 0.5 image essentially.

So what are the commands to update without erasing everything on my gameshell

@javelinface

1 Like

Sorry, I wasn’t 100% onboard with what you meant.
My reading was that you were asking if a fresh image can be updated to the latest firmware, as if you were using 0.5.
Re: upgrading from 0.4 to this; Yes it can, but I decided not to include this, given the problems users had with the stock 0.4 to 0.5 update, with slightly different systems, modifications and states of files.
I made this image initially to help people install standard updates/modifications that should be fairly straightforward, but due to differing configurations, people had trouble with. Remember when I was trying to help you get mupen64plus set up? That kind of troubleshooting.
Having an update script would no doubt lead to every post in this thread being someone having trouble applying it, and having to differentiate between user error, configuration error, or something on my end; especially given the nature of some of the modifications to system files.
I hope you can understand why I chose to omit this.
If I was to do an update, it would be one directly applicable to users who have used this custom OS as a base.

In short, were you actually asking the same thing as this post?

Oh ok, yeah that was not fun
Alright so how do I update from OS.V4 to OS.V5?

Have a quick read of my last post again. :slight_smile:

If you’re talking about the stock 0.4 to 0.5, have a look at the official thread. But please read through the posts. You may run into some problems. It’s definitely targeted at the more advanced user:

I don’t have a single scripted process made. I would have to run you through every single change.

Part of the process would involve doing exactly what I was trying to help you with re: mupen64plus. I did the exact same process. That was the easy part.

I have decided to not include any instructions on how to do it, but instead have links to all of the components I used for people to put together themselves.

As per @HalfBlood’s response in another thread, you can see why I have steered clear of having an upgrade patch from other versions:

As a small update that you can apply now (and will appear in the next release), here is an updated skin for the DEOT OS. Unifies the launcher icons to use the hexagonal blue filter.
Just decompress the archive, then put it in the skin folder.
https://drive.google.com/drive/folders/1wEH8P9faECjj6glUlRWQkSsSyWo0FjQW?usp=sharing

N.B. The OpenTyrian and GSPLauncher icons have their own icon in the /apps/Menu/21_Indie Games directory that override any icons changes in the skins, so you’ll need to change that one manually. Likewise with DinguxCommander in the utilities directory.

This should also update the fonts, masquerading as the set system fonts. The splash screens, and wallpaper should also be updated to the DEOT standard.

I have posted this in the skin development thread, since I figured it should be placed in the correct place if it is to have any direct discussion pertaining to it.

@Petrakis Just wondering, what was needing to be fixed/removed with exec ~/apps/launcher/load.sh & line in the .xinitrc file? Was it just removing the line?
I haven’t modified the .xinitrc from the stock 0.5, so may need to mark it to avoid any changes I’ve made being overwritten by an update.
Thanks in advance!

Basically ~/apps/launcher/load.sh its a legacy path, it doesn´t exist anymore

1 Like

Hmm, I may need some elaboration. Both of those files and paths seemingly exist in my installation, based on 0.5

Currently .xinitrc looks like this:

feh --bg-center ~/apps/launcher/sys.py/gameshell/wallpaper/loading.png 
exec ~/apps/launcher/load.sh &
exec ~/apps/twm.mod

So I removed the line referencing the legacy load.sh path, like this:

feh --bg-center ~/apps/launcher/sys.py/gameshell/wallpaper/loading.png 
exec ~/apps/twm.mod

All started up normally.

I then thought to remove the ~/apps/launcher/load.sh file, thinking that it would be unused, however this resulted in being unable to load the launcher.
I replaced the file, changing the mode to rwxr-xr-x, and everything went back to normal.

So from what I can gather, it seems safe to remove the reference to it in startup in .xinitrc, however it may still be being used by another start up process.

That aside, I haven’t noticed that much difference in performance or startup time removing the line from .xinitrc. Was there any other benefits to doing so, besides keeping things clean?

image

there is nothing in apps. I think that xinitrc is currently useless as we use the one in /home/cpi/launcher

Also twm is something that is not used anymore. Refer to my pull request

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