7 comments

  • LaurensBER 30 minutes ago
    Despite all "hate" against AI in the (retro)-gaming scene I'm genuinely excited to see these kind of projects (not sure if this one involved any kind of AI) and emulation.

    From a technical perspective emulation is absolutely amazing, it requires deep technical knowledge, an excellent understanding of the source system and the optimisations are on another level.

  • mikae1 33 minutes ago
    I'm so emotionally torn about all the awesome decompilation work done.

    Too bad all the cool decompilation is happening for games on early 3D centric consoles. I say this a Quake fanatic. Low res textures combined with that blurry bilinear style filtering is a look that's not easy to love. It's just a generational thing I guess.

    • toast0 26 minutes ago
      I'm pretty curmudgeony on 3D games. The gamecube and friends were the 2nd generation of 3D first game systems and most games that sold well were not simply am existing genre game but with 3D objects that will poke your eyes out.

      Doesn't mean I liked them, or that they wouldn't have been better as a 2D game. But IMHO the graphics stopped distracting from fun games... OTOH, I played plenty of games on the Atari 2600 were the player character wasn't much more than a chonky pixel :p

    • saturn8601 24 minutes ago
      Those games like for N64 never really emulated great. I can see the motivation for those games to finally get nice gameplay on other platforms.
  • wk_end 44 minutes ago
    From a preservation perspective, this is one of the least useful decomps ever, given how committed Capcom is to making sure RE4 is ported absolutely everywhere (kidding!)

    Made using the leaked debug build and its symbols, which shows how meaningful the work the game preservation community that acquires and distributes these things is.

    OTOH this is pretty off-putting:

    > Where the compiler needed a particular source shape to reproduce a register choice or a schedule and no natural spelling was found, the construct is marked with a // COMPILER-DIFF: comment (644 of them: dead tests, empty asm("") launders and anchors, register T x asm("rN") pins, padding statements).

    To me the value of a decomp isn't reproducing the original bytes per se (we already have the original bytes after all) - it's about reconstructing the understanding of the original game as represented by human-readable source code; getting byte-for-byte is just an indication that you've gotten it right. Needing to add a bunch of slop to force the compiler to match the original output is actually just an indication that you've gotten it wrong - and it's a demonstration of the danger of Goodhart's law, especially as it applies to AI.

    • Pannoniae 37 minutes ago
      Correct, this is just hacks for stuff you didn't manage to match exactly. Either that or your build environment isn't the same. Sadly, there are things which aren't really possible to reproduce in a byte-identical manner, things like exact file layout or variable declaration order, compilation order and that kinda stuff. And they might cause small but equivalent changes like different inlining/optimisation decisions, so it's really tricky to get it byte-exact.
    • toast0 22 minutes ago
      Certainly, it's better if you don't have these. But if I was working on something like this, I think you release when you have something that covers most of the territory, and then refine it over time.

      Maybe someone else comes and helps out here and there.

  • ricardobeat 41 minutes ago
    “byte-identical” is one of Claude’s favorite expressions
    • ronnier 0 minutes ago
      And what’s wrong with that? Nothing. AI is an amazing tool that has made me and many other more productive. It’ll only get better and stronger.
    • Tiberium 39 minutes ago
      The whole readme is extremely Claude-written, its dense Claudish style leaks from every sentence ;)
  • davikr 45 minutes ago
    How many tokens and which models were used?
  • sick_of_slop 38 minutes ago
    [dead]