xxOToTOxx

For those of you who didn't catch the other thread, there is now a dedicated Windows launcher available to help organize those Hypseus games and bat files:

Released:

2.11.7 of Hypseus Singe has been released in anticipation of the new Borf frontend Hypseus launcher for Windows. Keep an eye on https://www.youtube.com/@widge for announcement details. Hypseus Discord: https://discord.hypseus.net

For Absolute mouse co-ords (required by lightguns) Hypseus reads the HRAWINPUT, that's probably unaffected by these OS level changes. I don't know the Windows INPUT systems that well, worth a shot, but no idea if there is a way to fool the reported hardware signal on GetRawInputData calls.

@Jackie Brown One of the guys suggested this might be an option for you, without fiddling with game code. It might also provide a solution for your Model 2 Emulator issue 🤷‍♂️. https://superuser.com/questions/205861/keyboard-shortcut-to-swap-mouse-buttons In your case you would have to alter the code to swap middle and right button, rather than the left and right, but cool solution you could add to the start and end of a bat file.

Ok, I see. That's some pretty specific wants for specific hardware use cases. The games are fan written to work in most user (their) instances and amended by people who have other specific use cases. So you're unlikely to get the behaviors you want, unless you start changing the game code to do what you need I'm afraid. Don't think there is a generic switch that can be added easily for your case in current games. Probably just a matter of changing the hard-coded mouse button attributions, at least you have an opportunity to do alterations in these games, unlike the Model2 ROMS.

Guns don't have middle buttons ? 😂 - You can assign BUTTON1 (reload), BUTTON3 (shoot) on any supported real lightgun hardware in the main config file. Or you can use any of the reload options in the Service Menu: AUTO, EMPTY, BORDERS, LIGHTGUN - [They all should behave with a mouse]. If you insist on using a "mouse" for a "lightgun" game, mouse BUTTON numbers are fixed (in right to left order). So you would have to change game code to alter behavior.

The files from the MEGA link on the first page of this thread don't contain a starblazers.singe, they seem to have a couple of setupgame.singe and fai.txt framefiles. That's fine, but all the provided example bat files won't work, you need to alter your arguments with the correct files and paths. You can fight on with this version, or perhaps it might be easier to use the sanitized one from Internet Archive, which should work with the bat examples: https://archive.org/details/hypseus_singe_starblazers

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