GameShell OS image files (v0.3-0.4)

GameShell Firmware and Apps
186

I fiddled with the filter and prescale settings, but I can’t see any difference. Aside from the minor scaling issue, Pac-Man is definitely playable and the sound is perfect. And it benefits from a huge reduction in CPU usage with the Lima driver over FBTurbo.

Oddly though, SmashTV is super stuttery and unplayable with either driver. With FBTurbo it eats 110% of my CPU (out of 400%). With Lima it’s closer to 100%. Pretty minor difference.

Donkey Kong, Robotron, and Ghosts’n Goblins play fine. 1942, Zoo Keeper, and Robocop all stutter like crazy.

I really wish the dev team would step up here.

1 Like
187

I made something different and I have interesting results. Not quite understand but still. I flashed fresh OS 0.21 and copied every rereoarch related file. And after that I reflashed OS 0.4 and replaced all retroarch files with files from 0.21. At the end, I got retroarch 1.7.0 on OS 0.4
I’m getting correct aspect ratio on MAME PACMAN with core provided option with FBturbo and video_driver = “sdl”. With sdl2 retroarch stops working on both Lima and FBturbo.
Later versions of retroarch not working with sdl, so I’m guessing all these problems connected with video driver settings and with retroarch version itself and not with OS version.

PS: Key binding is also working, I mean through retroarch menu.
PPS: Scummvm core stoped working in retroarch :joy: So, one thing is cured and another is broken… Great)))

188

When I get a chance (maybe this weekend?) I’ll see if I can make any more progress with building MAME again. While making the entire thing takes a ridiculously long time, I’m wondering if it might be worth building a specific device/game for testing purposes. When MAME was being ported to handheld devices years ago, like the Tapwave Zodiac and eventually Android, and so on, there were builds for different families of games. In some cases performance was better because all the extra support in MAME for other games wasn’t included. I’m thinking that probably only affects the executable size and startup time, but it might also affect memory usage and maybe even performance when the emulation is running. Seems like it’s worth trying, although I don’t have the desire and patience to try to build the full MAME binary again. I’m glad @guu did that for us! :slight_smile:

https://docs.mamedev.org/initialsetup/compilingmame.html

There are lots of compiler options and things to fiddle with too. So perhaps if I can get a single device/game version building rather quickly then I can try various options and optimizations and find something that helps.

I wonder though, if the slowdowns in Smash TV, In the Hunt, and others are just because the hardware they used is too advanced for the GameShell to fully emulate in real time? The performance improvements you’re seeing with Lima, @wolo, imply that the video side of things is seeing an improvement. But if the slowdown is due to emulating whatever main processors those games used, then there’s not much more than can easily be done to speed things up since we’re limited by the GameShell hardware itself. Since this is the main/official version of MAME, it’s also not very optimized, although it can run the most recent stuff.

t might be worth looking into other versions of MAME that have been optimized for the Pi. I poked around and it seems like this one might be good to try:

It uses a much older version of MAME, so it may not support all the games we’d expect, or even emulate them perfectly, but it should run faster than the current modern version of MAME.

189

Before you spend a bunch of time compiling, I would recommend seeing the problem first-hand on a fresh OS 0.4 installation. Maybe “stuttery” wasn’t the best description. It’s way different than “laggy”.

Using the default RetroArch on OS 0.4 (making sure that Bi-linear Filtering is disabled), Zoo Keeper is smooth as silk. With Lima it uses 55% of my CPU. With FBTurbo, it jumps up to 180%. But it’s completely playable in both cases.

Enabling Bi-linear Filtering in RetroArch causes stuttering, but not on the same level as the stuttering in the standalone MAME.

5 Likes
190

Has there been an update to the v0.4 image file since its first release?
I want to make a custom version with the standalone emulators soon, but I downloaded the image right on the day of its release and maybe it’s outdated?

191

AFAIK no updates, but you can see that there are 4 .git in the file system (launcher, launchergo, menu and another one). You can update them with ‘git pull’

1 Like
192

0 updates, 0 fixes. sadly at this point i’m thinking with the state it was released in the devs dont really care about the community. they were “pressured” into a 0.4 and didnt even test it. it barely works out of the box and requires several “adjustments” to be actually usable.

I personally reverted to 0.3 and manually updated things. I am now looking into the method i’ve brought up before with will be a stock system with a custom repo for apt and building/migrating packages to use it instead. this will require some large changes to things like the launcher as using GIT wont work as well (and you lose your custom settings everytime you do update it) but it will make for a smoother experience (IMO).

give me a month or 3 to develop and i’ll be making a new thread on it.

2 Likes
193

Actually there were serval updates always

like @aplanas said,
if anyone try to make a custom os image, manually git pull in (launcher,launchergo,~/apps/Menu) is good to keep system up-to-date

and since v0.4 , I moved all user-data into ~/apps/Menu ,so that during the updating, custom settings will not lose

And thanks for all the supportings, any help will be great , this is an open source project after all

2 Likes
194

Digging up a thread from the past, anecdotally I can say that I have found greater stability from 0.4. I couldn’t say the same about 0.3 vs 0.21, and stuck with 0.21 for as long as I could.
0.4 has less crashing of emulators; loading, running and terminating, and overall UI Stability, in particular with wifi.

Directory structure consistency has also been tidied up, Eg the snes emulator isn’t in its own separate legacy folder location.
On folder manipulation, the recently added core management tool could prove to be very useful, in particular if the maintainer of a specific core decides to update their code. You can simply use the core manager to delete your existing core and then run the emulator to download an updated one.

In addition, proper skin integration, as opposed to having to edit the launcher skin parameters mean that doing a launcher update doesn’t wipe your skin settings. Further more, it gives more sand boxing tweaking space for testing skins, not needing to worry as much about system hangs when it doesn’t like your input.

Sure the two above points can be done via SSH easily, but it’s getting closer to a state where you can use the Gameshell independent of an external SSH session.

Power management also seems to be better, re battery life improvement, possibly due to switching to Lima, which seems more stable.
NWJS + phaser.io now seems to work with Lima drivers. Probably good news if you’re a developer.
Heat generated is a lot less, in particular while idling.

Overall emulation is a lot less hit and miss regarding tweaking settings for smooth audio/video.
This can be possibly attributed to retroarch 1.7.7 being updated to the current version.
The problems people seem to be encountering are mainly to do with teething problems people are having with configuring the new retroarch. Ie mame input problems, general key bindings, and updated cores. This and people possibly using older scripts to configure a newer config file incorrectly.

Standalone emulators have no benefits I can see.

This is purely anecdotal. There is also a chance that these improvements can be due to my own optimisations of the system as I became more and more familiar with things. Your mileage may vary. I would like to hear from the developers what they have actually done.

Then again, if when using an OS release you can’t notice a difference, then probably best to just go with what the majority of people are using, just so you can keep up to date.

2 Likes
195

that you for the update @guu i my message you if i encounter any real issues moving things to an apt source. i did notice the change with the git launcher and many thanks for that but there’s still a lot on 0.4 that was/is broken and requires intervention. I hope this isnt because development has shifted to the DEOT (same hardware)

196

DEOT is behind the main

197

Linux Kernel 5.3 is released. It’s time to update GameShell OS.

198

Agreed,@guu current v0.4 uses an unstable kernel(Linux 5.2 rc4) and the lima driver is not stable enough,It will be nice to do an update to improve the stablity and performance.

199

@guu I also think lima drivers and Mesa are outdated in v0.4.
Lima is causing me many issues, please update the OS with the new versions. (Mesa 19.1.x and 19.2.x are available, vs. 18.3 currently installed in the GameShell)

200

ok . will do …
I noticed that lima has been into the mainline kernel now , and it seems that no need to use seperate mesa anymore … what a good news…

2 Likes
201

could this mean a new update is coming? :>

1 Like
202

Yeah that’s great, no need to mantain a separate version anymore.
Now I understand why lima gives so many troubles, it’s an outdated version.

Hope I’ll be able to develop games that run on the GameShell too with the new updated drivers soon.

Please keep us updated on the progress with the new GameShell OS version.

203

I tested the latest kernel 5.3.8 with lima enabled by edit .xorg_lima.conf and disabled /usr/lib/lima with lddconfig.It seems that lima is still unstable.

2 Likes
204

Did you also try to use the updated Mesa?
Anyway, the new lima drivers + Mesa should improve many things.
A new update that removes the manually added implemention in favor of the kernel one is required for the GameShell to be future-proof.

205

How can you tell lima is not stable yet?