lr-scummvm: request for comments and testing

Lolonois

@roslof I could reproduce the isssue (g_TRECISION...) but here's what worked for me. I tested it with the lr-scummvm current master (commit: 6df2bdf - https://github.com/libretro/scummvm), not with the diablodiab changes.

Either way worked.

With Kernel 5.10.43:

Change in /boot/config.txt: Disable dtoverlay=vc4-fkms-v3d (fake KMS) and enable dtoverlay=vc4-kms-v3d (KMS).
Reboot.
Recompile scriptmodule as usual: sudo ./retropie_packages.sh lr-scummvm.

With Kernel 4.19.97:

If you want to revert from kernel 5.10 do this before:
(a): have/make a recent full backup and
(b):
```
sudo rpi-update  993f47507f287f5da56495f718c2d0cd05ccbc19
```
The commit string relates to this message in this repo. NB: You can also jump to 5.10 again with commit 85bda3d8fd6a8b70d189aefd9234440ca99cb81c.

Follow the on screen instructions.
Change in /boot/config.txt: Disable dtoverlay=vc4-kms-v3d (KMS) and enable dtoverlay=vc4-fkms-v3d (fake KMS).
Reboot.
Recompile scriptmodule as usual: sudo ./retropie_packages.sh lr-scummvm.

From my experience one needs only the "cutting edge" ScummVM for the recently added ResidualVM engines, but then this is also currently a moving target on the standalone ScummVM.

roslof

@lolonois great information. Clarifying question (with kernel 5.10.43): Actually running kms vs. fkms will yield different results when compiling? I didn't realize this.

Lolonois

I did not dig into all details but the g_... error gave me a hint that the GPU driver may be causing the error. With NOT recompiling and changing from fkms to kms I got random freezes with retroarch scummvm with "Day of the Tentacle".

One thing I forgot to mention: I also installed the package libglew-dev before recompiling.

BadFurDay

With the release of 2.5.0, when might we see an update to lr-scummvm?

Lolonois

@badfurday I assume it will take some time. The recent comments on this issue [1] give some insights.

However, you are free to speed things up by contributing or dontating to those guys running the show.

In the meantime I was able to deploy ScummVM core 2.5.0 in retroarch 1.9.7 without worries. User diablodiab had updated the branch after the release of ScummVM 2.5.0.

I used the 9703372cc8 commit from [2]. Just make sure to issue a make clean before each actual make to remove any leftovers from previous builds. FWIW Instructions here, a few posts above [3].

If games have high graphic demands you might be better off with the native ScummVM.

[1] https://github.com/libretro/scummvm/issues/179
[2] https://github.com/diablodiab/scummvm
[3] https://retropie.org.uk/forum/post/260716

ParadoxGBB

@lolonois, I'm really curious how you got lr-scummvm working at all, because I seem to have hit the following issue on my Pi4 (all titles graphically freezing either during or right after the retroarch "configuration loaded" notifications, as the screen is refreshing and pointer is rendered:

https://retropie.org.uk/forum/topic/30769/lr-scummvm-freezes-shortly-after-launching-any-game/2?_=1636065648381

On my older Pi3B everything is fine on RetroArch 1.8.8, and works fine still when compiling from latest lr-scummvm binary or sources, but breaks when doing a full update that upgrades to RetroArch 1.9.x.

This indicates to me that it's likely not directly tied to RPi4's graphic settings but some sort of interaction with RetroArch. I did a diff between the two machine .cfg files and so far not seeing anything obvious, but might muck around with that later.

I also tried custom building from https://github.com/diablodiab/scummvm with your steps and swapping out the core, but that doesn't load at all and just boots me back to ES.

So the only solutions I see right now is to somehow downgrade Retroarch on my Pi4 or change my configuration to use Scummvm, not lr-Scummvm. I'd really not have to do either.

I'm really scratching my head, because even if I'm wrong, I verified that FKMS is enabled in /boot/config.txt and libglew-dev package is installed. Kernal 5.10 installed too.

I really must be missing something because this is so broken that if everyone else is hitting this for this long (~5 months?) there's not a lot information out there. Then again, maybe folks running the core is a niche thing and more folks are just running ScummVM natively.

Lolonois

@paradoxgbb positively, as I wrote before, when you deploy an inofficial branch in an experimental marked emulator expect the unexpected. It is terra incognita.

However, after compiling the latest commit (da02041) from [1] and deploying it, lr-scummvm does not work (thats what you noticed, too). So there is some issue introduced since my post [2].

For the record (summary of my last posts):
I am on kernel 4.19.97 and fake KMS, retroarch 1.9.7 (binary, from Sept 8, 2021)
Important: Make sure to pick commit 9703372cc8 (from Sun Oct 10 17:43:37 2021 +0200) of repo [1]. This worked on my setup. There may be later versions (of future commits after writing this) that work, but this hit and miss approach is left as a exercise to the reader.

In a nutshell:

git clone https://github.com/diablodiab/scummvm scummvm_ddiab
cd scummvm_ddiab
git checkout 9703372cc8
./configure && make clean && make -j$(nproc)
cd backends/platform/libretro/build
make -j$(nproc)
strip scummvm_libretro.so
sudo cp scummvm_libretro.so /opt/retropie/libretrocores/lr-scummvm/

[1] https://github.com/diablodiab/scummvm
[2] https://retropie.org.uk/forum/post/267782

ParadoxGBB

@lolonois Thanks again for the help, but no go. I dug in a bit yesterday and oddly parsing the specific command from runncommand.log and then subsequently lr-scummvm's rom loader / directory translator, I get no output when running in the terminal at all. No errors, no hangs, no crashes, nothing. To clarify, that's now with your suggested commit head.

The best guess I have right now is that I'm missing some sort of dependency package. As folks noted before and it also surprised me, depending on what packages you have installed impacts compilation. It still seems like retroarch integration itself with recent versions is getting in the way of the cores either grabbed or compiled in the official repository, maybe around kms/fkms stuff given the nature of the freeze, seems graphical to me.

Also no, I'm not surprised that compiling from source for an experimental repository causes complications and requires work to get running. I am, however, surprised that the precompiled binary published at https://files.retropie.org.uk/binaries/buster/rpi4/kms/libretrocores/lr-scummvm.tar.gz.asc, with build timestamp 10/15/2021, is this broken with the defaults on my pi4, especially since none of the other cores I use has any problems with the latest retroarch bits. Does the precompiled binary work for anyone else or are folks getting freezes like me and the guy whose thread I referenced before?

If anyone would be so kind I'd love to windiff my output of ./configure with someone else who got the core to compile and work on a pi4 (EDIT: mine is https://pastebin.com/gNX24Urq).

Lolonois

@paradoxgbb thanks for providing the configure output and an elaborated answer: Your assumption was right.

After comparing with my configure output (http://ix.io/3ELs) which results in a usable build on my Rpi4, I assume the missing libglew-dev is the cause of the instant scummvm termination. Furthermore I have liba52-dev installed, but I assume this is less important. In contrast I don't have the GIF lib installed, so this difference is irrelevant.

Would you mind testing the binary build your were mentioning [1] after installing libglew (not the -dev package) first and report back if the pre-build binary then runs successfully? (If yes, this dependency should be noted to the maintainers of the lr-scummvm.sh scriptmodule of RetroPie-Setup).

And of course let us know if the source build works well with libglew-dev (and liba52-dev) installed.

HTH

[1] https://files.retropie.org.uk/binaries/buster/rpi4/kms/libretrocores/lr-scummvm.tar.gz.asc

ParadoxGBB

@lolonois Thanks again for your time on this.

So according to as much as I can tell, I do have both libglew and libglew-dev installed. I uninstalled the -dev package and made sure things were clean on the binary side but I still see the initial problem, which is an instant freeze. On the off chance I was wrong I attempted to install liba52-dev (and confirmed attempting to re-install libglew) as well but same result.

pi@retropie4:~ $ apt-cache policy libglew*
libglewmx-dev:
  Installed: (none)
  Candidate: 1.13.0-4
  Version table:
     1.13.0-4 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
libglew-dev:
  Installed: (none)
  Candidate: 2.1.0-4
  Version table:
     2.1.0-4 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
libglew1.5-dev:
  Installed: (none)
  Candidate: (none)
  Version table:
libglewmx1.5-dev:
  Installed: (none)
  Candidate: (none)
  Version table:
libglew1.6:
  Installed: (none)
  Candidate: (none)
  Version table:
libglew2.1:
  Installed: 2.1.0-4
  Candidate: 2.1.0-4
  Version table:
 *** 2.1.0-4 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
        100 /var/lib/dpkg/status
libglewmx1.13:
  Installed: (none)
  Candidate: 1.13.0-4
  Version table:
     1.13.0-4 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
libglew1.6-dev:
  Installed: (none)
  Candidate: (none)
  Version table:
libglewmx1.6-dev:
  Installed: (none)
  Candidate: (none)
  Version table:

At the moment I'm not convinced this is one problem. There's the graphical freeze problem when using the binary, and there's the booting out / no output problem when attempting to build my own. The latter's ./configure output does seem to indicate that my machine does have a problem detecting libglew for some reason. Right now I'm focusing on the former binary problem because that seems the most egregious to me (and it's faster to iterate on).

I did some initial pre-publishing testing for this core at the start of this thread, so it's possible I have something lingering or causing problems with that, but not sure why that would now be triggered with a RetroArch update --- that was about 3 years ago so I'm light on what specific steps I might have taken that would have caused a problem. There being a config.txt problem seems a stretch too since I'm hitting this on both of my Pi3 and Pi4 on retroarch upgrade.

Both of these Pis have forked configuration copied and tweaked, so prehaps that has something to do with it. I'm about to get a new pi zero 2 w online, so I'm thinking about first trying to get this core working from scratch to see what datapoint that creates. After that, I'm a bit at a loss on how to proceed.

EDIT: My /boot/config.txt: https://pastebin.com/XCgGUERC

Stuffu

I'm have been using standard scummvm and have zero issues and the controllers work just fine, both gamepad and mouse/keyboard.

I'm curious what benefits there are with lr-scummvm over scummvm?

Thanks in advance

retropieuser555

@stuffu you get the little extras RetroArch offers, like the overlays (borders) and shaders

Stuffu

@retropieuser555 ok, never bothered much about those parts but maybe will look into it some day :) Thanks for clarifying!

ParadoxGBB

@stuffu My biggest preference is having global retroarch controller settings with hotkeys in ScummVM.

Lolonois

@paradoxgbb some differences/similarities I spotted in my setup Rpi4/4GB:

/boot/config.txt: I have disable_overscan=0 and max_framebuffers=1, gpu_mem=256 (the latter for completness sake, irrelevant on a Rpi4)
No differences in the libglew* packages

I am running kernel and corresponding firmware of Linux rpi4 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Q: Do you drive a monitor beyond full HD in you setup?

What I can confirm that the binary build from [1] with these parameters in the retropie.pkg:

pkg_repo_commit="c63de10ee05bc1b6c33cc2cc32ba7b8ac48f842c"
pkg_repo_date="2021-10-13T18:21:29+02:00"

freezes (for example in the initial cut-scene of "Day of the Tentacle"). I am not going to investigate in that.

However, I can try to assist you with the source build on a Rpi4 only, although the turnaround-time is somewhat longer for a source build. You may consider disabling some engines which speeds up the turnaround cycle. Like this:

From my previous post, replace

git checkout 9703372cc8
./configure && make clean && make -j$(nproc)

with

git checkout 9703372cc8
./configure --disable-all-engines --enable-engine=scumm && make clean && make -j$(nproc)

[1] https://files.retropie.org.uk/binaries/buster/rpi4/kms/libretrocores/lr-scummvm.tar.gz

HTH

ParadoxGBB

Me again. ;-)

Here to report that things are now up and running. I had really dropped down the rabbit hole with this last month but finally, it sorted itself. More on that in a sec. I'll spare you all of the many tests and experiments and things I tried here as that's not really relevant.

First, I'd caution anyone here building lr-scummvm from diablodiab's repository from scratch, at least right now. Even if you get the target binary at the end, it might not work, and as you can tell from previous posts here it's a real bugger to debug and a lot of my initial time and effort focused on that. If you are messing around with this and get instantly booted out rather than seeing any kind of informative output, I would just stop and try something else rather than try to walk what dependencies are detected and how and everything else that the config script does.

Instead, you can just edit ~/RetroPie-Setup/scriptmodules/libretrocores/lr-scummvm.sh directly to leverage RetroPie's existing infra to build and configure, but point it to a different repository. Line 16 is the source repository:

(e.g. rp_module_repo="git https://github.com/libretro/scummvm.git master")

You can edit it to diablodiab's repository, and the scripts even support specific head hashes so you can edit it to something like:

rp_module_repo="git https://github.com/diablodiab/scummvm.git master 9703372cc8".

When doing so I was at least able to confirm the graphical hang I see also with the current published binary and source of the official lr-scummvm repository, so much better --- and it suggested that there was something specifically conflicting with the source (in both repositories) and my setup.

I then saw the following bug / issue last month when I was messing with this last, in the beginning of December:

https://github.com/libretro/scummvm/issues/183

I was convinced that there was a strong possibility that this was the issue I was hitting... both the timing where it originally surfaced and the symptoms strongly correlated to what I was seeing and since the workaround fix was only two lines I attempted to patch but I could not get that working and I ended up walking away frustrated and enjoyed the holidays instead.

Well, 22 days ago that unofficial fix made it not only to the official repository but also in the published binary, and now all is well as far as I can tell.

So, if you're having trouble with lr-scummvm, give it another go.

Based on the nature of this bug though, I'm surprised anyone could get lr-scummvm working without this fix on any ARM platform, unless the underlying issue here was circumvented by doing a customized build.

https://github.com/libretro/scummvm/pull/190

Hope this helps someone!

Lolonois

@paradoxgbb thanks for reporting back verbatim. Did I get it right that the retropie provided binary does work well? (I assume yes, as the binary [1] relates to the lr-scummvm git from 2021-12-27, it runs ScummVM 2.1.1 IIRC)

[1] https://files.retropie.org.uk/binaries/buster/rpi4/kms/libretrocores/lr-scummvm.tar.gz

The diablodiab hit-and-miss results leave me somewhat unsatisfied, but I can not put research at this atm. FTR: I am on RA 1.9.7, GCC 8.3 and for me (as stated earlier) the build of 9703372cc8 runs fine on a RetroPie 4.7.19/Rpi4.