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

bluestang

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:

Use @DirtBagXon's latest executable code with the additional font and nice overlay tech
Moved the executable into my ..\emulators\daphne folder
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:

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
Should use a similar launch script to Daphne, so you can literally just swap the emulator
Uses a RetroPie module script that can build for 32-bit or 64-bit
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

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:

roslof

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

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

I'll take a look now.

roslof

@DirtBagXon I tried lair2 and Hypseus. Game launches and if necessary builds dat files. The game exits/crashes immediately after the slates are rendered and before any overlay is displayed. The audible Lair 2 beep plays just before the crash.

Not a lot of information in the console output or from hypseus_log.csv:

2021/03/21;14:59:44.805;WARN;2394;0;lair2::repaint@988;"Surface does not match disc video, re-allocating surface!"
2021/03/21;14:59:53.494;WARN;2394;0;ldp1000::write@455;"Unimplemented Sony LDP command received: 0xC"
2021/03/21;14:59:55.660;INFO;2394;0;ldp_vldp::nonblocking_search@471;"NOTE: converting FPKS from 29970 to 23976. This may be less accurate."

Other games seem to work. Only lair2 isn't working with the update.

Hope this is helpful.

DirtBagXon

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

Hope this is helpful.

Ok, looks like a malloc() memory corruption on the Pi.

Will investigate.

DirtBagXon

@roslof

Ok, there is a patch in, local testing on Pi seems to now work - let me know.

Grab latest codebase. If you have already it cloned, just do:

git pull origin RetroPie

roslof

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

@roslof

Ok, there is a patch in, local testing on Pi seems to now work - let me know.

Grab latest codebase. If you have already it cloned, just do:
git pull origin RetroPie

That got it. Crash is fixed and the overlay w/new font is properly rendering for Dragon's Lair II. Looks great!

Optionally, for other overlays (referred to as "scoreboard" in the file hypinput.ini) Button3 toggles the visual on and off. Would consider this a "nice to have", but this is a very nice and welcome improvement.

Cheers!

roslof

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

interested if anyone uses any other versions, and the results.

I tried an older US ROM, version 3.14 (lair2_314). Weird behavior, but has nothing to do with your change...

At first, this version would freeze after Slates render... But after I ran it a couple of times -- after testing with Bluestang's version, which also froze, and the original Daphne which worked properly then going back to your latest version, the intro suddenly started working. Go figure. :) Overlay looks correct. Also unrelated to your change, you cannot add credits and start the game. Same issue with Bluestang's executable, so again -- not new.

I also tried the latest European version 3.19 (lair2_319_euro).
It loads and plays correctly, however the overlay does not display. Not sure if this is expected for PAL games.

DirtBagXon

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

I also tried the latest European version 3.19 (lair2_319_euro).
It loads and plays correctly, however the overlay does not display. Not sure if this is expected for PAL games.

The PAL lair2 games (Using a different Laserdisc player VP932) don't appear to have ever had this implemented (Daphne log):

VP932: Text on screen (ignored)
VP932: Got command 
D/W1007@  INSERT@
VP932: Text on screen (ignored)
VP932: Got command 
D/W1107@  COIN(S) @
VP932: Text on screen (ignored)

case 'D':
                {
                        if (vp932_command[1] == '0')
                        {
                                printline("VP932: Picture Number/time code display off (ignored)");
                        }
                        else if (vp932_command[1] == '1')
                        {
                                printline("VP932: Picture Number/time code display on (ignored)");
                        }
                        else if (vp932_command[1] == '/')
                        {
                                printline("VP932: Text on screen (ignored)");
                        }
                        else
                        {
                                printline("VP932: Error in 'D' command");
                                printline((const char*)vp932_command);
                        }
                }
                break;

DirtBagXon

Some exciting progress:

hypseus.bin singe vldp -framefile ~/.daphne/singe/timegal/timegal.txt -script ~/.daphne/singe/timegal/timegal.singe -homedir ~/.daphne/ -datadir ~/.daphne/

2021-03-22 10:08:25.918 INFO  [2535263] [reset_logfile@328] CPU : GenuineIntel || Mem : 15936 megs
2021-03-22 10:08:25.918 INFO  [2535263] [reset_logfile@329] OS : Linux 5.8 || Video : NVIDIA Corporation GK208B [GeForce GT 710] (rev a1)
2021-03-22 10:08:25.930 INFO  [2535263] [reset_logfile@330] RGB2YUV Function: C
2021-03-22 10:08:25.930 INFO  [2535263] [reset_logfile@336] Line Blending Function: C
2021-03-22 10:08:25.930 INFO  [2535263] [reset_logfile@343] Audio Mixing Function: C
2021-03-22 10:08:25.935 WARN  [2535263] [sound::init@208] WARNING : requested 2048 samples for sound buffer, but got 1024 samples
2021-03-22 10:08:25.953 INFO  [2535263] [SDL_input_init@285] No joysticks detected
2021-03-22 10:08:27.265 INFO  [2535263] [ldp_vldp::read_frame_conversions@1038] Framefile parse succeeded. Video/Audio directory is: /home/pi/.daphne/singe/timegal/./
2021-03-22 10:08:27.286 INFO  [2535263] [printline@95] Starting Singe version 1.14
[console] Starting Singe version 1.14

DirtBagXon

roslof

@dirtbagxon Bravo! Checking it out now.

roslof

Cheers, @DirtBagXon -- I got things running.

Tested a few Daphne games (no issues)
Tested a Singe game: Time Gal (no issues)

I am having an issue with Singe Game: Time Traveler. It parses the framefile & starts up with the Hologram Time Traveler Singe logo then exits. Log shows something about "Font surface is null!":

2021-03-23 19:32:45.357 INFO  [31012] [printline@95] Starting Singe version 1.14
2021-03-23 19:32:54.065 INFO  [31012] [printline@95] SINGE: Font surface is null!
2021-03-23 19:32:54.065 INFO  [31012] [printline@95] SINGE: Font surface is null!

For what it's worth, my package for Time Traveler (video files, m39.TTF font, images, etc.) is unchanged since using your previous version of Singe.

Hope this information is helpful.

roslof

@DirtBagXon one last question: Regarding fonts, framefile, pics, ram, roms & sound: Are Singe-based games and [traditional] Daphne-based games pulling from the same or from different locations? Should -homedir and/or -datadir affect the location of these folders?

DirtBagXon

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

@DirtBagXon one last question: Regarding fonts, framefile, pics, ram, roms & sound: Are Singe-based games and [traditional] Daphne-based games pulling from the same or from different locations? Should -homedir and/or -datadir affect the location of these folders?

Singe needs a few files from the pics and sound directories of Daphne (same folders). And of course the new fonts directory.

Your -homedir and -datadir should always point to the home directory of Daphne for both 'Daphne' and 'Singe', so on a RetroPie:

-homedir  /home/pi/RetroPie/roms/daphne -datadir /home/pi/RetroPie/roms/daphne

Assuming that is where those folders are.

The fonts loaded by Singe are dictated by the location in the .singe file. They are game specific and usually in the game directory, not like Daphne which uses the global fonts directory as above. On mine they are in the same directory as the other files, but if you have an edited singe file, may not be.

A grep in the timetraveller directory on mine shows:

grep -i ttf *.singe
dvd-globals.singe:fontDebug6pt = fontLoad("singe/timetraveler/m39.ttf", 6)
dvd-globals.singe:fontDebug8pt = fontLoad("singe/timetraveler/m39.ttf", 8)
dvd-globals.singe:fontDigital = fontLoad("singe/timetraveler/ds-digib.ttf", 18)

As you see the path will require the -datadir to be correct.

/home/pi/RetroPie/roms/daphne/singe/timetraveler/ds-digib.ttf

The font loaded where you specify is erroring isds-digib.ttf details:

-rw-r--r--  1  pi  pi  24896 Feb  1  1999 ds-digib.ttf

file ds-digib.ttf
ds-digib.ttf: TrueType Font data, 15 tables, 1st "OS/2", 21 names, Unicode

md5sum ds-digib.ttf
1467e2d37ec60cc50117a8db7c24f626  ds-digib.ttf

I tried to attach the font here, but it appears I can't. Why it worked on the older single I am not certain, but it may be SDL2 is being more strict.
It is loaded with the same internal SDL call: TTF_OpenFont()

These are just standard TTF fonts, so you can always copy it to your Windows, or Linux Desktop, and check by loading into your local fonts database.

On my RPi the font loads fine, horrible font but fine:

Singe is more troublesome than Daphne, as the .singe files are text editable LUA files, so are prone to being different from someone else, depending on where you got them from. However, on the plus side it means you can fix things yourself.

In Daphne the ROMS (i.e. what the .singe file replace) are binary dumps of data from the arcade machine boards and standard.

TimeGal and Ninja Hayate attempted to enforce something similar by using LUA bytecode (binary ), but that is another story.......

DirtBagXon

FYI: I have renamed the repo to hypseus-singe:

https://github.com/DirtBagXon/hypseus-singe

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

Wanted to thank @SaturnX for getting the ball rolling on this, and for the kick up the ass to get me thinking of Hypseus as a SDLv2 version of Singe.

I am going to sleep now.....

roslof

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

On my RPi the font loads fine, horrible font but fine:

I updated to the newer version of Time Traveler (2.0) and it works straight-away (FWIW, the older one only uses one font... Suspect my issue had something to do with not having an overlay font, as an overlay font was probably expected?)

Something odd though (and again, not your fault, rather what is inherited) --

The TTF is clean, when you view it by itself. Not sure why Hypseus is rendering the font in such a strange way (many characters (eg. H, I, L, X, Y, 1, 4) render higher than the other characters. They are also rendering somewhat inaccurately. Little errors all over the place, which gives it the ugly look.
Something wrong with the vector to raster system, my guess. Clean font:

font ds-digib.ttf.jpg