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)

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:
doom2.wad
doomu.wad
doom.wad
freedoom1.wad
freedoom2.wad
HELL2PAY.WAD (W_GetNumForName: genmidi not found!)
PERDGATE.WAD (W_GetNumForName: genmidi not found!)
plutonia.wad
sigil.wad (Unknown or invalid IWAD file)
SIGIL_COMPAT.wad (Unknown or invalid IWAD file)
tnt.wad

The ones working are (the others I did put up in brakets the error tha throws):
doom2.wad
doomu.wad
doom.wad (same as ultimate, just with different name just in case)
freedoom1.wad
freedoom2.wad
plutonia.wad
tnt.wad

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 https://github.com/rheit/zdoom.git

cd zdoom

cmake . -DNO_OPENAL=ON

make -j4

1 Like

Ok great, now it’s working, thanks!

I have to write down all the steps hehe

1 Like

I might include a fully configured zdoom in my next release. ;).
The tutorial from @lix is missing the install step, and leaves the build files and sources behind, so is a bit messy. I’m a bit OCD when it comes to leaving “dirty dishes” in my launcher. (And in real life!)

@lix that step you mentioned above:

cmake .   **-DNO_OPENAL=ON**

It disables openal. Are you sure you want that? Also I think it needs a double dot.
There’s a typo in your code re:

You have three dots (…)
It’s meant to have two dots (..)

I’ve made a rough script to automate it all for you. It installs to the launcher’s home screen, so move it to wherever you want afterwards.

wget -O /home/cpi/zdoom.sh https://www.dropbox.com/s/j2fu7twdrw7ec72/zdoom.sh?dl=1
chmod +x /home/cpi/zdoom.sh
./zdoom.sh

Anyway probably better to take all this discussion to the right thread. This is getting a bit off topic.

Back on topic. The things in Japanese (it’s actually Chinese) are the DEOT exclusive extra apps/games. I call them the edge lord apps. They’re purely decorational, and exist to make it feel like you have some kind of 1337 underground hacking unit. Nonetheless they’re things featured in the stock DEOT OS, and things that make that OS special.
You can honestly ignore them if you want, and even delete them. Since they take up so much space visually, I am going to put them in their own folder in future. I provided instructions above on his to do this.

1 Like

This script is specifically for my DEOT v2 200128 build, and uses the directory structure for the launcher items, ie, Retro Games>id>zdoom. It has the DEOT style icon to match.
It’s the same as what I’d be including in a future update, basically; if I decide that it’s something worth including.

wget -O /home/cpi/zdoom.sh https://www.dropbox.com/s/l850wpc7pxtoexh/zdoom_deot.sh?dl=1
chmod +x /home/cpi/zdoom.sh
./zdoom.sh

Edit:
Here’s a great addition to allow you to select base game and mod independently! :slight_smile:

1 Like

Ok thanks for the explanation I didn’t know that about the image.

Nice if you could include it (zdoom) on the image.

I think pretty much all is looking good, I think the next release will be a great step further. Maybe I will change to be my main SD card.

Talking about retroarch, I think, well for me in this little screen, I will stick to the rgui interface, just to read better all the menu and options.

1 Like

Thanks! That’s a huge compliment! Essentially, it is still the same as the stock 0.5 image, just with periodically maintained additions, and the assumption that I know people who have my image have things set just the way I know I put them on mine. In reality, it’s a way to make helping people slightly easier.

I’ll have to run a poll to see if anyone else would want zdoom. The last thing I want to do is include too much bloatware. If it’s just as easy to provide an installation script for optional items, I’ll just write them out instead.

Re: the XMB interface being too small, give this a go:

  1. Open retroarch, with the XMB interface enabled
  2. Go to the settings page, and select User Interface
  3. Scroll down and select Appearance
  4. Adjust the Menu Scale Factor left and right.

I found that 1.00 scale was a good enough readable resolution, while still being able to see the general menu layout.

1 Like

Yes, good idea those scripts for optional items like zdoom if it doesnt get votes.

Thanks, the scale I got is the same you say, just me being a bit picky hehe.

Also, just for imformation for others, I think it’s problem of the base image 0.5.
I tried Blood and Shadow Warrior and works on the FBTURBO driver. Not on LIMA.
But Duke Nukem 3D works on LIMA.

1 Like

Thanks for testing that! I hadn’t actually tried either of them, since 0.5 hit! Good to know!
Just to add to the list, the same thing can be said about Quake 1 (quakespasm). The menu alone loads up all glitchy. It runs, just with a lot of graphical glitches. You’ll need to use the variable -nomtex to get it running on Lima.
Runs like a train stuck in a blender using Lima.
Runs like a train with spaghetti stuck in its wheels using FBTurbo.
Basically, either way, it doesn’t really run desirably well.
Strangely enough, Quake II (Yamagi)works AMAZINGLY well using the Lima drivers. Like. Buttery and smooth.
I was hoping to do away with having to use the FBTurbo drivers, but looks like we still have a use.

1 Like

The next thing I’m undertaking is re-ordering the .config/retroarch directory to be WAY more streamlined, and correct.
Currently in the config, there are a lot of defined directories. I don’t think anyone has actually come to some logistical consensus of what and where everything should be, considering most of them haven’t been defined by default. I’m hoping to change that, at least using the structure I have in place as a base.

This is what it currently looks like
core_updater_buildbot_assets_url = "http://buildbot.libretro.com/assets/"
core_updater_buildbot_cores_url = "http://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/"

system_directory = "~/apps/emulators/bios"
libretro_directory = "~/.config/retroarch/cores"
libretro_info_path = "~/.config/retroarch/cores"

assets_directory = "~/.config/retroarch/assets"
core_assets_directory = "~/.config/retroarch/assets"
cheat_database_path = "~/.config/retroarch/cheats"

runtime_log_directory = "~/.config/retroarch/logs"
log_dir = "~/.config/retroarch/logs"

content_database_path = "~/.config/retroarch/database/rdb"
joypad_autoconfig_dir = "~/.config/retroarch/autoconfig"

rgui_browser_directory = "~/.config/retroarch"
rgui_config_directory = "~/.config/retroarch/config"

audio_filter_dir = "~/.config/retroarch/libretro-common/audio/dsp_filters"
video_filter = "~/.config/retroarch/gfx/video_filters/Scanline2x.filt"
video_filter_dir = "~/.config/retroarch/gfx/video_filters"
video_shader_dir = "~/.config/retroarch/shaders/shaders_glsl"
video_layout_directory = "~/.config/retroarch/layouts"
overlay_directory = "~/.config/retroarch/overlay"

playlist_directory = "~/.config/retroarch/playlists"playlist_entry_remove_enable = "1"
content_favorites_path = "~/.config/retroarch/content_favorites.lpl"
content_history_path = "~/.config/retroarch/content_history.lpl"
content_image_history_path = "~/.config/retroarch/content_image_history.lpl"
content_music_history_path = "~/.config/retroarch/content_music_history.lpl"
content_video_history_path = "~/.config/retroarch/content_video_history.lpl"

screenshot_directory = "~/.config/retroarch/screenshots"
thumbnails_directory = "~/.config/retroarch/thumbnails"
recording_config_directory = "~/.config/retroarch/records_config"
recording_output_directory = "~/.config/retroarch/records"
menu_wallpaper = "~/skins/DEOT/sys.py/gameshell/wallpaper/desktopbg.jpg"

input_remapping_directory = "~/.config/retroarch/config/remaps"

savefile_directory = "default"
cursor_directory = ""
dynamic_wallpapers_directory = ""
cache_directory = ""
resampler_directory = ""
bundle_assets_dst_path = ""
bundle_assets_dst_path_subdir = ""
bundle_assets_src_path = ""
content_history_dir = ""
core_options_path = ""

Here’s the entire config
I’ve just reshuffled like config items together to make it easier to think.

There are a lot of gaps that can be defined. Furthermore, the stock image has a lot of extra directories and files residing in .config/retroarch that unless they’re referenced in the config, probably can be removed. I’ll have to see what else ie loaded when running retroarch from /usr/local/bin, but I’m fairly confident that it shouldn’t be too much.

If at least we have all the directories defined along with key bindings, we should be able to make a script to amend a stock retroarch config, making it a far less menial process, when we need to update retroarch. I’ve had far too many bad experiences with using an old config in a newer build to dare risk just copy pasting my existing one.

Speaking of, I’ll probably write up small scripts to update the existing DEOT OS v2 to whatever the current version is, as well as provide a pre made image, just for the current and last image. That way, having to wipe your image every time shouldn’t have to happen. Fingers crossed.

3 Likes

@javelinface check this about twm https://github.com/clockworkpi/launcher/pull/309#issuecomment-583981387

1 Like

Oh snap! Thanks for the heads up @Petrakis!
Applying this on the stock image might end up being a case of another update, ala the 0.4-0.5 route. There may be a few people who could have difficulty with this. I’ll definitely apply this to the custom image myself; or if there’s a 0.51 image, wait for that as well. It shouldn’t be too hard actually, since it’s all just within the launcher. Writing a script would be super easy. I might do it soon.
Either way, it’s happening :slight_smile:
Thanks!

Here’s a small script to do the change.

wget -O /home/cpi/twm.sh https://www.dropbox.com/s/m43wz5o5syrhkx8/twm.sh?dl=1
chmod +x /home/cpi/twm.sh
./twm.sh
Contents of the script:
#!/bin/sh
# WRITTEN BY JAVELINFACE FOR THE GAMESHELL FEB 14 2020

echo "----------DELETE LINE 10----------"
sed -i "10d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 10----------"
sed -i "9 a \	exec /usr/bin/twm -f ~/launcher/.twmrc" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 11----------"
sed -i "11d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 11----------"
sed -i "10 a \	#exec ~/launcher/dwm-mod" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 19----------"
sed -i "19d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 19----------"
sed -i "18 a \	exec awesome -c ~/launcher/awesome/rc.lua" /home/cpi/launcher/.xinitrc

echo "----------DELETE LINE 20----------"
sed -i "20d" /home/cpi/launcher/.xinitrc
echo "----------WRITE LINE 20----------"
sed -i "19 a \	#exec ~/launcher/dwm-mod -w" /home/cpi/launcher/.xinitrc

echo "----------CLEANUP----------"
rm /home/cpi/twm.sh
What I did

For those of you wanting to do what I’m about to do to their own image, I’ve modified /home/cpi/launcher/.xinitrc from"


session=${1:-gameshell}

case $session in
hdmi )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf &
	feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/desktopbg.jpg
        cd ~/launcher/sys.py/ ; python appinstaller.py > /tmp/appinstaller.log & cd ~/
	exec ~/launcher/load.sh &
	exec ~/launcher/sys.py/gsnotify/gsnotify-arm daemon &
	#exec /usr/bin/twm -f ~/launcher/.twmrc
	exec ~/launcher/dwm-mod
	;;
gameshell )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf & 
	feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/loading.png
        cd ~/launcher/sys.py/ ; python appinstaller.py > /tmp/appinstaller.log  & cd ~/
	exec ~/launcher/load.sh &
	exec ~/launcher/sys.py/gsnotify/gsnotify-arm &
	#exec awesome -c ~/launcher/awesome/rc.lua
	exec ~/launcher/dwm-mod -w
	;;
*) 
	exec $1;;
esac

to


session=${1:-gameshell}

case $session in
hdmi )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf &
	feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/desktopbg.jpg
        cd ~/launcher/sys.py/ ; python appinstaller.py > /tmp/appinstaller.log & cd ~/
	exec ~/launcher/load.sh &
	exec ~/launcher/sys.py/gsnotify/gsnotify-arm daemon &
	exec /usr/bin/twm -f ~/launcher/.twmrc
	#exec ~/launcher/dwm-mod
	;;
gameshell )
	exec ~/launcher/aria2c --conf-path=/home/cpi/launcher/aria2.conf & 
	feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/loading.png
        cd ~/launcher/sys.py/ ; python appinstaller.py > /tmp/appinstaller.log  & cd ~/
	exec ~/launcher/load.sh &
	exec ~/launcher/sys.py/gsnotify/gsnotify-arm &
	exec awesome -c ~/launcher/awesome/rc.lua
	#exec ~/launcher/dwm-mod -w
	;;
*) 
	exec $1;;
esac

Basically commenting out the DWM and enabling the TWM.

The changes are to do with how the window managers behave, in particular when plugging in via HDMI. You probably won’t notice anything if you only use your gameshell handheld.

It does however seem to make the launcher icons move a bit smoother, but also a bit slower. I’ll have to do a side by side comparison to check.

You will also need to edit the ~/.config/retroarch/retroarch.cfg file, and have fullscreen enabled. Windows mode doesn’t scale well, and will be zoomed in like crazy after enabling twm.
Look for this line, changing it to true:

video_fullscreen = "true"

I’ll add this to the script tomorrow too.

I’m torn whether to include this. It sounds like it’s going to be implemented in a future official release anyway, but I’m not sure if people are more used to the DWM menu movement now.

Try the script above out if you have some time. It works for both the DEOT version and the official 0.5 version. I’ll make a second script to revert it back if anyone wants it.

Let me know if in the next release I should:

  • Change to the TWM window manager
  • Keep the DWM window manager

0 voters

Also from the previous poll, it looks like most people don’t want any extra pre installed standalone emulators, but had some interest in the Emulationstation front end. This will most likely be mainly associated with Retroarch.

1 Like

all the 3rd party softwares could also be setup at user choice, so be external by using an apt or warehouse repository

what are the differences between the two window manager implementation ?
are they really usefull as clockwork os doesn’t allow multitask ?

3rd option is to use my customized monsterwm,
it will give you anywhere sound/backlight control, allow context switch between windows and could ask any window to close

1 Like

I have thought about having every single option buildable via the warehouse, from a stock 0.5 image.

I’ve only applied this one, since it’s going to be something according to the GitHub entry that will be implemented later on in the official image. Just so there’s less things to update later on. I honestly can’t say what’s different between them, besides how things are animated.

Re: multi tasking via monsterwm, If people are wanting to have it, I’d put it in. I’m interested in using it in my own day to day OS. For now, I’m hoping to have as close to what a spiritual DEOT OS would be, if one were made today; while keeping things that are fairly stock updates.