xxOToTOxx

Interesting... I get `36910` I am missing something here.... So fix in repo probably won't do anything..... I need to check the video I got you to download...... This was one of the first I did, and I haven't touched since. EDIT: OK, apologies it looks like I used some other source video.... However I can't remember which one it was. I will see if I can figure but most probably a Karis revision that may no longer be available..... If you still have the Karis one from before, copy the .mp4 to the Pi and run the mediainfo --Inform='Video;%FrameCount%' command on it, to see if it matches 36910

Just tested and played with deaths first few levels on 64 and 32bit, I am not seeing this issue. Can you explain where it occurs exactly.... Also on the pi: sudo apt-get install mediainfo Then run this on the converted .m2v file: mediainfo --Inform='Video;%FrameCount%' dl2e.m2v EDIT: I have pushed a new dl2e/main.singe into the repo too, I can't replicate it, but have put same fix as previous - can you try it.

Really? Did you change any settings ? Can you post your game.cfg Also are you running on aarch64 full 64bit or 32bit userland ? Run file /opt/retropie/emulators/daphne/daphne.bin Assuming this is RetroPie.....

How about torrent from here: https://1337x.to/torrent/4876774/Daphne-SINGE-Dragon-s-Lair-2-Enhanced-Laserdisc/

Yes - from archive.org as always Although I think this may have been removed, so you may have to find the .mp4 elsewhere. Or try this torrent: https://1337x.to/torrent/4876774/Daphne-SINGE-Dragon-s-Lair-2-Enhanced-Laserdisc/ The frames in the video are: mediainfo --Inform='Video;%FrameCount%' dl2e.m2v 36910

Ninja Hayate is there too if you want it: https://archive.org/details/singev1-hayate

You could also get original Time Gal and Ninja Hayate from here: https://mega.nz/#!hmhRQC7I!0EXghHIMKzPT1aVpyYCuZX0QHChVzkgnFrB4WSatDdo From:

Well original 'timegal' will use the original video and all other files supplied with Singe 1 Time Gal: https://archive.org/details/singev1-time-gal 'timegalv2' will need you to convert the video from Singe2 version on archive.org and combine with files on the singe2 repo above. They are different games with different video and overlays. The 'timegal' on the repo above is a copy of 'timegalv2' - that is really for people who only want the new version v2 called 'timegal' - confusing I know but that was my mindset at the time...... Regarding 'freedomfighter' - I never really got that working correctly I don't think. So if you have success in level succession let me know

No longer needed. Hopefully looping death scene fix in: https://github.com/DirtBagXon/hypseus_singe_data The only files you need to change are: modified: dragon/hscore.singe modified: dragon/main.singe modified: dragon/map.singe modified: freedomfighter/hscore.singe modified: freedomfighter/main_mouse.singe modified: freedomfighter/map.singe modified: jack/hscore.singe modified: jack/main.singe modified: starblazers/hscore.singe modified: starblazers/main.singe modified: starblazers/map.singe Let me know.

I know the change in the codebase that is causing this, it's related to a 32bit <=> 64bit interoperability. Unfortunately, without it most of the main Singe games have timing issues on 64bit so I can't revert. The games that are having issues are all later fanmade games using the same underlying old LUA framework it appears, so I believe this needs to be fixed in the game framework. I haven't seen the issue in other titles. I am seeing it in Singe 1 jack, dragon, freedomfighter and starblazers. Seems to have been fixed in later Singe 2 ports. I haven't had as much time recently to look on these, but hopefully fixes will be pushed to: https://github.com/DirtBagXon/hypseus_singetwo_data

First you need to understand that Singe is a different emulation of game data to Daphne. The first Singe version was added as a 'plugin' to Daphne, and looking at your image of the files, you have 'singe.dll' which is the plugin to Daphne so this version should/will work. Now, in order to use the original Daphne version of Singe you have to give it the correct arguments, which will always begin with: daphne.exe singe vldp -framefile ... -script ... If you have 'freedomfighter' folder in the daphne folder, then the arguments include the main .singe file of the game and framefile, and become: daphne.exe singe vldp -opengl -x 1600 -y 1200 -fullscreen_window -noserversend -volume_vldp 64 -volume_nonvldp 32 -sound_buffer 2048 -framefile freedomfighter/ff.txt -script singe/freedomfighter/setupgame_mouse.singe There are lots of arguments here, but famawizard has prepared this for you, and put the arguments into a windows .bat file called 'freedomfighter.bat'. So you just run that. If you want to understand what each argument does then you are going to have to do some Googling, most are Daphne specific, some are for the Singe plugin. Here is a good place to start for Daphne parts: http://www.daphne-emu.com/mediawiki/index.php/CmdLine Daphne and Singe are notoriously difficult to understand until you use them and experiment. Which is why most of the developers simply supply a .bat file. However, for real enjoyment you should take some time to understand these arguments as there are many, many incredible games on this site you can play, and configure, once you master. Footnote: Daphne and Singe code has been around for a decade or more and uses older software libraries that don't work great on modern operating systems. Hence the release of newer versions of Singe (Singe 2: Just improved Singe no Daphne) and Daphne Singe (Hypseus Singe: With Daphne support) which uses up-to-date graphics libraries and improved features. However most still use the same command line driven interfaces, so the above statement still stands. Good luck.

Having worked on the Daphne source code recently, I don't think you have an old version of Daphne, it's ancient. Freedom Fighter was tested in Daphne with game code 'ffr' but never worked. @famawizard's version is Singe, not Daphne, so you need to use a completely different Daphne version with Singe support. As advised there is a version within the archive, or use one of the modern Singe engines.

Now has a software rendered original scoreboard for lair/ace: -software_scoreboard This will work in -fullscreen_window but not -fullscreen mode.

Then you carefully need to look at the command line arguments it is running, as Daphne isn't recognising one of them: Unknown command line parameter or parameter value: Make sure you are "quoting" any argument with spaces in it. I would be expecting this argument to be "F:\Emulation\LaunchBox\Games\Arcade\Daphne 4k\Daphne\singe\johnnyrock\johnnyrock.singe" <- Note: .singe

You are running a local (i.e. on your hard drive) version of Daphne without Singe support. Maybe it's time to try Hypseus Singe

- For those familiar with Daphne, this should be a direct drop-in replacement. Contains many additional features and SDL2 enhancements: Windows, MacOS X and Linux (Raspberry Pi) 64bit version of Daphne for Windows 4k M2V support Many additional features in Daphne and Singe Windows Client: https://github.com/DirtBagXon/hypseus-singe/tree/master/win32 Main Site: https://github.com/DirtBagXon/hypseus-singe/ Emuline Thread:

This change may have unintended consequences elsewhere, so if you could do a complete test on Daphne games also, that would be useful. I haven't seen any issues, but the more testing the better. Thanks. Update: There was some question on the Windows port handling m2v files over 2Gb. I have tested using a 2.5Gb Cobra Command 4K conversion Daphne m2v video file and a 3Gb Singe m2v file. The Windows port does not have issues with files over 2Gb in Windows 10 (64bit). I no longer have a 32bit version of Windows to test.

@312BhP - I have pushed a fix that should allow the larger files on 32bit linux systems. Grab the latest push on the RetroPie branch. This only affected 32bit linux platforms. The Windows port is opening > 2Gb files without issue thus far tested.

Correct, I have not run through splitting files, but it is all about the frames. Karis & Poiu are probably our experts here. mediainfo --Inform='Video;%FrameCount%' fireandice_01.m2v mediainfo --Inform="Video;%Duration%" fireandice_02.m2v ffmpeg -i fireandice.m2v -acodec copy -vcodec copy -vframes 65500 fireandice_01.m2v I have played with above commands to limit number of frames in total. But I couldn't find a clean way in ffmpeg to start from a particular frame for the second _02 file.... you have to deal in start times and key frames, not the same..... There is a document to be written here

I am afraid so, I am not certain that 1080p content at that bitrate will run smoothly without full KMS, so I would more aim for 720p, maybe.....

Ok, I have just figured this. It is a limit of the 32bit version. The file will need to be split on 32bit systems, only 64bit system builds can handle files over 2Gb. Confirmed on a 32bit Debian install. Fix applied to 32bit linux in repository. This will be less of an issue when the aarch64 builds are standard.

Check the filesystem types on the pi too, with: sudo mount Just in case.

Then, the only logical conclusion is it is a corrupt file....

Latest version won't make a difference on this I don't believe, looking at the code, this still implies it cannot read the file. Are you sure there are no weird meta characters or spaces at the beginning or end of the 2.4Gb filename when you transfer it ? Windows can add these and they are not obvious sometimes. It is failing on: mpo_open(filename, MPO_OPEN_READONLY); Pretty basic stuff, and decade old code from original Daphne. Something MUST be weird in that filename... Rename it on the pi with quotes: mv "/home/pi/RetroPie/roms/daphne/fireandice.daphne/./fireandice.m2v" "/home/pi/RetroPie/roms/daphne/fireandice.daphne/fireandice.m2v" Either that, or the file is corrupt, reading deeper into the old code, it does attempt to make a SEEK which, if fails, will give the same result. It may also be a corrupt file.

I will help if I can, of course, but show the FULL contents of /dev/shm/runcommand.log when things go wrong. ??