I have just finished picking up the pieces you mentioned and remediated my problem by them and just noticed you are more awesome than I already though and published a new release! Many thanks!
Haha aww thanks!! I thought there wasnāt much to warrant an upload, until I added them all up and realised, dang; there is actually quite a lot!
Hopefully the links allow you to cumulatively add the majority of the changes.
Did you end up getting Retroarch working better? Iām curious as to what your overlapping problem was.
Really looking forward trying this out. Thanks!
I was having the glitch in XMB when used the āCore Updaterā option, it remain stuck and got overlayed with the other options when moving in the menu. I have switched back to RGUI, as it suits me better in overall, Iām not using the device on HDMI, just for handheld. Anyway, I will still stick with RGUI as itās much easier to read on this small screen.
Today I have installed the new deot_v2+ 200224.img on another mSD, and noticed the problem on XMB with āCore Updaterā no longer appear (although pressed Core updater once all of the other items were updated).
Excellent work on this new image!
Thanks
Noticed some minor glitches, can you please include a fix for them in the next release?
When using DEOT skin it seems the font is too big at the Airplane setting.
BatMon makes RetroArch hang - not sure how to resolve this.
Thanks
I wonāt be able to fix the Batmon, but @Petrakis wrote it, so may be able to help!
As for the air plane mode, and the larger font, Iām trying to get the āproperā setting menu working. The current one is just a place holder. If youāve ever tried the stock 0.4 DEOT image, youāll know what it is supposed to be.
For now itās a small enough problem, seeing as we shouldnāt be needing to turn airplane on and off too much.
Agreed, not a big issue, just wanted to let you know.
Thanks for the contact about BatMon, wrote him a PM about this.
Cheers
With the stock 0.5 or the custom one? I donāt think iāve had this issue with the stock one, I will see if I can reproduce it.
@Petrakis
I have experienced the issue with the DEOT_v2+ 200224.img which is based on the 0.5 stock one with RetroArch 1.8.4 playing Super Mario Land Rev 1 (GB) .
So it should work properly with the stock 0.5? Iāll make further tests.
It works for me, but it might be a very specific scenario where it happens. But I have my theory, its not that it freezes (You should be able to still do ssh), what I think it could be happening is that when BatMon is raised on the screen it steals focus from retroarch, so keypresses are directed to BatMon instead of RetroArch.
It could be, thanks.
Regardless of all the efforts the community puts into the various side of deployments, and thanks BTW for all of you guys, we are still a long way from being ClockworkOS stable. I had tons of freezes like when exiting any game from RetroArch, or when loading games which worked before (with every official release) - Mostly using the RetroArch side. I guess itās not a coincidence we still have version starting with zero dot x. I donāt want to demotivate anyone, but I think itās a shame that during these years official gamesh development is still going so slow providing such a rocky experience on the user side.
Try using the older FBTurbo graphics driver. That should solve your stability problems. Of course that comes at the hit of less performance, but honestly if youāre using retroarch, besides the XMB interface, youāre not missing out on that much using the older graphics drivers.
The Lima drivers are still labelled as experimental. Itās there so you can test it out.
If you can provide examples of games that worked before that no longer did, that would be great so we can test it out and replicate the problems to find solutions. Include which drivers you were using etc.
The whole point of me making this image was to help solve problems for people with an environment I know is configured a certain way, and to apply universal fixes to help people have an image that does what you want it to. Iām desperately trying to advance us towards something that can be considered a stable OS.
Possibly consider trying this.
I never considered it before, but the window manager could be the problem regarding the reported crashes. I have personally changed to the twm manager, ie performing the above change, and havenāt had any crashes. The image I just released has a slightly modified hybrid that uses the dwm manager in handheld and twm in hdmi, simply because I assumed people would complain about menu speed problems. The vote I ran earlier had a 75:25 split, hence why I made a compromise.
I guess itās a matter of the chicken and the egg. Things will go faster if communication gets better. Most people doing things are doing it in their own free time, out of the love for the console. As soon as it feels like a thankless job, with people cracking the whip at your heels, of course people are going to drop off.
On a lighter note:
AH! I just re-read this and realised what the problem you were facing was!
I made a typo in the buildbot URL, having https://buildbot.libretro.com/nightly/linux/arm7-neon-hf/latest/ instead of https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/
One letter v. I made a typo!
So Iāve just pulled in this. Works AMAZING! All emuās just works out of the box, different regions on PSX games doensāt matter, N64 runs smoooothly. I cant beleive this isnāt the official image.
Iām a developer (frontend guy) that has used Linux for the last 15 years. Please tell me if I can help out in any way.
Once again, thanks for your amazing work.
Edit: And the global volume controls!! Canāt believe that isnāt in official image.
Thank you so much @peturh ! You have no idea how happy this makes me feel! I will constantly be trying to find as many way to make the image as fast, useful and graphically appealing as possible, without introducing too much to bloat the image.
Itās all a culmination of the work of the community that Iāve tried to streamline into one image, and provide instructions on how to do so. I canāt take all the credit! Most of the credit is attributed and credited in the first image, ie the DEOT v1+ image.
Hopefully the reason the volume controls wasnāt included wasnāt some kind of compatibility, or performance hit issue. Perhaps itās the fact that it is limiting the shift + start/select to a single function, and is seen as counter productive. Ooh that gives me an idea, re: having a separate hook to enable/disable the volume control hook on a per app basis, say if youāre doing something that doesnāt have sound per se! I canāt think of anything yet, but if I do Iāll be sure to include it!
One thing that I am having trouble with is reverse engineering the DEOT stock kernel to extract the first and second boot screens, and then recompiling the kernel to incorporate the images. Iāve got the contents of the 0.4 DEOT Kernel and the current stock 0.5 kernel, ie the one this custom image uses.
So far Iāve managed to get the first boot screen:
Hereās what the rest of the screens are supposed to look like:
Actually, in retrospect now that iām looking at it, itās only the GCORES INDUSTRIES image that I need. I can just modify the BIRDSONG END image just erasing the text, and using the supplied eurostile font to just rewrite the second splash screen! How could I have been such a fool?? Ahhhh!
I donāt know if the LOADING screen in the above image was every actually used in the end image. The one we have is much more minimalistic.
The final thing that Iāve been really wanting to get working properly is the settings items, specifically for sound, brightness, airplane and storage. Like the image above, they should have a more customised gauge like interface, as opposed to the dial like interface from the stock OS. Itās not that big an issue, but part of what makes the DEOT image unique.
I have extracted the contents of the settings menus here, along with the contents of the /home/cpi/launcher/sys.py/UI
It currently freezes at load. I believe itās something to do with things that are referenced in the xxx_page.py file, that arenāt correctly linked in the skin_manager.py file; namely font references/sizes etc. It could be something else. Itās just going to be a slow matter of checking every possible referenced thing, and cross referencing it against the altered and original file.
If you can get any of the above working, that would be fantastic! Otherwise, Iāll keep chipping away at it in my spare time. Also, if thereās anything else that you think would be a great addition, or optimisation to the custom image, let me know!
Iāll have a look at the menu stuff! Even though I must admit Iām not a python developer. But maybe I can sort something out.
Iāve been trying this updated 5.4.20 kernel out, and for mupen at least, Iām seeing slightly better performance. In particular, trying out banjo Kazooie, Mariokart 64, Mario 64 and Zelda OOT. Less micro stutters and graphical artefacts mainly. Slightly smoother.
Retroarch seems less prone to randomly quitting on load, but that could just be luck.
I havenāt read all of the commits in github, and perhaps things werenāt changed that much. It could be a placebo effect. But either way, itās seemingly improving performance. Looks like a lot of GPIO changes, and port activation. And of course general updating of the kernel files. I may need to update to buster properly to make use of all of the optimisations. Iāll look into that, and find a way to not have everything break as it usually does. I think there was talk of doing this in another thread.
Iām not sure who asypost is in the forums, but I did notice that @shell has made commits to it, and @guu is following. If either of you know who they are, let me know! Iām thinking about including it with the next release. This one seems like a keeper!
If youāre out there asypost, Iām loving your work!
In other news, looking into other threads, Iām considering including the DS emulator mentioned earlier in the week. Would that be something people would like to see?
Adding a streamlined way to include the Godot assets and marketplace would be an interesting direction for the gameshell. Iām looking into it with a keen eye.
Itās been fairly quiet lately, gameshell progress wise, so nothing much else to add or report on. Work has also picked up again, so that works out well.
Here we go! Another update, but one to test out before making it prime time. Please let me know how you go with it!
DEOT v2+ Build 200307
7th of March 2020
Current changes:
- Updated Kernel to 5.4.20
- Updated to Debian 10, Buster, maintaining Lima drivers functionality. Ie, Buster hasnāt broken everything like it normally does.
- Installed and configured ScummVM
Future Changes:
- Incorporate the DEOT boot splash screens
- Include Drastic emulator, action.config files, and icon
- Godot
Itās currently uploading to the Google drive from the first post.
Iāll provide a mega link once itās uploaded.
In my rush to upload and compress the image, I forgot to a) empty the mail and b) delete clockwork-pi3-kernel-5.4.20 directory I copied over to muck around with incorporating the custom boot splash screen.
Use the empty mail script in utils to remove the mail dialogue, and just delete the clockwork-pi3-kernel-5.4.20 directory to save about 800MB or so.
As a side, Iām also experimenting with this overclocked 5.5 kernel:
I only havenāt provided it, since the overclock may give a beginner user an inaccurate perception of the Gameshellās battery life due to the overclock, and thus attribute this image with a lower battery life.
Spent the evening trying to get Drastic to work. Boy is it fast! Hereās a custom icon Iāll be using once itās working.
Just so I donāt cross post, hereās where weāre at re: playing DS on the gameshell.
On another note, I canāt remember if I installed an action.config file for the Wonderswan, including an app icon etc. Nothing too fancy. Just a link to the Retroarch core anyone can easily download. Itās not necessarily everyoneās cup of tea I guess, which is why I canāt remember if I installed it or not. Iāve just been toying with the idea of an alternative chassis that supports a 3:4 screen orientation (as opposed to 4:3), for SHMUPS and arcade style games - Kinda like what the Wonderswan did.
Another thing Iāve been wanting to toy with is installing extra plugins for the PCSX emulator. Iāveā¦ kinda got the Castlevania bug. Curse you Netflix. And with that comes Symphony of the Night, for some Alucard action. (no students allowed Since there arenāt really any graphical options to enable a bilinear filter, or any other means to make the text less compressed, itās something Iād like to look into. Itās still playable of course. Just, it could be even better.
If anyone else has made any progress on the above already, it will save me having to tinker. That said, itās always fun to do so anyway. Let me know! And as usual, let me know how the community image is running, and any requests etc.
In other news, I couldnāt reverse engineer the stock DEOT kernel to extract the two boot splash images, and I never got a response from the devs re: my request to have access to the files. So I made them myself
These are the things that are missing from the kernel to give the final touches on the DEOT experience.
Hereās a preview.
(Donāt worry; the actual files are 8 bit BMP files - the forum wonāt let me upload that format)
Iām definitely going to include Drastic. Itās running ever so perfectly. Hereās a link to the thread where I posted a config file that works brilliantly.
As for the boot splash screens and editing the kernels, Iāve managed to get the second one in. Itās just the first one before the frame buffer Iām still having difficulty with. Iāve got it based on the 5.4.20 kernel I used in the most recent build.
Iāll post what Iāve got so far, in case anyone wants to tweak it any more. Or if anyone knows how, please let me know!
The uImage is the same one made by asypost (Who I think is actually @shell!) above, just with the /drivers/video/logo/logo_linux_clut224.ppm file substituted and then compiled. Copy it to your /boot partition as per normal.
The logo_linux_clut224.ppm is the second boot logo splash. Itās converted to the correct raw format, and already in the uImage, but is here in case you can help at all with making the first boot image work. @peturh - If you offer any help that would be great!
The psplash was my attempt at using a third party frame buffer splash screen substitute. Probably only useful if youāre using psplash, but who knows. It could be useful for someone.
Otherwise, here is the file by itself, if you want to try your hand at doing it from scratch.
I never got around to really spending time customizing your previous DEOT release to get everything (especially build environments, like for box86 and the other things like mono I was tinkering with)
working again from my old environment. Iām thinking your new image based on buster is worth waiting for and using as a relatively stable start again. Sorry to say, but Iāve been dragging my feet a bit since I didnāt want to invest a bunch of time only to have to do so again relatively soon. Mostly starting from scratch each update is time consuming and Iād rather spend my time tinkering and trying to build new things than just setting up the environment to do so!
But Iād also really like to have the new kernel available. I was under the impression that while overclocking was supported with it, it depending on the settings used. Is it worth considering using the new kernel, but having the default settings use the regular Gameshell performance settings. Essentially have it NOT overclocked by default, but use the new kernel. Then someone who really wanted to could tweak settings to get even more performance, at the loss of battery life. I have a larger battery installed and I know others on the forum do too, so Iām just wondering if there might be a compromise that allows for a āsafeā install for new users, but also a tweakable install for tinkerers. Just a thought. I should probably just roll my own kernel by following along with the posts here, but if youāre already there and could include it as an option, I think it might be useful.
Thanks for maintaining and enhancing this OS option! While the interface design is cool, I think the main benefit is that you actually improve it as well as ensure most everything is working. That includes emulators and drivers that arenāt broken or set up incorrectly. The official OS has sadly lagged far behind and if there werenāt other options like yours, I fear interest in the platform as a whole might have fallen off.