Aller au contenu

xxOToTOxx

GamerLine
  • Compteur de contenus

    516
  • Inscription

  • Dernière visite

  • Jours gagnés

    34

xxOToTOxx a gagné pour la dernière fois le 6 octobre

xxOToTOxx a eu le contenu le plus aimé !

5 abonnés

Profile Information

  • Hardware
    Linux PC, hypseus-singe, SDL2, daphne, singe

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

xxOToTOxx's Achievements

Community Regular

Community Regular (8/14)

  • Posting Machine Rare
  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

504

Réputation sur la communauté

  1. 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.
  2. @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.
  3. 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 this shiny new video from @HVG now, I took another look at the bug in the bytecode and have a better solution proper fix. Here is a v1.21 of the "Death Loop" fix, grab the new files from the same place on GitHub. Edit: I finally fixed the root cause. Grab v1.21 on the same link. Note: This there is no different end result to the previous 1.20 fix, but 1.21 is a proper fix which the earlier one led me to. 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.21
  4. 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
  5. 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"......
  6. 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.
  7. 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.
  8. Yes 😆 I've written a detailed explanation of this in several places, including Discord. So I not gonna repeat it here (again).
  9. 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 👍
  10. 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.
  11. 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.
  12. Might as well post this here too, as it's an appropriate thread:
  13. These rips are just the early standard 1983 laserdisc footage. For the prototype footage you need the 2002 Limited Edition Dragon's Lair Laserdisc. You need to hunt that disc down. It's out there on Internet Archive but not upscaled. See here to watch the prototype running:
  14. If you are a fan of the Hypseus game Space Rocks by Widge, some great news. You can now listen to the soundtrack of original music on Spotify, Amazon or Apple Music: https://music.apple.com/us/album/space-rocks-original-game-soundtrack/1831288219 https://music.amazon.co.uk/albums/B0FL7T9LL1?ref=dm_sh_sr8ya1lztpAjpv1GTg41iik3i
×
×
  • Créer...