(REQUEST) Add Daphne Singe emulator?

pjft

@shift The changes were done to support the Raspberry Pi, so they'd better :) More seriously, yes, just install from source from the RetroPie menu and it should be good to go.

shift

@pjft said in (REQUEST) Add Daphne Singe emulator?:

@shift The changes were done to support the Raspberry Pi, so they'd better :) More seriously, yes, just install from source from the RetroPie menu and it should be good to go.

Badlands, Bega's Battle, and Road Blaster work too!

shift

@pjft @dirtbagxon

Is there a command to check which roms daphne can run? I have searched around but there are no official lists of alternative roms it can run.

DirtBagXon

@shift said in (REQUEST) Add Daphne Singe emulator?:

@pjft @dirtbagxon

Is there a command to check which roms daphne can run? I have searched around but there are no official lists of alternative roms it can run.

@shift - Take a look at the Game Types here:

http://www.daphne-emu.com/mediawiki/index.php/CmdLine

Retropie, seems to have a compatibility list here too:

https://github.com/RetroPie/RetroPie-Docs/blob/master/docs/Daphne.md

shift

@dirtbagxon said in (REQUEST) Add Daphne Singe emulator?:

@shift - Take a look at the Game Types here:

http://www.daphne-emu.com/mediawiki/index.php/CmdLine

Retropie, seems to have a compatibility list here too:

https://github.com/RetroPie/RetroPie-Docs/blob/master/docs/Daphne.md

Thanks, but unfortunately in those pages there is a lot of approximation, for example the rom dle20, which I know for sure that it works, is not even mentioned there. I would like to understand if it is possible to extrapolate from the code a precise list of roms that can be launched (not that they have to work, only that they can be launched).

DirtBagXon

@shift said in (REQUEST) Add Daphne Singe emulator?:

@dirtbagxon said in (REQUEST) Add Daphne Singe emulator?:

@shift - Take a look at the Game Types here:

http://www.daphne-emu.com/mediawiki/index.php/CmdLine

Retropie, seems to have a compatibility list here too:

https://github.com/RetroPie/RetroPie-Docs/blob/master/docs/Daphne.md

Thanks, but unfortunately in those pages there is a lot of approximation, for example the rom dle20, which I know for sure that it works, is not even mentioned there. I would like to understand if it is possible to extrapolate from the code a precise list of roms that can be launched (not that they have to work, only that they can be launched).

If you want every game listed with a ROM entry in the codebase, then I would do: git grep m_shortgamename

git grep m_shortgamename
src/game/astron.cpp:    m_shortgamename = "astronp";
src/game/astron.cpp:    m_shortgamename = "blazer";
src/game/astron.cpp:    m_shortgamename = "galaxyp";
src/game/astron.cpp:    m_shortgamename = "astron";
src/game/astron.cpp:    m_shortgamename = "galaxy";
src/game/astron.cpp:    m_shortgamename = "cobraab";
src/game/badlands.cpp:  m_shortgamename = "badlands";   
src/game/badlands.cpp:  m_shortgamename = "badlandp";   
src/game/bega.cpp:   m_shortgamename = "bega";
src/game/bega.cpp:         m_shortgamename = "begar1";
src/game/bega.cpp:   m_shortgamename = "cobra";
src/game/bega.cpp:   m_shortgamename = "roadblaster";
src/game/cliff.cpp:     m_shortgamename = "cliff";
src/game/cliff.cpp:     m_shortgamename = "gtg";
src/game/cliff.cpp:     m_shortgamename = "cliffalt";
src/game/cliff.cpp:     m_shortgamename = "cliffalt2";
src/game/cobraconv.cpp: m_shortgamename = "cobraconv";
src/game/esh.cpp:       m_shortgamename = "esh";        
src/game/esh.cpp:               m_shortgamename = "eshalt";
src/game/esh.cpp:               m_shortgamename = "eshalt2";
src/game/esh.cpp:       m_shortgamename = "eshalt";
src/game/esh.cpp:       m_shortgamename = "eshalt2";
src/game/ffr.cpp:       m_shortgamename = "ffr";
src/game/firefox.cpp:   m_shortgamename = "firefox";
src/game/firefox.cpp:   m_shortgamename = "firefoxa";
src/game/gpworld.cpp:   m_shortgamename = "gpworld";
src/game/interstellar.cpp:      m_shortgamename = "interstellar";
src/game/lair.cpp:      m_shortgamename = "lair";
src/game/lair.cpp:                      m_shortgamename = "lair_f";
src/game/lair.cpp:                      m_shortgamename = "lair_e";
src/game/lair.cpp:      m_shortgamename = "dle11";
src/game/lair.cpp:      m_shortgamename = "dle21";
src/game/lair.cpp:              m_shortgamename = "dle20";
src/game/lair.cpp:      m_shortgamename = "ace";
src/game/lair.cpp:              m_shortgamename = "ace_a2";
src/game/lair.cpp:              m_shortgamename = "ace_a";
src/game/lair.cpp:      m_shortgamename = "sae";
src/game/lair.cpp:      m_shortgamename = "lair_a";
src/game/lair.cpp:              m_shortgamename = "lair_b";
src/game/lair.cpp:              m_shortgamename = "lair_c";
src/game/lair.cpp:              m_shortgamename = "lair_d";
src/game/lair.cpp:              m_shortgamename = "lair_n1";
src/game/lair.cpp:              m_shortgamename = "lair_x";
src/game/lair2.cpp:     m_shortgamename = "lair2";
src/game/lair2.cpp:     m_shortgamename = "ace91";
src/game/lair2.cpp:                     m_shortgamename = "ace91_euro";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_315";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_211";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_300";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_314";
src/game/lair2.cpp://                   m_nvram_filename = m_shortgamename = "lair2_317";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_318";
src/game/lair2.cpp:                     m_shortgamename = "lair2";      // default version, so it gets the default name
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_316_euro";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_319_euro";
src/game/lair2.cpp:                     m_nvram_filename = m_shortgamename = "lair2_319_span";
src/game/laireuro.cpp:  m_shortgamename = "laireuro";
src/game/laireuro.cpp:  m_shortgamename = "aceeuro";
src/game/laireuro.cpp:          m_shortgamename = "lair_ita";
src/game/laireuro.cpp:          m_shortgamename = "lair_d2";
src/game/lgp.cpp:       m_shortgamename = "lgp";
src/game/mach3.cpp:     m_shortgamename = "mach3";
src/game/mach3.cpp:     m_shortgamename = "uvt";
src/game/mach3.cpp:     m_shortgamename = "cobram3";
src/game/starrider.cpp: m_shortgamename = "starrider";
src/game/superd.cpp:    m_shortgamename = "sdq";
src/game/superd.cpp:    m_shortgamename = "sdqshort";
src/game/superd.cpp:    m_shortgamename = "sdqshortalt";
src/game/thayers.cpp:   m_shortgamename = "tq";
src/game/thayers.cpp:           m_shortgamename = "tq_alt";
src/game/thayers.cpp:           m_shortgamename = "tq_swear";
src/game/timetrav.cpp:  m_shortgamename = "timetrav";

But I know for a fact that quite a few aren't in a working state.

http://www.dragons-lair-project.com/tech/

Feel free to create a list, no one is actively working on this any more ;)

shift

@dirtbagxon said in (REQUEST) Add Daphne Singe emulator?:

But I know for a fact that quite a few aren't in a working state.
http://www.dragons-lair-project.com/tech/
Feel free to create a list, no one is actively working on this any more ;)

Thanks! This is the list I was looking for.

shift

@DirtBagXon @pjft

I was finally able to run singe2 on my 4GB raspberry pi 4, but among the singe 2 games I have tried there is not one that is minimally playable, everything is slow. Has anyone tried singe2 maybe on an 8GB pi4 and it works better? Are there any special settings to minimize the resources required to run discreetly?

pjft

@shift Actually I have, and an 8GB will do nothing about it. It's because the videos included in most games are 1080p, and the rendering is not hardware accelerated. I believe you can play the ActionMax games/older games, as their native resolution is 480p there, but I can't say for sure.

Download Handbrake and convert all the videos to 480p. 576p might work as well, but still stutter a bit. Or try to find 480p versions of the videos that I believe are available for some of the games, but I converted mine myself and it worked just fine. Just be sure to keep the same frame rate in the converted video, as Singe depends on the framerate to know when to expect the inputs.

You might then need to resize the files in the Overlay on some of the games if they render too big for your liking, but that's a second step. I think I only resized them for Cliff Hanger, as I can live with the "level selection screen" not being quite aligned in the other games.

shift

@pjft said in (REQUEST) Add Daphne Singe emulator?:

Download Handbrake and convert all the videos to 480p. 576p might work as well, but still stutter a bit. Or try to find 480p versions of the videos that I believe are available for some of the games, but I converted mine myself and it worked just fine. Just be sure to keep the same frame rate in the converted video, as Singe depends on the framerate to know when to expect the inputs.

You gave me an interesting tip, I'll do as you said. Thanks

Darksavior

Has anyone gotten singe2.0 working with v1 timegal?

 ./Singe-v2.00-Pi-armv6 -v ~/singe2/timegal/timegal.txt ~/singe2/timegal/timegal.singe
Error compiling script:  /home/pi/singe2/timegal/timegal.singe: version mismatch in precompiled chunk

I tried the v2 of timegal and it runs too slow but that's besides the point. Whoever encoded this did a horrendous job with whatever filters they used.

pjft

@darksavior I agree, looks terrible. I keep singe1 around to play Timegal.

DirtBagXon

@darksavior said in (REQUEST) Add Daphne Singe emulator?:

/home/pi/singe2/timegal/timegal.singe: version mismatch in precompiled chunk

This is a 32/64bit error - I worked around this in the Singe v1 codebase.

It is because Time Gal (v1) uses compiled 32bit bytecode, not a plain LUA script.

Try:

file /home/pi/singe2/timegal/timegal.singe

Use the 'file' command on any other .singe files, except Ninja Hayate which also uses byecode, you will see the difference.

https://github.com/DirtBagXon/singe/tree/master/bytecode

Why these were 'special cases', I don't know....

DirtBagXon

@pjft said in (REQUEST) Add Daphne Singe emulator?:

@shift Actually I have, and an 8GB will do nothing about it. It's because the videos included in most games are 1080p, and the rendering is not hardware accelerated. I believe you can play the ActionMax games/older games, as their native resolution is 480p there, but I can't say for sure.

Download Handbrake and convert all the videos to 480p. 576p might work as well, but still stutter a bit. Or try to find 480p versions of the videos that I believe are available for some of the games, but I converted mine myself and it worked just fine. Just be sure to keep the same frame rate in the converted video, as Singe depends on the framerate to know when to expect the inputs.

You might then need to resize the files in the Overlay on some of the games if they render too big for your liking, but that's a second step. I think I only resized them for Cliff Hanger, as I can live with the "level selection screen" not being quite aligned in the other games.

My understanding of Singe v2 was to allow custom game designers to utilise sprites and mouse coordinates above the 356x240 range which was forced in v1.

Out of interest, with decreasing the size of the videos and overlays, are you actually seeing any benefit on these older games?

In the new games coming out over at http://www.emuline.org I see the requirement for v2.

Not trying to push v1 here, just interested in the gaming communities response to v2.....

pjft

@dirtbagxon Well, I don't have a preference between v1 and v2 - it's just what games I can play there. I use v1 for TimeGal and I'm not going to change. Same for Ninja Hayate.

V2 has a lot of other fan-made games (Samurai Jack, Daitarn, etc) which I can't find for v1, so that's why I'm using it.

DirtBagXon

@pjft said in (REQUEST) Add Daphne Singe emulator?:

V2 has a lot of other fan-made games

And I believe the new fan-made games use the larger resolutions in sprite and mouse handling, so totally get that.

The Time Gal overlays on v2 look totally different to v1, nice but different.

I am a traditionalist here, and want retro games to look, well 'retro', like the arcades.

Interesting...

pjft

@dirtbagxon Agree about Time ~~Crisis~~ Gal (sorry, had my mind elsewhere) and the older games in general.

There are, however, people still developing fan-made games that make for interesting experiences in this space. I personally am dabbling in re-creating Road Blaster based on higher quality footage. I'll see if that ever gets done :)

shift

@dirtbagxon said in (REQUEST) Add Daphne Singe emulator?:

Out of interest, with decreasing the size of the videos and overlays, are you actually seeing any benefit on these older games?

I've only tried v2 with new games, and, decreasing the resolution (thanks to @pjft for the tip), they are now playable (previously it was impossible on an Rpi4).
As for the old games, on the other hand, I use v1 because I like it. I haven't tried v2 on old games, I only installed it to be able to launch new ones.

Darksavior

@dirtbagxon I was already using your timegal.singe and using the file command didn't change anything.

DirtBagXon

@darksavior said in (REQUEST) Add Daphne Singe emulator?:

@dirtbagxon I was already using your timegal.singe and using the file command didn't change anything.

Ok, so two different things to address here:

You don't need to use my timegal.singe (or hayate.singe for that matter) any longer with the latest commit in my repo. You can revert and use the original .singe file. There is no difference in gameplay in my version, it just added a work-a-round for an arithmetic issue. So you can continue to use it, or swap it out with the original - up to you, it won't change the game.

The arithmetic issue has now been fixed in the libsinge.so library rather than the .singe game file in the latest commit of the codebase.

The 'file' command doesn't change anything, it's just an informational utility. Most .singe files will show you that the content is:

file maddog.singe 
maddog.singe: ASCII text, with CRLF line terminators

i.e. ASCII text - open it in your favourite text editor - you can change game variables and functions etc, even rewrite the game.

Then try:

file timegal.singe
timegal.singe: Lua bytecode, version 5.1

This shows that this is not text, but in fact a compiled (32bit) binary bytecode. As stated above, I am not sure why, but at a guess in an attempt to obfuscate code.

You won't be able to edit this as above, but you can try.... ;)

I was trying to convey that the two v1 games, Time Gal and Ninja Hayate, were released in a different format to all other v1 games. And thus had to have fixes specific to them in my repos for both the standalone Singe and the Daphne plugin. From the error you were seeing, it appears that Singe v2 didn't address these.

Most of the changes I made were due to a move from 32bit linux to 64bit, which is now the norm. But also exposed issues (C int/long) and other library updates that have been made in the years since v1 was released. As far as the bytecode issues were concerned, this was my first clue to addressing:

http://lua-users.org/lists/lua-l/2016-02/msg00176.html

Windows doesn't really care so much about running 32bit binaries on the 64bit variants of Windows. It has a 32bit subsystem already built in. So even old versions of the windows Singe will still run on 64bit Windows 10 and these old games just work there.

I hope that clarifies some things...