New Hypseus and lr-Daphne to add on Retropie-Setup

DirtBagXon

@jamrom2 said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon

I installed everything I wanted from my "list" and a few extras. The version of Cliff Hanger you used is fantastic, but it's too much for my Pi3B+. How did you create the framefile and is there one that uses a lesser video scale but still uses the Singe side as well?

The best approach would be to downscale the existing 1080p Singe video with ffmpeg

ffmpeg -i cliff.m2v -an -qscale:v 4 -b:v 6000k -vf scale=1280:720 -codec:v mpeg2video 720_cliff.m2v

As your re-encoding there will be a slight loss of quality, but probably nothing you will realise due to to downsize in resolution in any case.
We keep the bittate high with -qscale:v 4 - See ffmpeg docs.

You can check the frames are equal, on each, after the recode with mediainfo

mediainfo --Inform='Video;%FrameCount%' cliff.m2v
36780
mediainfo --Inform='Video;%FrameCount%' 720_cliff.m2v
36780

See my Singe 2 porting repo for links on how to get these tools.

Each game incarnation has a different frame layout, so you can't really use a video from one game in another version without rewriting all the game frame reference code in the LUA. This is one inherent issue with Singe (which will have fan changes and tweaks), unlike Daphne where the ROM frame references will always be the same. It's better to keep the video with the LUA code. You then just have to deal with the means to distribute it like that, and the inherent consequences.

Provided you have a decent quality source, down-scaling the video shouldn't be an issue. So having the 1080p will always allow you to get the games running on lower spec hardware, with a little work. Singe overlays are written to work with source video resolution, but hypseus will try to align on the new resolution. Some games have options to move sprites around in the Service menu (9 in-game ).

Others, you may need to make minor alignment changes in the LUA (text editing - main.singe - spriteDraw(x,y,sprite[LIVES]) ).

This is Daphne, but see my Dragon's Lair on a Pi Zero (first Gen), using downscaled video, in the forum here.

jamrom2

@dirtbagxon

I finished up the video conversions, and it looks great... but the audio is still way off. Lagging behind a few seconds.

Is there a way to build new OGG files based on the new M2V files? I've tried a few on line converters, but that was fruitless.

The video is very impressive though. Much better than what I had before.

DirtBagXon

@jamrom2 said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon

I finished up the video conversions, and it looks great... but the audio is still way off. Lagging behind a few seconds.

Is there a way to build new OGG files based on the new M2V files? I've tried a few on line converters, but that was fruitless.

The audio shouldn't need recoding, as the recode of video should not have changed anything timing related.

You can play with the start audio timing with -ss as detailed here in the porting repo. Daphne, and therefore Hypseus, are very specific about the frequency of .ogg files (see discussion), so you need to use specific arguments passed to ffmpeg.

There is normally only two reasons for this sync issue I have seen:

Resource exhaustion
FPS mistimings

As you have downsized the video, it shouldn't be using too much CPU to cause exhaustion... You can check by running top in an ssh session when the game is running.

Can you see anything in the logs when this occurs ?

cat /dev/shm/runcommand.log

Maybe also share the mediainfo output for the current .m2v and .ogg files.

sudo apt-get install mediainfo

mediainfo cliff.m2v and mediainfo cliff.ogg on the relevant files.

I do think that some of these Singe 2 HD titles are pushing the limits of the 32bit OS on the Pi <= RPi3

I tried the recode on video (as above ) on my RPi3b and am not seeing the issue, although performance on the Pi4 running full aarch64 from raspberrypi.org is significantly better.

You could test if the Pi is the cause of the issue by grabbing the Windows version of Hypseus and running the same game files. It will eliminate the recoding as the cause.

jamrom2

@dirtbagxon I'm actually using the videos that are broken down into sections by level.

I can try the Singe 2.0 set as well now that you taught me to how it's done. In fact I will just to see what the difference is.

At any rate...

Here is the runcommand.log
https://pastebin.com/kEJJXrKu

And, unfortunately, a screen shot of the mediainfo. I'm just not that good with Linux to do the black box thing you guys always do.

Hopefully there is something in these files you see, because everything looks like it should. The sound is good, it's just not synched with the video. And again.. the video is fantastic, even condensed to 720p.

DirtBagXon

@jamrom2 said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon I'm actually using the videos that are broken down into sections by level.

Ok, so this the the original Singe 1 release.

And, unfortunately, a screen shot of the mediainfo. I'm just not that good with Linux to do the black box thing you guys always do.

Just paste text using the </> tags above ;)

The image is perfectly readable. Also it doesn't show any issues at you state.

Hmmm.. it does appear that some of these games are gonna be problematic on the Pi.

I don't believe that there has ever been a widely adopted version of Singe (1) on Linux previously (at least several people have told me this). Most of the early Singe 1 games created by a guy known as RDG (worked with Scott Duensing who wrote Singe) used SD video (720x480 in nearly all cases ) back in 2009-10. All of these work perfectly on the Pi.

Then around 2019 a group of guys tackled new games (we know their names) but these were pretty much all designed to work on Windows Daphne Singe (as this was the most widely adopted platform, but used bitrot SDL1 ). Resources are not really much a consideration on games like these in Windows. This re-interest is what started the Singe 2 application, which gets a whole lot more resource intensive especially with the full 32bit overlays (Singe 1, and Hypseus, use simple 8bit overlays and are vastly lightweight in comparison, alongside looking more Retro IMHO ).

I'm not using excuses here, honest, but I think what is starting to become clear is that these later HD (2019), and Singe 2, games have MPEG-2 video that pushes the Pi limits.

Hypseus comes with an optimised version of the libmpeg2 library which works on (x86) Linux, Windows and Mac. But not on the Pi (ARM), we have to use the ARM optimised packaged version of the library from Raspberry Pi OS: https://raspbian.mirror.ac.za/raspbian/pool/main/m/mpeg2dec/

Even this ARM libmpeg2 package (On Pi's up to 3b+ ) didn't use mmal or v4l/v4l2 for GPU hardware acceleration. MPEG-2 decoding through hardware is no longer available as of the Pi4, so all MPEG-2 decoding, on all Pi's, is done on the CPU: https://forums.raspberrypi.com/viewtopic.php?p=1947760#p1947760

I have had reports now that (Singe) Cliff and Asterix games seem particularly troublesome on the Pi. 64bit Pi4 included. I cannot see why these titles in particular are more problematic, video encoding looks identical to others via mediainfo. Even when downscaled with ffmpeg they still appear to have issues, which seems like it is possibly some frame timing/encoding issue. If anyone has more insight on this, I would be grateful. I am no expert here, but it does appear to be platform specific.....maybe.....

At least we have the Daphne version of 'cliff' to cover one of these problematic games. (The Daphne version is available in a true 4k version in Hypseus, which will definitely only work on x86 - see screenshot here ).

The current Pi implementations still use an early SDL2 version, this may also be an issue. SDL2 1.0.16 suddenly bought the Windows version of Hypseus to life, with no other changes or optimisations. So I am hopeful we may see improvements when the Pi OS's default SDL2 version catches, or surpasses, this.

This still, of course, leaves all the Daphne games and 30+ Singe games that should run fine on the current generation of Pi's.

Hopefully there is something in these files you see, because everything looks like it should. The sound is good, it's just not synced with the video. And again.. the video is fantastic, even condensed to 720p.

I am not certain I have a solution on singe 'cliff' as per above.... sorry..... maybe the next generation of Pi will bump this comment.

jamrom2

@dirtbagxon I forget when I actually started using Daphne on my MAME cabinet. It was right when it first came out for windows, even before the GUI version. I think 2002 or 2003? It's been that long.

But up until recently, when guys like yourself (are you by chance Otto on the other forum?) and Karis stepped in to the scene to help clean-up videos and teach others how to do the same, the quality was always visually crappy as for whatever reason, Digital Leisure did a poor job of converting the videos from the original.

But now, at 4k and all the deep resolution and quality, its a trade-off. I'd rather have what we have now and build a system around it, rather than what was in the past. The videos and audio quality are just THAT good now whereas, we thought it looked good because it was a cartoon game playing on a CRT back when this all came out.

I can only be extremely thankful and appreciate all that you have done and continue to do with this project and getting it up and running on RetroPie. I already switched Cliff Hanger back to my original, which is in 640x480 HD and looks very good running on just straight Daphne. It's fine. Because of you, I picked up a few more games and learned A LOT about how this all plays together.

You're an asset to this fun hobby! Thanks for putting so much time in.

In the meantime... it's about time I moved up to a Pi4 and started a new build.

best,
JamR

One more thing I was thinking about Cliff Hanger... it might be the actual overlays that are causing the drag on the Pi. I've seen this with lr-DosBox-Pure and other higher systems that use shaders and overlays. It just beats the Pi to a pulp. If you try the same game in the more native DosBox-Staging which does not support overlays and is not in the Librettro core, it's very smooth... up until you play games higher than the Pi can handing in that range as well.

DirtBagXon

@jamrom2 said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon I forget when I actually started using Daphne on my MAME cabinet. It was right when it first came out for windows, even before the GUI version. I think 2002 or 2003? It's been that long.

You're an asset to this fun hobby! Thanks for putting so much time in.

It's a pleasure.

One more thing I was thinking about Cliff Hanger... it might be the actual overlays that are causing the drag on the Pi. I've seen this with lr-DosBox-Pure and other higher systems that use shaders and overlays. It just beats the Pi to a pulp. If you try the same game in the more native DosBox-Staging which does not support overlays and is not in the Librettro core, it's very smooth... up until you play games higher than the Pi can handing in that range as well.

I don't think the overlay in Hypseus will be the issue, it is incredibly lightweight. Pretty certain it's down to CPU decoding of MPEG-2 streams.

Darksavior

@DirtBagXon Lost hw acceleration with the new retropie sdl2 2.0.20 update.

I installed the latest retropie weekly pi4 build and tested with the preinstalled sdl2 and hypseus is fine. As soon as I update the retropie-setup script and install the the new sdl2 from binary or source, then hypseus is a desynced slide show.

DirtBagXon

@darksavior said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@DirtBagXon Lost hw acceleration with the new retropie sdl2 2.0.20 update.

I installed the latest retropie weekly pi4 build and tested with the preinstalled sdl2 and hypseus is fine. As soon as I update the retropie-setup script and install the the new sdl2 from binary or source, then hypseus is a desynced slide show.

Just compiled SDL 2.0.20 (changelog is minimal) on the Pi4 ...

git clone https://github.com/libsdl-org/SDL
cd SDL/
git reset --hard b424665e0899769b200231ba943353a5fee1b6b6
mkdir build 
cd build
../configure
make

Checked hypseus is linking against it:

[version] Hypseus Singe: v2.8.0-RPi
[console] Linux 5.10
[console] SDL(CC): 2.0.14
[console] SDL(LD): 2.0.20
[console] Compiled: Jan 29 2022 23:15:29

I am seeing no issues here running several games.....

I haven't checked if RetroPie is providing any specific build flags to its SDL source build. I built vanilla, as you can see, and linked in /etc/ld.so.conf.d.

You could try the new -novsync and/or -opengl flags with hypseus.

Anyone offer an explanation on this behaviour.. ?

Edit: Just checked some of the HD Singe videos and playing fine too.....

2nd Edit: it also appears that 2.0.20 has fixed the ActionMax issue on the Pi !!!! I have just been playing fine - Whoo Hoo....

Darksavior

@dirtbagxon
Log file: https://pastebin.com/zwMLkrxi
Tested using the pre-installed binary of hypseus. I believe it's listing both times I ran it. Once with the preinstalled sdl2 (2.0.16 maybe?) and the 2nd time with 2.0.20.
And yes, the game runs fine at that resolution before the update.
There is no change when using those flags.

DirtBagXon

@darksavior said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon
Log file: https://pastebin.com/zwMLkrxi
I believe it's listing both times I ran it. Once with the preinstalled sdl2 (2.0.16 maybe?) and the 2nd time with 2.0.20.
And yes, the game runs fine at that resolution before the update.

There are no errors there, but this isn't an issue with Hypseus functionality, it's an SDL interaction with the display.

~~Did you try the -novsync or -opengl arguments?~~
Ok, sorry missed that bit - so no difference....

I am no expert on the display environment RetroPie provides in these weekly builds and how it may have changed. This is a change in the SDL interaction with the display between SDL versions. I may be able to offer a flag to overcome an issue, but I need to understand the issue first.

As this SDL release has fixed a standing issue with ActionMax, which now allows Hypseus to read pixel data from the SDL Texture on the GPU. SDL has obviously undergone more changes than the Changelog states for the Pi.

I am hoping someone may be able to offer some insight as to how the display environment and SDL 2.0.20 could have changed in RetroPie between these versions on a weekly build?

I cannot replicate the issue on a standard Rasbian Desktop release with SDL 2.0.20, and in fact I see the SDL improvements, listed above, with it in that environment....

Of course as it's a weekly build it may also be a bug in the current RetroPie build...

Thoughts...

Darksavior

@dirtbagxon Retropie doesn't support bullseye right now but I also tried their custom sdl 2.0.20 a week or so ago on it.

On 32bit bullseye lite I get the same slowdowns/desyncs as their weekly 32bit buster build with 2.0.20.
On 64bit bullseye lite the problem doesn't exist...

sdl 2.0.20 installer: https://raw.githubusercontent.com/RetroPie/RetroPie-Setup/039407c5ed012286924ea0d8b3b782974aa4fab5/scriptmodules/supplementary/sdl2.sh
The sdl2 installer included with the weekly buster build: https://pastebin.com/rMT3eDvn

mitu

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I am no expert on the display environment RetroPie provides in these weekly builds and how it may have changed. This is a change in the SDL interaction with the display between SDL versions. I may be able to offer a flag to overcome an issue, but I need to understand the issue first.

The major change in the KMSDRM display driver in 2.0.20 is the ability to change resolutions, but there have been also other changes added to the driver which may have an effect. If you're running on the desktop, you are not using the KMSDRM display driver though, but the X11 one, so if there's something caused by it, you may not notice it.

DirtBagXon

@darksavior said in [New Hypseus and lr-Daphne to add on Retropie-Setup]

On 32bit bullseye lite I get the same slowdowns/desyncs as their weekly 32bit buster build with 2.0.20.
On 64bit bullseye lite the problem doesn't exist...

Ok, so this is smelling more like a bug in 32bit

I'll try and get the 2.0.20 libraries running on my 4.7.1 install to see if I can see what this might be.....

DirtBagXon

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

The major change in the KMSDRM display driver in 2.0.20 is the ability to change resolutions, but there have been also other changes added to the driver which may have an effect. If you're running on the desktop, you are not using the KMSDRM display driver though, but the X11 one, so if there's something caused by it, you may not notice it.

Thanks @mitu

I am pretty certain that KMSDRM has not been an issue thus far, I have a couple of guys who run hypseus on the bleeding edge "rasbian" stuff without any X11 libraries whatsoever, and they feedback to me. They do however all run in full aarch64. Last bug report I had was in 2.0.16 which was fixed (nothing display related ), I'll try and ping them to check 2.0.20.

SDL 'should' be behaving the same in 32/64 land, the SDL calls are identical......

DirtBagXon

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above. Installed in /usr/local/lib

I patched hypseus to show the loaded SDL library version when run.

I can switch between SDL versions simply by adding /usr/local/lib to the first line of /etc/ld.so.conf.d/arm-linux-gnueabihf.conf and running sudo ldconfig

Executing: /opt/retropie/emulators/hypseus/hypseus.sh "/home/pi/RetroPie/roms/daphne/dle21.daphne"
[version] Hypseus Singe: v2.8.1-RPi - SDL(LD): 2.0.10
[console] Setting alternate home dir: /opt/retropie/emulators/hypseus

Parameters:
Executing: /opt/retropie/emulators/hypseus/hypseus.sh "/home/pi/RetroPie/roms/daphne/dle21.daphne"
[version] Hypseus Singe: v2.8.1-RPi - SDL(LD): 2.0.20
[console] Setting alternate home dir: /opt/retropie/emulators/hypseus

Using v4.7.1 default package 2.0.10 libraries, all is good.

Switching to 2.0.20, using default compile options, I see the slowdown, but ActionMax games work...

Dropping back to 2.0.10 source, with default compile options, all is good once again.

Built 2.0.10 again with compile arguments from the setup script provided, no change.

Moved to 2.0.12 source - working

Build with, and without, from this point: --enable-video-rpi --enable-video-kmsdrm --disable-video-x11 --disable-video-vulkan

Moved to 2.0.14 source - working

Couldn't get 2.0.14 to compile with these flags..

/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c: In function 'KMSDRM_CreateWindow':
/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c:1765:71: error: 'EGL_PLATFORM_GBM_MESA' undeclared (first use in this function)
              if ((ret = SDL_EGL_LoadLibrary(_this, NULL, egl_display, EGL_PLATFORM_GBM_MESA))) {
                                                                       ^~~~~~~~~~~~~~~~~~~~~
/home/pi/SDL/src/video/kmsdrm/SDL_kmsdrmvideo.c:1765:71: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:635: build/SDL_kmsdrmvideo.lo] Error 1

From SDL 2.0.16 this issue arises - with or without compile flags

This is only occurring on 32bit, aarch64 builds and works fine on all the testbeds I could put together. I know guys running full KMSDRM on 2.0.16 in aarch64 without issue.

Between SDL 2.0.14 and 2.0.16 the most obvious culprit is:

Added Vulkan support to the KMSDRM video driver

I tried disabling/adding various Window/Renderer SDL flags to hypseus in order to work around this. Nothing seems to work. CPU is pegged up at 80%+ so it does in fact appear like HWACCEL is failing.....

mitu

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above [...]

RetroPie doesn't use KMSDRM on a Pi3, only on the Pi4. If you used the 'installer' posted by @Darksavior previously, then this is your issue: the RPI video driver - which gives acceleration on the Pi3) - is not enabled with that.

2.0.20 has been added (yesterday) in RetroPie - just update your setup and re-test, you don't need to compile SDL manually.

DirtBagXon

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

Ok, so on vanilla v4.7.1 on a Pi3 running (full 32bit) I compiled SDL 2.0.20 as above [...]

RetroPie doesn't use KMSDRM on a Pi3, only on the Pi4. If you used the 'installer' posted by @Darksavior previously, then this is your issue: the RPI video driver - which gives acceleration on the Pi3) - is not enabled with that.

I didn't run the 'installer' - I compiled manually from SDL github source.

With and without arguments in that installer script, so configure will have picked up most things.

I gave the following arguments when I compiled with them: --enable-video-rpi --enable-video-kmsdrm --disable-video-x11 --disable-video-vulkan

So what should I add for acceleration on the Pi3 ? I should note that up to 2.0.14 works fine from source.

2.0.20 has been added (yesterday) in RetroPie - just update your setup and re-test, you don't need to compile SDL manually.

If I do this, I can't test incremental changes in SDL. Up to 2.0.14 works fine. I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

mitu

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

We have a few patches added so it's more than just the compile flags.

EDIT: are you sure your setup is using the KMSDRM driver ? You would need to modify the config.txt boot configuration file to enable it, it won't work out-of-the-box on a Pi3 with the RetroPie image.

DirtBagXon

@mitu said in New Hypseus and lr-Daphne to add on Retropie-Setup:

@dirtbagxon said in New Hypseus and lr-Daphne to add on Retropie-Setup:

I assume that RetroPie does nothing special to SDL rather than compile time arguments ?

We have a few patches added so it's more than just the compile flags.

EDIT: are you sure your setup is using the KMSDRM driver ? You would need to modify the config.txt boot configuration file to enable it, it won't work out-of-the-box on a Pi3 with the RetroPie image.

Ok, I think I have pretty much seen that it is not necessarily related to KMSDRM, but is related to SDL version and 32bit land.

I'm not clear how to proceed on this in RetroPie.

I want to be able to configure various SDL commits from github to trace the issue, so kinda need a means to be able to do this in a controlled manner. In the method I describe above, I can just switch SDL libraries to whatever version I need to test, and back. How can I do this with RetroPie specific changes and have your local patches, and compile flags, available in those libraries easily?

I am certainly not qualified to tease through all the SDL commits to locate specific changes here.

Whether I do this on a Pi3 or Pi4 distributions seems mute at this point as they both exhibit the issue in later versions of SDL after the previous 2.0.10 package.

Edit: I have just tested SDL 2.0.20 libraries against both 32bit and 64bit Windows builds of Hypseues. And the issue isn't there. This is looking implementation specific....