I still have screen tearing with gPSP on 0.4, but there’s no tearing on 0.3.
That’s weird because I’m on 0.3 and have very noticable tearing. Is there some global setting you have to enable to avoid tearing?
@podmaz OS 0.21 includes RetroArch 1.7.0, while OS 0.4 includes RetroArch 1.7.7.
I verified that both setups are using the exact same version of mame2003_plus_libretro.so.
My next step will be to upgrade RetroArch on my OS 0.21 card to see if it breaks. If I can figure out how to downgrade RetroArch (to 1.7.0) on my OS 0.4 card, that would be another useful test.
@wolo indeed! I also thought that all this connected with unstable retroarch build. But I’m not good in all this linux stuff(
As you guys pointed out all these flaws, I’m starting to take notice. The last update had way less problems
I took a stab at upgrading RetroArch using the instructions in this thread, but I ultimately gave up. My device froze during the “make” process and I wasn’t patient enough to start over.
I also tried copying the /usr/local/bin/retroarch binary from OS 0.4 to OS 0.21, but that just caused RetroArch to dump back to the menu. There must be too many unmet dependencies.
I’ll stick with OS 0.21 where I have pixel-perfect rendering for now. Thanks guys!!
I did some testing on OS 0.3 which includes RetroArch 1.7.5, but my results weren’t any better than with OS 0.4.
I updated Launcher to 1.2.5, and it appears to be properly switching between fbturbo and lima. Top shows RetroArch hogging ~70% CPU when I’m using fbturbo. It drops down to ~1% when Lima is selected.
But that damn Pac-Man screen is still squished and cropped in either case!
Then I thought I might have an easier time downgrading to an older RetroArch by using dpkg. But even after removing/purging and then installing an older deb package, it still shows version 1.7.5.
I’m not quite Linux-y enough to figure this out.
Well I guess there’s nothing we can do, until the devs decide to fix everything
Is using Lima saving a lot of energy? Also, where can I see the version number of my launcher? And do you have screen tearing on 0.3?
Settings > Update will show your current version of Launcher.
I’ve been (overly) focused on the scaling/cropping problem. When it hit a dead-end, I get frustrated and swap back to my stable OS 0.21 card – so I can’t provide much info about battery life or tearing in OS 0.3.
Hey guys, should I just go back to v0.3? Because it seems v0.4 is a hot mess
I’m starting to wonder the same thing. I noticed in another thread (ohBoy emu) @Lix went back to 0.3 to solve problems. Since I lost Lima on 0.4 due to upgrading to Buster, I’d kinda like to try the standalone MAME stuff with Lima to see how much better it runs. So I might switch back too!
I’m not sure what benefits 0.4 brings, beyond some extra pre-installed emulators that seem to be slower and/or broken in various ways and need to be replaced anyway.
Don’t get too excited for MAME SDL. Its not solved for now…
I followed your standalone MAME instructions and was happy to see that Pac-Man fit properly on the screen. The scaling is doing something weird though. Check out the side-by-side comparison:
On a brighter note, I did notice a considerable reduction in CPU usage with Lima versus BFTurbo:
Pac-Man with FBTurbo: ~181% CPU
Pac-Man with Lima: ~56% CPU
So should I go back to os 3 and wait for os 5? Where are the developers in all of this, they need to do damage control lol
Oh it is working then?
Are controls working too?
Can you try inthunt.zip?
Cool! Good to see it’s working better with Lima, and even on 0.4. Maybe I’ll just roll back to that and not do the system upgrade to Buster again.
I’m only guessing, but I think your display scaling issue might be due to filtering being turned off in the standalone version. Have a look at mame.ini and search for “filter”. Somewhere in the video options there might be a filter 0 and if so, change it to 1. I was trying to get the most speed so I turned off filtering even though it looked kinda crappy. But with Lima it might run fast enough even with filtering turned on. Pacman shouldn’t be a problem, certainly. I think each game could have its own settings, with the filtering on/off as needed for each, but I was just messing with the top level settings when trying it out.
I’m curious how some of the beefier games might run – even something like Smash TV might be a good test.
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.
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 So, one thing is cured and another is broken… Great)))
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!
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.