xxOToTOxx

Thanks Max. Please don't let this be an invitation to make a swill of AI generated garbage. Let's have some proper audio editing from original audio tracks - PLEASE!! Audacity should probably be your tool of choice: https://www.audacityteam.org/download/

With Max's permission, I'll put these here. Multi-Language dragons_lair_1080.zip dragons_lair_II_1080.zip space_ace_1080.zip I added Multi Language support to all 3 Reconstructed games. You can add the extra Language suffixed .ogg direct to the "Video" folder, i.e. lair2-it.ogg The preset languages are described in the below YouTube, but of course you can change the LangOpt variable to do what you want in the main .singe file. I had to move the Treasure Position option to a new place, to make the changes consistent, so I moved it to the "Death Rewind" position. Note: This option in now not adjustable in DL and SA, as Max already stated in the Space Ace thread - it's not available in these games. Now you can create and drop-in whatever languages you want, just create the audio files. Please share them back.

If you, or someone else, creates an .ogg file to match the current game audio (in a language of your choice). It is trivial to add language selection to the game menu's, so multiple languages can easily be supported, other Hypseus games already do this. This is just an audio editing exercise, it does not require you to do anything other than create a matching audio file - Use Audacity. Preferably a native of the language would be the best person to do this. This applies to any language for which Space Ace audio files exist. I will happily add this option, if someone produces a valid audio file. Over to you guys. Update: As promised on the the additional, in-game, Options: (You still need to create audio files)

Taking a quick look, this looks really nice. But please be aware that if you are re-framing scenes, you will be affecting the position of hitboxes. So you should check hitboxes very carefully on those scenes, especially it the target is small and in the distance.

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

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.