xxOToTOxx

Thanks, so much for making some deobfuscation of this, I made one minor adjustment (for me), moved the (flashing) button sprite under the ACTION sprite, rather than over it. Yeah, that's LUA, but hats off for your patience here- This old, old game really has had a REDUX this year now. Happy New Year. Edit: These changes can go in the Alt Sprite pack, but we should maintain RDG's (fixed) version as the base.

My understanding is, RDG is no longer of this earth. If you understand what I mean. So highly unlikely.

You might have a small amount of space to shift sprites around, but I'm not certain it would be enough to achieve the effect you are after. Not impossible, but painful certainly.

You have 2 things against you here: 1. It's not encrypted, it's obfuscated bytecode. This is how it was released in 2010 by RDG (he's no longer around to ask, but presumably to stop people messing with his code). I have never seen a standard LUA version of this game. Altering it requires deep and rather painful analysis of the obfuscation. I've only made fairly minor changes to it. 2. This game, having been written for original Singe 1, only has a small overlay resolution (unlike the full 1080/720 overlays on Max's Dragon's Lair). This means there really isn't the space to create that style of prompt animation, even IF you could find the correct place for it in the bytecode.

🎄

Read your PM's

I've had a couple of requests on changing the direction sprites, so here is my alt and move away from RDG's original. I took inspiration from GodElite, but tidied the spacing and added drop-shadow correctly + ducon2016 added animation. You can grab it from here: https://archive.org/download/singev1-hayate/hayate_altsprite_rompack.zip/hayate.zip

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.24 on the same link. Note: Version v1.24 includes the frame corrections and a fixed memory leak from Singe 1 code. 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.24

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"......