Working Dreamcast games

mitu

Forgot to mention I'm using a 3B model (non B+). To complete what @barbudreadmon suggested, I've modified the entry for lr-reicast in /opt/retropie/configs/dreamcast/emulators.cfg to get lr-reicast starting.

lr-reicast = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-reicast/reicast_libretro.so --config /opt/retropie/configs/dreamcast/retroarch.cfg %ROM% </dev/null"

WarC0zes

@mitu Thanks, the games are launching now :)

after test, works better reicast than lr-reicast for rpi 3B.

barbudreadmon

@WarC0zes said in Working Dreamcast games:

after test, works better reicast than lr-reicast for rpi 3B.

You probably mean faster (it is, slightly), because lr-reicast is better in terms of compatibility and features, one example is that the dead zone thing mentioned by @backstander is in core options.

WarC0zes

@barbudreadmon Yes, mean faster. After cool for naomi games, but rpi 3b lack of power.

quicksilver

@mitu @barbudreadmon Thank you for your help on this! I now have lr-reicast working on my pi3b+ (overclocked). Testing crazy taxi, performance is at least on par with the standalone reicast and may actually be better. I think Lr-reicast must use something different for audio because the standalone reicast using omx will drop the sound any time the fps takes a dip. Lr-reicast audio however only stutters a little bit when fps dips. Ive noticed this behavior with OMX while using mupen64plus and thats why I switched to SDL for audio when using that emulator.

I cant wait to test more games with this! Hopefully this can be added directly to the experimental emulators at some point in the future.

mitu

@quicksilver lr-reicast will use ALSA, and I think the standalone Reicast also got ALSA sound support, but the launching script might not be updated for it (on the Pi) - from what I noticed looking at the emulators.cfg, it uses either omx or oss.

EDIT: actually, ALSA support was available in standalone Reicast also, it's not a recent addition as I thought.

barbudreadmon

@quicksilver iirc, the main developper of lr-reicast reimplemented the spu emulation (sound processing unit) last year, i'm not sure those changes were backported to standalone. As to why, the main reason might be that it's not easy to commit something to standalone reicast, even when it is confirmed to fix issues.

quicksilver

Tested a few more games with lr-recaist. Army men Sarge's heroes is significantly slower even with the recommended tweaks @barbudreadmon suggested. Daytona USA is also slower and has some missing textures on the cars (might be caused by one of the tweaks?). But having analog deadzone is great!

I've noticed that quite a few games have textures that flicker (army men, dynamite cop to name a few). This is present in the standalone core as well as lr-recaist. Is this because we are using a gles 2 device? Is this worth reporting on the GitHub issue tracker or is it something we pi users are stuck with?

barbudreadmon

@quicksilver There might be some improvements with textures if you change settings for "Alpha sorting", "Modifier Volumes", and "Div Matching", that will most likely slow down the emulation but feel free to experiment.

Most of the rendering improvements were done on the OIT renderer, which required an OpenGL 4.3 compatible gpu, and preferably a good one (some games are struggling on my gtx960 with the oit renderer, while i'm not even using enhanced resolution or upscaling). For the most part i think the non-OIT renderer is the same as standalone reicast, so turning on/off one option or the other should give the same result.

pjft

Just to say that after adding the < dev/null to the line lr-reicast actually worked surprisingly well - well done @barbudreadmon on the developments and @mitu for getting it working.

I find that my lr-reicast does not have sound, which is unexpected but certainly tolerable as I am not running the latest RetroArch (I'm still on 1.7.1 it seems). The driver is alsathread, all works well on other emulators.

Just checking whether there's anything I might try that might change things, from your perspective?

On load, from the pastebin logs from yesterday the following messages come up:

[INFO] ALSA: Using signed 16-bit format.
[INFO] ALSA: Period size: 284 frames
[INFO] ALSA: Buffer size: 1411 frames
[INFO] [LED]: LED driver = 'null' 0x1e419c

I see in @WarC0zes 's log it has a few more lines:

[INFO] ALSA: Using signed 16-bit format.
[INFO] ALSA: Period size: 384 frames
[INFO] ALSA: Buffer size: 1536 frames
[INFO] [LED]: LED driver = 'null' 0x2333a4
[INFO] [MIDI]: Initializing ...
[INFO] [MIDI]: Input disabled.
[INFO] [MIDI]: Output disabled.
[INFO] [MIDI]: Initialized "alsa" driver.

I will try alsa instead of alsathread later and see if it changes anything, but if anyone has any other ideas do send them over. If not, it's also fine, really - I'm mostly looking into this out of curiosity as the only game I really play is Ikaruga, though it does look great in terms of how far it's come!

Happy Friday.

BJRetro

@barbudreadmon @mitu following your steps, including adding the dev null to the config file you mentioned (my path on the initial steps to Modify the install script was a bit different, something like /home/pi/RetroPie-Setup/scriptmodules/libretrocores/lr-reicast.sh, but whatever) this is working on my rpi 3b+ Console version which is slightly overclocked the way people have previously recommended to overclock for N64 (was a long time ago now that I did those settings on this one). I am really intrigued about having an libreto version of this because I am thinking it might solve a problem I have on my bartop with virtuafighter 3tb+ because most of the Dreamcast games use analog but VF only uses digital controls. So I am thinking I will be able to enable “analog to digital”, save a game configuration file and play VF now without changing the settings for other games! Yay! Will test if that is true and report back. Meanwhile I tested Crazy Taxi and Virtua Fighter and they seemed to run good and although Marvel v Capcom seemed to lag with frameskip completely off at frameskip 1 it seemed to run about the same as standalone.

I have two “issues” right now.

(1) when you choose a rom first the screen goes to a black screen where you can see a script being run and then the game starts. I have to see if that only happens the first time you run a game or if it continues after. I will check over the weekend. Not a big deal but if this gets put back into the mainstream it could be something people complain about if it happens every time. Not sure if that is just me though.

I am not getting audio with this version although I do with the standalone omx and oss versions. I am running retropie 4.4. This prevents me from fully testing how well lr is working because part of it for me is hearing the audio cues that the game is running slow. If anyone has ideas why that might happen let me know. I know one of the Mupen emulators historically had an issue with this someone found a fix for.

In sum: I think this should be added back to the RetroPie setup script (assuming the few remaining steps we had to do to get it running can be automated) so people can decide what they want to use. I really thank you for bringing this to our attention. At this point I see no difference between this situation and Mupen. With Mupen people can assess for themselves whether they want the lr version or standalone and the debate can rage on as to performance, benefits of retroarch, etc on a per-game basis, which is what ultimately leads to better optimization and experience for all! Same thing here! Great work!

pjft

@BJRetro said in Working Dreamcast games:

I am not getting audio with this version although I do with the standalone omx and oss versions. I am running retropie 4.4. This prevents me from fully testing how well lr is working because part of it for me is hearing the audio cues that the game is running slow. If anyone has ideas why that might happen let me know. I know one of the Mupen emulators historically had an issue with this someone found a fix for.

Huh. That's interesting as I thought it'd be only me, as @quicksilver commented that his audio ran well.

We might do well in sharing our files for:

retroarch.cfg
/dev/shm/runcommand.log, with Verbose logging running

and see if anything stands out. If anyone who has a running setup with audio, it'd also be great if you could share yours for us to compare if something is amiss.

mitu

@pjft said in Working Dreamcast games:

@mitu for getting it working.

I actually didn't do anything besides adding that comment from the Github issue. @buzz already added the scriptmodule last year after the upstream development started.

quicksilver

I'm guessing my audio is working because I updated retroarch right before installing lr-recaist. However, now I have a frame counter running on multiple lr- emulators that I'm going to have to go through and manually turn off.

barbudreadmon

@pjft @BJRetro For what it's worth, i'm using alsa and sound is working.

BuZz

@quicksilver I noticed that on one of my systems (where I had intentionally let retropie save a full config out). Must be a parameter change in retroarch or a default value change or something to cause it (or maybe it's a bug). To fix just restore the default retropie retroarch.cfg (It's not a good idea to save the config out anyway as you lose the function of the global config then).

quicksilver

@BuZz So just replace the retroarch.cfg in the "all" folder? Do the retroarch.config.rp-dst only come with the binary install? I updated from source and it seems that retroarch.config.rp-dst is missing from all the system config folders.

mitu

@quicksilver Only the retroarch.cfg.rp-dist exists in /opt/retropie/configs/all/, the system's config folder don't get one. However, if you enabled 'Save config on exit', your systems' retroarch.cfg files contain a full RA config, which should override your global .cfg.

BuZz

@mitu @quicksilver All retroarch configs get the rp-dist one if when updating the existing one is different from the shipped retropie version. In this case it could be the one for the system that's changed - and probably is if it's only happening for certain systems.

mitu

@BuZz Aha, thanks for clearing that up.