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

[DirtBagXon]

@roslof 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:

While it's not crashing, after the kill, was able to spot:

[New Thread 0xf0aad450 (LWP 1451)]

Thread 4 "vldp" received signal SIGBUS, Bus error.
[Switching to Thread 0xf0aad450 (LWP 1451)]
mpeg2_idct_copy_c (clock=0xf01045c0, dest=0xeff2b040 "", stride=-269308740) at idct.c:169
169           idct_row (block * 8 * i);
(gdb) 1405 Killed

Edit:
Ok, I have grabbed the original Hypseus repo code and ran it on a RPI 3b then switched to my changes. Apart from the overlay I see no difference in the video shown at this point, just incredibly slow at rendering. I don't believe my changes have degraded the vanilla status of hypseus, maybe someone who has this running reasonably well on their setup could expand.

 

 
Confirmation that Badlands et al also work in this port.
 

 
I also deleted the .dat  files for lair and badlands on Raspian 32bit and they were ALL recreated on both repos, so still unable to replicate this.

What kinda setup are you using? Software , kernel and SDL2 versions etc ?

 

[roslof]

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

What kinda setup are you using? Software , kernel and SDL2 versions etc ?

64-bit Kernel enabled:

Linux retropie 5.10.17-v8+ #1403 SMP PREEMPT Mon Feb 22 11:37:54 GMT 2021 aarch64 GNU/Linux

Also running KMS instead of FKMS.

SDL2 should be most recent (installed from RetroPie Setup Depends script for sdl2 (installed via source on Sat, 13 Mar 2021)

ii  libsdl2-2.0-0:armhf                    2.0.10+5rpi                         armhf        Simple DirectMedia Layer
hi  libsdl2-dev:armhf                      2.0.10+5rpi                         armhf        Simple DirectMedia Layer development files
ii  libsdl2-gfx-1.0-0:armhf                1.0.4+dfsg-3                        armhf        drawing and graphical effects extension for SDL2
ii  libsdl2-gfx-dev:armhf                  1.0.4+dfsg-3                        armhf        development files for SDL2_gfx
ii  libsdl2-image-2.0-0:armhf              2.0.4+dfsg1-1+deb10u1               armhf        Image loading library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-image-dev:armhf                2.0.4+dfsg1-1+deb10u1               armhf        Image loading library for Simple DirectMedia Layer 2, development files
ii  libsdl2-mixer-2.0-0:armhf              2.0.4+dfsg1-1                       armhf        Mixer library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-mixer-dev:armhf                2.0.4+dfsg1-1                       armhf        Mixer library for Simple DirectMedia Layer 2, development files
ii  libsdl2-net-2.0-0:armhf                2.0.1+dfsg1-4                       armhf        Network library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-net-dev:armhf                  2.0.1+dfsg1-4                       armhf        Network library for Simple DirectMedia Layer 2, development files
ii  libsdl2-ttf-2.0-0:armhf                2.0.15+dfsg1-1                      armhf        TrueType Font library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-ttf-dev:armhf                  2.0.15+dfsg1-1                      armhf        TrueType Font library for Simple DirectMedia Layer 2, development files

[DirtBagXon]

@roslof

I'm running it on older versions than you, on Rasbian RPi3b.

SDL2 is supposed to figure out all the acceleration for you. According to the imprecise documentation......

"SDL 2.0 changes this; you almost always get hardware acceleration now, and the API has changed to reflect this." -lol

ii  libsdl2-2.0-0:armhf              2.0.5+dfsg1-2+rpt1                armhf        Simple DirectMedia Layer
ii  libsdl2-dev                      2.0.5+dfsg1-2+rpt1                armhf        Simple DirectMedia Layer development files
ii  libsdl2-image-2.0-0:armhf        2.0.1+dfsg-2+deb9u2               armhf        Image loading library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-image-dev:armhf          2.0.1+dfsg-2+deb9u2               armhf        Image loading library for Simple DirectMedia Layer 2, development files
ii  libsdl2-ttf-2.0-0:armhf          2.0.14+dfsg1-1                    armhf        TrueType Font library for Simple DirectMedia Layer 2, libraries
ii  libsdl2-ttf-dev:armhf            2.0.14+dfsg1-1                    armhf        TrueType Font library for Simple DirectMedia Layer 2, development files

I guess I will need to get a RetroPie dev setup at some point.....

To get bluestang2006 libmpeg patch on this repo, before the mkdir build do:

wget https://github.com/bluestang2006/hypseus/commit/76bc01fdf09152820fff88c28c61b2bea1b47ecf.patch -O patch.diff
patch -p1 < patch.diff
sudo apt-get install libmpeg2-4-dev
mkdir build
cd build
cmake ../src/
make

[roslof]

@dirtbagxon I confirmed that the 64bit kernel is not compatible with default compile. If @bluestang's patch fixes this (compatible compiler options/includes?) I'll inform.

[DirtBagXon]

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

@dirtbagxon I confirmed that the 64bit kernel is not compatible with default compile. If @bluestang's patch fixes this (compatible compiler options/includes?) I'll inform.

But this is 64bit kernel with 32bit userland - correct ?

[roslof]

@dirtbagxon forgive, I'm unclear/green on userland. Only know that @bluestang's patch + installer run fine with these settings (KMS/64-bit kernel). Will try his patch with your build shortly.

[DirtBagXon]

@roslof

file /usr/local/bin/hypseus.bin

[roslof]

@dirtbagxon looks like 32-bit

/usr/local/bin/hypseus.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=0870fd6f38c57af407124e243bb5b7f06f4319bd, with debug_info, not stripped

[DirtBagXon]

@roslof

This may go some way to explain the .dat  file creation issues...

[roslof]

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

@roslof

This may go some way to explain the .dat  file creation issues...

Maybe, but this was not an issue with @bluestang's compile, and I verified it is also a 32-bit file. All dats I have now were generated with his exe.

[DirtBagXon]

@roslof

Looking here: https://retropie.org.uk/forum/post/254740

It appears that patch should cover it with local libmpeg2-4

[roslof]

The TLDR: Success! Dragon's Lair runs with 64bit Kernel + KMS

The Output:

wget https://github.com/bluestang2006/hypseus/commit/76bc01fdf09152820fff88c28c61b2bea1b47ecf.patch -O patch.diff

(received)

patch -p1 < patch.diff

patching file src/CMakeLists.txt
patching file src/vldp/vldp.h
patching file src/vldp/vldp_internal.cpp

sudo apt-get install libmpeg2-4-dev

libmpeg2-4-dev is already the newest version (0.5.1-8).

mkdir build

done, and added cd build

cmake ../src

good

make

good

then mv hypseus hypseus.bin
and sudo cp hypseus /usr/local/bin/hypseus.bin (overwriting previous executable)

RESULTS:
Success! Dragon's Lair runs with 64bit Kernel + KMS

[DirtBagXon]

@roslof

Or just grab this pre-patched branch in future:

git clone --single-branch --branch RetroPie https://github.com/DirtBagXon/hypseus-singe.git

[roslof]

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

@roslof

Or just grab this pre-patched branch in future:

git clone --single-branch --branch RetroPie https://github.com/DirtBagXon/hypseus.git

Hindsight 20/20. Great work on this, man.

[DirtBagXon]

@roslof

Well, didn't expect my few days off to be spent like this :)

Great news, thanks for all the testing.

░░░░░░░░░░░░▄▄░░░░░░░░░
░░░░░░░░░░░█░░█░░░░░░░░
░░░░░░░░░░░█░░█░░░░░░░░
░░░░░░░░░░█░░░█░░░░░░░░
░░░░░░░░░█░░░░█░░░░░░░░
███████▄▄█░░░░░██████▄░
▓▓▓▓▓▓█░░░░░░░░░░░░░░█░
▓▓▓▓▓▓█░░░░░░░░░░░░░░█░
▓▓▓▓▓▓█░░░░░░░░░░░░░░█░
▓▓▓▓▓▓█░░░░░░░░░░░░░░█░
▓▓▓▓▓▓█░░░░░░░░░░░░░░█░
▓▓▓▓▓▓█████░░░░░░░░░█░░
██████▀░░░░▀▀██████▀░░░

[bluestang]

@dirtbagxon @roslof

Awesome that another fork is out there for users to try.

My patch should work with both 32-bit and 64-bit RPiOS. The userland for each should be their respective kernel, i.e. armhf (32-bit) or aarch64 (64-bit). It is not a good idea to mix binaries so I have separate thumb drives for both images.

I exclusively use the 64bit though because gcc compiled binaries guarantees NEON optimizations and overall I find the end user experience to be very good.

In addition the KMS driver is in a very stable state in the 5.10.X kernels as well as the KMS audio driver.

[DirtBagXon]

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

@roslof They were, and it probably can - but you might even get away with a simple compiler flag. I don't have it at hand, but if you check my last commit on the RetroPie-Setup repo for the daphne installer, as well as the makefiles in Daphne, you might see it.

The issue was related to how the compiler handled the default type for char - as signed or unsigned int.

https://stackoverflow.com/questions/46463064/what-causes-a-char-to-be-signed-or-unsigned-when-using-gcc

If I recall correctly, we want these to be... signed?

Hey @pjft,

These are committed to Hypseus here:

https://github.com/DirtBagXon/hypseus/commit/be31cfb503b00e6f493d217287c

[roslof]

@dirtbagxon @bluestang between the two of you, I am running things nicely like this:

1. Use @DirtBagXon's latest executable code with the additional font and nice overlay tech
2. Moved the executable into my ..\emulators\daphne folder
3. Paired it with @bluestang's hypseus.sh script (greatly preferred, as it mirrors the current Daphne format)

With all of these little changes (and tweaks to the script and RetroPie emulators.cfg file to support) this is almost perfect... My code is 32-bit and I'm running on 64-bit.

Since KMS and 64-bit will be more and more leveraged by the community, and since Daphne stand-alone will simply not work with this configuration, I would advise this hybrid approach. I think it'll be easier to accept into the RetroPie master branch if:

1. Users won't have to move their folders around from default (should remain as <romname>.daphne and not rely on vldp_dl and vldp folders
2. Should use a similar launch script to Daphne, so you can literally just swap the emulator
3. Uses a RetroPie module script that can build for 32-bit or 64-bit
4. That supports @pjft's fixes for Bega, Badlands and Road Blaster (so feature parity with Daphne)
5. And with the new, nice overlay support with font

Would the two of you consider this approach? And for what it's worth, I have no say on what get into experimental modules, but as a user, this would make me incredibly happy -- to finally see a supported Daphne/Laserdisc emulator that is basically plug-and-play, but with nice new features for KMS and 32/64-bit support.

Personally, I'm set up pretty good now, but it took a bit of time to get it just right.

[DirtBagXon]

@roslof

Happy for that approach, however I have no knowledge of packaging RetroPie plugins, so would be better to leave that to those who know more. The real issue here is the sheer amount of complex argument options that Daphne/Hypseus take. I tackled this with the wrapper script inherited, and repeatedly edited, from DavidGriffith's original Daphne repo. This is the whole reason the original (closed source) Daphne Loader application used to exist, and even that was a bit of a nightmare to use....

Users won't have to move their folders around from default (should remain as <romname>.daphne and not rely on vldp_dl and vldp folders

All this can be easily done by editing the wrapper script to reference whatever directories you want/need. It's all in editable text in run.sh.

Should use a similar launch script to Daphne, so you can literally just swap the emulator

Hypseus is statically linked to the vldp module now, which means it's a monolithic binary that can be installed and run from anywhere. This is a big advantage over the shared library path hassles required to link to libvldp2.so in the older repos. Should, and can, be a straight swap out of the binary.

That supports @pjft's fixes for Bega, Badlands and Road Blaster (so feature parity with Daphne)
And with the new, nice overlay support with font

Use the new repo and fork it.

Uses a RetroPie module script that can build for 32-bit or 64-bit

I have no idea here...

 
Note:
I have also just pushed another couple of fixes, one removes the need to use --useoverlaysb in the startup arguments.

As DL games will no longer display video without it, why make it optional? Passing it as an arg will still work, and can change it from the '2' default.

Note: there are actually only two options, '2' or anything else.....

if (sboverlay_characterset != 2)
    g_other_bmps[B_OVERLAY_LEDS] = load_one_bmp("pics/overlayleds1.bmp");
else
    g_other_bmps[B_OVERLAY_LEDS] = load_one_bmp("pics/overlayleds2.bmp");

I may begin to look at getting the Singe v1 plugin into Hypseus. The Singe code appears to have all been stripped out of the codebase so this may be no small task. But if I get some more time to play I may try for my own interest. We always have Singe2 to fall back on....

 

[DirtBagXon]

Now have Dragon's Lair II (lair2) overlays working in Hypseus.

I only use lair2 ROM 3.19 (US) - so be interested if anyone uses any other versions, and the results.

It requires another FIXED width font (whitrabt.ttf ).
So ensure you add that to the fonts directory.

It should however warn you if it isn't there:

 

 

Now with better alignment: