xxOToTOxx

Hypseus is doing a little more than a "media player", it's emulating CPU cores, overlays, INPUT control system, field blending, scanlines and bezel drawing etc and rendering (whatever resolution) video on a "single-core", in much the same way as any emulator operates on a single core for timing purposes, including MAME. Watch the CPU load in task manager when you run it. What you are trying to do is run 4k hi-bitrate video and a full emulation on a single core, so the answer to your question is: Whatever your "core" can support. It doesn't matter if you have 16 or 64 cores, the single core is the only thing that matters. Bear in mind the higher requirement you put on this, the fewer users will be able to enjoy it, including many, many SBC ARM systems. The VLDP was designed to run 720x480 non-square pixel "laserdisc" video, it can do that and very much more, but there is a theoretical "camel/straw" here dependent on current hardware. Your original upscale of Road Blaster works great on decent desktop systems, certainly not Raspberry Pi's, but you are pushing it further up the CPU core requirements if you increase resolution and bitrate. So you need to experiment and see what will be possible on hi-end, or average systems, that's down to you really and for whom you are aiming this video at, just yourself and hi-end systems, or general users. Edit: I did a little calc some time ago, on the amount of pixels you expect to be processed and rendered every time you jump a resolution. I'll post it here for context, remember this is just video not including any other emulated hardware and input/effects. Using an FPS of 30, for this example, as it's near NTSC video standards. 360×240 = 86,400 pixels - 30 times per second 640x480 = 307,200 pixels - 30 times per second 1024×768 = 786,432 pixels - 30 times per second 1440x1080 = 1,555,200 pixels - 30 times per second 1920×1080 = 2,073,600 pixels - 30 times per second 2560×1440 = 3,686,400 pixels - 30 times per second 3840x2160 = 8,294,400 pixels - 30 times per second But also let's not hijack HVG's thread.

Making some comparison shots of the previous versions: Original Singe 1: (PlayStation source): AI upscale of Singe 1 video: Raw Taito Laserdisc Collection Bluray (Over saturated 'red' and de-focused): And finally @HVG version: Just to re-iterate grab the latest LUA: https://github.com/DirtBagXon/hypseus_singe_data/raw/refs/heads/master/00-zip-roms/00-Elder-Modernized-zip-rom/hayate.zip

Really nice I have made some minor tweaks on the LUA side, so you should grab this for use with this video. https://github.com/DirtBagXon/hypseus_singe_data/raw/refs/heads/master/00-zip-roms/00-Elder-Modernized-zip-rom/hayate.zip In logs, it will now register as: Initializing Ninja Hayate Singe v1.22 Thanks again @HVG

The VLDP is pretty good at matching the FPS discrepancy, so this makes sense, but it was worth pointing out. Great work 👍 The VLDP will log the FPS discrepancy, quite a lot, but as with the 60 FPS Dragon's Lair sources, it shouldn't be an issue if keyframes are corrected. [ldp_vldp::nonblocking_search@455] NOTE: converting FPKS from 25000 to 29970. This may be less accurate. I didn't notice these issues while the death scenes were broken in the LUA, but now they are fixed, it will be awesome to finally have a high quality fixed working game. Thanks so much for undertaking this.

@HVG - This is a really nice source now, thank you so much. Having the ability to see death scenes easier now with the LUA update, I would like to point out that there seem to be frame overshoots on many of the deaths scenes. Probably only a frame or two, I did a quick video of the early one that I spotted first: https://youtu.be/J7Gxr8oGcqs?si=KnEkQKWNUPunHEU9&t=15 - @15s just after the respawn black screen. Playing through (and dying with unlimited continues) I have spotted several of these. This probably isn't helped by the fact you had to edit in death scenes, but also your video is @29.97 FPS, whereas the original is @25 FPS so this may be leading to the slight inaccuracies. The game would have been coded for a 25 FPS source. Edit: Just for comparison, I did load the old 25FPS video sources into the new LUA and I don't notice those frame overshoots, at least on that scene. Just a FYI.

There was a bug in the original hayate bytecode, from Singe 1 days, it triggered Death Scene looping. Being obfuscated bytecode this was very hard to track down. I put a "fix" in for the issue a few years ago, but it was never perfect and just disabled proper Death Scenes if the bug was triggered. As we have a shiny new video source from @HVG, I took another look at the bug in the bytecode and now have a correct fix. The "Death Loop" bug is now fixed, language selection and frame corrections have been added, grab the new LUA files from GitHub. Corrected version v1.22 on the same link. Note: Version v1.22 has some frame corrections that affect both original and HVG new video versions. This in now definitive version. https://github.com/DirtBagXon/hypseus_singe_data/raw/refs/heads/master/00-zip-roms/00-Elder-Modernized-zip-rom/hayate.zip In logs, it will now register as: Initializing Ninja Hayate Singe v1.22

Well spotted! This game has been obfuscated to hell and I never noticed it was playing only as mono from a single channel. The channel tracks are very similar and most noticeably different in the attract voiceover near the beginning. No matter, it's worth having the ability to switch. I'll have to dig through the game bytecode and will add a new Service Menu option to switch to the other channel. I'll stick an updated Zip ROM up on GitHub, when it's done. Edit: No audio file changes are needed. The updated Zip ROM is here: https://github.com/DirtBagXon/hypseus_singe_data/raw/refs/heads/master/00-zip-roms/00-Elder-Modernized-zip-rom/hayate.zip

This one is the latest version, in Zip ROM format: https://github.com/DirtBagXon/hypseus_singe_data/raw/refs/heads/master/00-zip-roms/00-Elder-Modernized-zip-rom/hayate.zip Yeah. Taito did a slapdash rush job on this transfer for sure. The RGB is totally unbalanced, you could look to de-saturate RED when you chop it up. The detail and clarity of content is certainly better than the existing video, it's just set in a "blazing sunset"......

The VLDP doesn't care, it will display what is provided. In the last release 2.11.6, there is a primitive de-interlace algorithm using the `-blend` argument. This can be used to de-interlace on-the-fly on progressive displays. But it had limited testing, your mileage may vary.

See my response here:

I'm not convinced this is worth doing until we have an RF (Domesday) capture of the ALG games. Because when we do, I'm sure that will be the preferred source and the whole game would benefit from a total rewrite at that point. Doubling the framerate, on the current games, is a massive amount of work in the LUA. You are effectively incrementally increasing **every** frame reference and need to make that adjustment for every scene and frame reference in the game LUA. That's the easy part. Then you have hitboxes, all tied to a specific frame number and cross referenced to scene frame references. You are incrementally interjecting frames, effectively doubling the number of hitbox definitions that will have to made, all with new (or at least programatically incremented) frame references. There are only a couple of guys, not on this forum, that are looking at hitbox re-definitions, so unless someone wishes to pick up and begin understanding hitbox structures, this is a hard ask for time when other projects are being undertaken. Great idea, but the work involved is substantial to say the least. Just replacing video segments with the same FPS sources is a quick fix and in my opinion probably the best route until DomesDay RF captures surface. Footnote: The reason the AI sources from Karis' version were used in the conversions, it it was the path of least resistance in the existing LUA, without having to rewrite all the hitboxes like you are suggesting. I 100% agree these are far from optimal video sources and the guys have been using Domesday for newer games (gallagher, fastdraw, tierras) where available. But these games are written from scratch and have taken considerable time.

Yes 😆 I've written a detailed explanation of this in several places, including Discord. So I not gonna repeat it here (again).

Hi guys, great project. Charlie Chan is pretty much spot on, I looked at the MKV and there are frames that need to be dropped from the beginning from the LDF capture, by my math 157 seems correct. Then you just need to encode the m2v to MPEG2 as described in the GitHub pages here: https://github.com/DirtBagXon/hypseus_singe_data?tab=readme-ov-file#conversion The existing .ogg is probably fine as you are just changing the video. Then just drop the m2v in place of the existing m2v file and start up Hypseus let it re-index. I'll be interested in how this all looks 👍

Mad Dog II: The Lost Gold - 2 Player This has been asked for a few times here, well it's finally fixed up and ready for 2 player goodness.

Hey @Nit3H8wk - long time no hear. That Topaz Road Blaster video of yours is still pretty damn good. But this is also an interesting route. Please let us know if, and or how, turns out. Should you try it.