xxOToTOxx

Sorry, I assumed you would do this on a Linux system not Windows as you used a Pi mv carbon.ogg carbon_delayed.ogg This just 'renames' (mv is move - not sure what PowerShell thinks it is) the file, so use Windows explorer to rename the file rather than the command line stuff. This seems to be working ok though: ffmpeg -i carbon_delayed.ogg -ss 00:00:00.330 -c copy carbon.ogg "carbon_delayed.ogg: Unknown file format" This just means ffmpeg can't find the file or it has been corrupted, because the rename failed. If all else fails, just pull the ogg from the original MP4 again, with the delay: ffmpeg -i ACR.mp4 -ss 00:00:00.330 -vn -c:a libvorbis -ar 44100 -map a -b:a 160k carbon.ogg

To answer this more generically, you probably need to add the following arguments to the game `.commands` file. Assuming this is RetroPie or similar. https://retropie.org.uk/docs/Daphne/#command-parametres Add `-manymouse -oversize_overlay` to the gun games .commands files. i.e. /home/pi/RetroPie/roms/daphne/maddog.daphne/maddog.commands Create the file if it doesn't exist.

This could be one of two things: 1) The pi isn't playing the video at full speed ? You will need to lower the bitrate, or reduce the resolution of the video so the Pi can handle it (Both ffmpeg arguments). 2) The audio is out of sync due to the Singe audio bug work-a-round. You can add a delay when you encode the audio out of the MP4, see details here: https://github.com/DirtBagXon/hypseus_singe_data#conversion Usually 00:00:00.330 (i.e. 9 frames [33ms] is enough), but you can adjust that value. So for carbon an already encoded ogg , you can quickly correct with: mv carbon.ogg carbon_delayed.ogg ffmpeg -i carbon_delayed.ogg -ss 00:00:00.330 -c copy carbon.ogg Or you can do the encode direct from the MP4 and do the same thing, see the above URL documentation. You need to provide more details on which games (HD versions or SD) and the arguments you are passing to them here.

If this was the only reason for these games to exist, I fear they would die out far too quickly...

@dex77 - I am a massive fan of your SD work on lair, ace etc, these SD are fantastic when displayed at native resolution in a 640x480 "window" on a modern screen. Heads above the original video by RDG. However, when I use yours, or any, SD content in -fullscreen, on a modern 2/4k monitor it just doesn't match what some of these upscales are trying to achieve. Even with all the modern bilinear filtering etc applied. There is a drive for HD on this content. This is not gonna suite, or please, everyone. As I say about Singe 2 and Hypseus comparisons, there are different audiences for the games in these applications. And if we can cater for as many as we can, then all the better. @HVG - I have to state that on a 2k -fullscreen display these "upscales" look far better than anything we have already and I thank you for that. I also thank everyone for their work in providing this diversity. Great job to all the people who have the knowledge, and spend their own time, in providing these classics in an improved/refactored version. I think we just have different groups of people looking for different things.

1000% agree - As I said I am amazed it works at all. But it is pretty cool how close we have got thus far.....

Here is an interesting discussion about the SDL1 to SDL2 shift on a 15k CRT in the SCUMM forum: https://forums.scummvm.org/viewtopic.php?t=16330

I'm getting old, but on that video does the LCD version not sound to be playing too fast ? Or is it just the comparison...... The VSYNC stuff is explained quite well here: https://www.digitaltrends.com/computing/what-is-vsync/ So VSYNC is what I disabled on the CRT build, i.e. it relies on the (reported) refresh rate of the display. I'm pretty sure your CRT wont have VSYNC technology. I have looked through the SDL setup functions, and cannot see anything else I can add, or take out, to help this. SDL is supposed to make all the choices itself now. Again re-enforcing the SDL maturity hope. The CRT version does look playable enough there though Really nice to see them in play - BTW were the munchies nice ?

So, from your comments above, I assume this is what you are using: https://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=295 Which is creating a hardware abstraction layer between a digital HDMI and producing an analogue signal to the CRT ? So SDL will be reliant on what is passed back from this abstraction layer as I understand it. I think this is down to SDL library support, fingers crossed it will be addressed in future releases. I guess there are many ways to do the digital to analogue conversions, so some may work better with SDL than others. Interesting stuff. To be honest, I am pleasantly surprised that a 4k video signal is even remotely working on an analogue CRT

For anyone who has attempted, or is looking to attempt, running Hypseus with a CRT there was some discussion here: http://www.emuline.org/topic/2363-emu-hypseus-singe-sdl2-64bit-4k-daphne-emulator-windows-mac-linux/?do=findComment&comment=117946 I have put a CRT Windows build (removing VSYNC) on the repo: https://github.com/DirtBagXon/hypseus-singe/releases/tag/v2.6.20 Would be interested in others experience with CRT's and hypseus. Here is an interesting discussion about the SDL1 to SDL2 shift on a 15k CRT in the SCUMMVM forum: https://forums.scummvm.org/viewtopic.php?t=16330

Many thanks for all the help here, it's pretty hard when you don't have the hardware you need to test on I will put that version as an experimental CRT edition on the main repo downloads. As I said future SDL2 may improve this (PRESENTVSYNC for CRT improvements for instance), but unless someone wants to donate a CRT not sure I can go much further.....

OK, cool And final question, so 4K ESH (talking Daphne not Singe now) is now playable at an acceptable frame rate, with audio in sync, on the CRT ?

Can you just confirm if there was any difference between the two MEGA link versions I posted, I still suspect PRESENTVSYNC was the main problem, but did the second version improve anything ?

But that's comparing Apples and Oranges. The Singe 2 conversion it not a ROM game, it's a LUA simulation and video may have been encoded at a different FPS (MP4 vs M2V).

So, just a little clear up here, when you state "SInge 1.0" - you are talking about original Daphne here (not Singe), running the Daphne ROM game, not a Singe conversion ?

Ok, out of options now. I am allowing the video to be dictated by the refresh rate of the CRT, not sure what else I can do. What discrepancy are we talking about? Is there any difference between the last two ?

Ok, I am ripping out all the accelerated enhancements now, another version here to try.... Grab CRT release from: https://github.com/DirtBagXon/hypseus-singe/releases/tag/v2.6.20

Ok, give this a try: Grab CRT release from: https://github.com/DirtBagXon/hypseus-singe/releases/tag/v2.6.20

Ok, it's building, if it runs better with the software renderer that might be a good indication it's the PRESENTVSYNC option that's doing it... Fingers crossed.....

I will compile a custom Windows binary that drops SDL `SDL_RENDERER_PRESENTVSYNC` from the build - again unknown territory - but something to try. Will paste MEGA link here when it's ready.

I have no faith in this working, but just try using `-nohwaccel` on the CRT......

Ok, so SDL2 and CRT's, at this point, don't work well - interesting...... Would be interesting to know if this is Windows specific (I am guessing it isn't), but if anyone running Linux with a CRT has any updates.....

Ok, without access to a CRT I don't really know how to test this further... Windows SDL2 is still pretty new and has known issues, so this may improve as SDL2 matures. Google shows nothing to help us here. But just to be clear, if you connect the same rig to an LCD monitor it all works fine with standard and 4k resolution video ?

There is also a new version of SDL2 for Windows (2.0.18): https://www.libsdl.org/download-2.0.php You will need the "Runtime Binaries" zip for your Windows 32/64 version and again just overwrite the existing `SDL2.dll` I haven't tested this version, but it may have improvements....... 2.0.16 had some major improvements over 2.0.14 in the Renderers.

What version of hypseus are you running? Run in the command prompt with `hypseus -v` In version `2.6.20` there are a couple of new options to force the renderer to `-opengl` or `-vulkan` also new SDL libraries. Just overwrite the .exe and .dll file from the zip at https://github.com/DirtBagXon/hypseus-singe/releases/tag/v2.6.20 `-ignore_aspect_ratio` is deprecated. But you can try the new argument: `-force_aspect_ratio` which will force 4:3 Also you can specify the resolution with `-x` and -y` as always.