N64 recompilation

I have a CS degree and I can't fully comprehend how this is so easily (?) possible.

Please explain like I'm moronic (which I am). I get that for a decompiled game it's just machine code (unless someone spends weeks figuring it out and writing it back as human readable a la Mario 64 pc port), but barring that is it really so simple as to look at whatever instructions are happening and treat them like API calls and then being able to replace instructions with whatever you want?

Why don't all emulators work like this already? My mind is blown. This feels like the equivalent of those troll physics comics where you power your car with two magnets facing each other. Please explain

POSIWID: The Purpose Of A System Is What It Does Shirt $21.68

It's All Fucked Shirt $22.14

POSIWID: The Purpose Of A System Is What It Does Shirt $21.68

  1. 2 weeks ago
    Anonymous

    ai voice means it's a scam youtuber talking out of his ass selling snake oil. probably a pajeet

    • 2 weeks ago
      Anonymous

      >ai voice
      the absolute state of IQfy

    • 2 weeks ago
      Anonymous

      highest iq IQfy user

      • 2 weeks ago
        Anonymous

        ai voice means it's a scam youtuber talking out of his ass selling snake oil. probably a pajeet

        Youre both pajeets who have no native English.

    • 2 weeks ago
      Anonymous

      > computer voice
      yeah, not watching any of it and blocking the channel.

      usually.

      I'm not buying it. N64 emulators have used dynamic recomplitation for years, and they still have glitches. How could this one guy build a static re-compiler that perfectly emulates all the graphics API. Not to mention it can be very difficult to statically disassemble everything in one pass. Maybe the N64 processor architecture makes this possible, but im still skeptical.

      > How could this one guy build a static re-compiler that perfectly emulates all the graphics API
      they can't. nintentoddlers have only a handful of games they understand the microcode of, and each game can use whatever microcode they like, which leaves 90% of the n64 library unsupported.

      [...]
      Youre both pajeets who have no native English.

      have a nice day, Black person.

      • 2 weeks ago
        Anonymous

        There's no "computer voice" in the video, pajeet.

  2. 2 weeks ago
    Anonymous

    >I have a CS degree
    wiener sucking

    • 2 weeks ago
      Anonymous

      >i can't fully comprehend how is it possible to compile leaked C code
      So this is the power of a CS degree

      degreelets seething

      • 2 weeks ago
        Anonymous

        They have degreelessness mode permanently on

      • 2 weeks ago
        Anonymous

        I make more than you in your industry and without the student loan debt. Who is the one seething here?

        • 2 weeks ago
          Anonymous

          >I make more than you
          Stop talking like a child.
          Nobody cares if you "make" more money than someone else.

  3. 2 weeks ago
    Anonymous

    >i can't fully comprehend how is it possible to compile leaked C code
    So this is the power of a CS degree

    • 2 weeks ago
      Anonymous

      >compile leaked C code
      that's not what's happening at all, moron

  4. 2 weeks ago
    Anonymous

    I'm not buying it. N64 emulators have used dynamic recomplitation for years, and they still have glitches. How could this one guy build a static re-compiler that perfectly emulates all the graphics API. Not to mention it can be very difficult to statically disassemble everything in one pass. Maybe the N64 processor architecture makes this possible, but im still skeptical.

    • 2 weeks ago
      Anonymous

      It's not perfect at all it's just supposedly faster than current methods

      • 2 weeks ago
        Anonymous

        Why can't this be extended to work for all emulators instead of the plugin-based shit shows some of them are?

        • 2 weeks ago
          Anonymous

          Basically he based his project off the OOT and Mario64 decomplication projects, and then generalized it a bit to get a head start on any other game by mapping out the common parts, it's not a plug and play system, nobody else knows how to use it besides him

    • 2 weeks ago
      Anonymous

      This is the first poster in this thread who actually watched the video.

    • 2 weeks ago
      Anonymous

      NTA, I got as far as downloading and building it but seems like there's a ton of shit you have to pre-configure so I'll wait until someone makes a version for complete morons like myself

      • 2 weeks ago
        Anonymous

        Yeah looks like you have to run the ROM through a disassembler first to create an elf file and parse the metadata.

    • 2 weeks ago
      Anonymous

      Lookup how ghidra works. Your tax dollars gave fruit.

  5. 2 weeks ago
    Anonymous

    It's a hype video for an unreleased project, none of this is "really so simple" you're just a fricking moron who thinks that computers are magic despite claiming to have a degree in CS

  6. 2 weeks ago
    Anonymous

    >is it really so simple as to look at whatever instructions are happening and treat them like api calls and then being able to replace instructions with whatever you want?
    No.

  7. 2 weeks ago
    Anonymous

    If you can do JIT translation of an emulated target's machine code to the host machine code you can usually do AOT translation as well. There are issues with self modifying code however, so I'm guessing there's some kind of fallback JIT since that was commonplace on older architectures. PS3 emulation does some very clever stuff using LLVM to convert PowerPC assembly to LLVM IR, then uses LLVM to generate host compatible binaries of the translated PowerPC instructions. QEMU has TCG which is a JIT that translates basic blocks from guest to host at runtime. Apple's Rosetta does AOT to translate x86 binaries to ARM compatible binaries (with the help of some special CPU mode to speed up the translated code), but ultimately has a JIT as well because of self modifying and runtime dynamically loaded code

    • 2 weeks ago
      Anonymous

      NTA
      since you seem knowledgeable is the code produced with this thing actually clean room code or is it actually compromised?

      • 2 weeks ago
        Anonymous

        nta but from the video it's just turning mips assembly directly into C code using macros, eg.

        addi $a0, $s0, 69

        ->

        void func(int A0, int S0)
        {
        A0 = ADD32(A0, S0, 69)
        }

        So it's pretty much the same game code underneath, probably couldn't call that cleanroom really
        I'm not even sure if I'd call it "native PC" since there's probably a ton of optimizations this would prevent from working, which an actual decomp project would be able to use.

        • 2 weeks ago
          Anonymous

          too bad. II was thinkiing it might be some kind of CS algorithm based clean code but i guess it doesnt hurt to have game preservation only from thiis outcome. I really want new ocarina games though.

        • 2 weeks ago
          Anonymous

          How do you (programmatically) look at this and swap libultra calls to something else?

          • 2 weeks ago
            Anonymous

            Libultra has some well known signatures iirc, they probably just scan for opcodes used in it and then name the funcs of it based on those

        • 2 weeks ago
          Anonymous

          its just text editing mate, you disassemble it and then translate the assembly into x language with disoptimizers which just pick up on patterns in the assembly and spit it out the likely written shitlang code.

          A couple years back I was considering whether it would be viable to just auto-translate instructions from ROMs (for e.g. NES) into x86 assembly. It would allow people to easily mod retro games by writing x86 code and having that code executed between 'native' instructions. So if I understand right they're doing something like that here?

          • 2 weeks ago
            Anonymous

            >just auto-translate instructions from ROMs (for e.g. NES) into x86 assembly
            I saw a project like that before: https://github.com/Xenomega/NESgen
            Seems the dev of that decided that statically recompiling per-game didn't work as well as general system emus though.
            Really most emus do things like this internally already though, eg https://www.youtube.com/watch?v=19ae5Mq2lJE talks about how RPCS3 converts PS3 vector insns into AVX2/AVX512

          • 2 weeks ago
            Anonymous

            Building a static recompile is much better in terms of computational load.

          • 2 weeks ago
            Anonymous

            If getting better perf was as easy as running a single tool to statically recompile it every emu would have switched to doing it ages ago
            ...which they pretty much did when they moved over to AOT/JIT/dynarec compiling
            Only difference here is this gives you C files that are easier to work on, good for your popular Zelda and Mario games where teams are willing to work on improvements, not as useful for random N64 shovelware.

          • 2 weeks ago
            Anonymous

            >vector insns into AVX2/AVX512
            Was that the main problem?
            morons were saying it was super hard to emulate.

          • 2 weeks ago
            Anonymous

            Its not like every CPU had that instruction set, yes it was introduce years ago (2013) by Intel but not many programmers thought it was useful for standard programs and even the coder for that PS3 emulation optimization mentions that: https://whatcookie.github.io/posts/why-is-avx-512-useful-for-rpcs3/
            So you needed to have the right hardware and also the knowledge about avx512 instruction set and you needed to know how the PS3 SPU handles floating point values and shuffle instructions at least that is what hes talking in greater details in the video. So yes it was hard to emulate unless you had all of the correct setup and knowledge.

  8. 2 weeks ago
    Anonymous

    JIT/AOT has been a thing in emulators for years, now instead of letting the emulator handle it all for you, you have to instead setup a whole code repo and run tools to statically recompile it, then find a matching libultra PC port and switch all the games calls over to it, and of course go through and fix all the various bugs & issues, add fixes for increased framerate/resolution, all that shit.

    Meanwhile I can let mupen64 handle all that and load the game in less than a minute.

    Pretty sus that like 3 youtubers all dropped videos and twitter posts about it at the exact same time, maybe this is useful for people who want to start their own "holy shit XYZ PC port commenced!!" project on github (with patreon + kofi links of course), but the average guy trying to play random unloved N64 game #3432 will likely still have to use an emulator.

  9. 2 weeks ago
    Anonymous

    its just text editing mate, you disassemble it and then translate the assembly into x language with disoptimizers which just pick up on patterns in the assembly and spit it out the likely written shitlang code.

  10. 2 weeks ago
    Anonymous

    >I have a CS degree and I can't fully comprehend how this is so easily (?) possible
    Christ. Do they really just give these degrees out like candy huh.
    Worthless, garbage education.

  11. 2 weeks ago
    Anonymous

    >is it really so simple as to look at whatever instructions are happening and treat them like api calls and then being able to replace instructions with whatever you want?
    What the frick are you talking about?
    Of course you can't just replace instructions with "whatever you want."
    God damn...
    Go back to school.
    Re-enrol in ASM for fricks sake...
    Fricking moron...

  12. 2 weeks ago
    Anonymous

    this is just an emulator that can only play a single game. you get some performance gains but when you're emulating the N64 on a PC made after 1998 that's not particularly useful

    • 2 weeks ago
      Anonymous

      It's not an emulator. The claim is it does a full decompile for the N64 source code, then re-compiles for the target system (Windows), translating graphics calls to e.g. DirectX 12.
      Supposedly the performance is exceptional and somehow flaws that existed within emulators are no longer present. It can be done on arbitrary games.

      • 2 weeks ago
        Anonymous

        these early game systems have games with self-mutating program code running from RAM, my intuition is this isn't a generalized solution (i don't know if determining whether you've decompiled a game like that completely is computationally decidable). maybe it's possible to cover some portion of the library

        >translating graphics calls to e.g. DirectX 12.
        that's how emulators work as well

  13. 2 weeks ago
    Anonymous

    Someone explain how I was just thinking about my semi-obsession with the underlying functions of Zelda 64 and all of a sudden this thread exists?
    Frick you, OP. And frick whatever the hell is responsible for this BULLSHIT! My entire life was ruined by this piece of fricking shit.

  14. 2 weeks ago
    Anonymous

    These decomps are all N64 games that happen to reuse the same engine as other games which makes it easier.

    OOT/MM gets decomp because it's based on Mario 64 which also got decomp. Wouldn't be surprised if Starfox 64 is next.

    • 2 weeks ago
      Anonymous

      This isn't a standard decomp, this is from a static recompiler. Every N64 game (except for a few that used custom microcode) can be ran through this and ported to PC.

      • 2 weeks ago
        Anonymous

        On Linux or just Windows?

        • 2 weeks ago
          Anonymous

          Both.

      • 2 weeks ago
        Anonymous

        >except for a few that used custom microcode
        So the very best ones.

        • 2 weeks ago
          Anonymous

          Specific solutions will be developed for those ones. The system allows for arbitrary adaptation of translation flaws. (frame rates, CPU speeds, etc)

  15. 2 weeks ago
    Anonymous

    This is awesome.
    Now all they need to do is recreate all the textures in high-res versions (with modern enhancements like diffuse textures). Re-write 90% of the code. And re-create all the shapes with much higher-polygon counts. Also convert the 2D sprites to 3D. Then they will have finally succeeded in porting the game! (for back-up purposes, of course)

    • 2 weeks ago
      Anonymous

      Forgot. They also need to enhance the animations for arbitrary frame rates...

  16. 2 weeks ago
    Anonymous

    Recompilation could be used to make modern PS/Xbox emulators possible, since they already basically run full PCs

    • 2 weeks ago
      Anonymous

      OG Xbox uses funky weird Nvidia shit which makes it a pain to emulate to this day. PS3 and 360 are more forgiving since they are more in common with PC.

    • 2 weeks ago
      Anonymous

      The CXBX og xbox emulator used to do almost the same thing, turning game into a "native" app by translating xbox api/hardware calls into win32 stuff so you could have Halo.exe etc
      All the per-game hacks it needed made them decide to just make a proper hardware emu instead, but nobody really gave a shit about xbox so that tooks years longer than it should have.
      With this new thing I guess all the per-game hacks to switch libultra / fix framerate / etc will be kept inside C files which can be thrown on github, popular games might benefit if people work on it enough, but would probably be better to work on the actual decomp.

  17. 2 weeks ago
    Anonymous

    Its nothing new and many emulators do this and its called High Level Emulation (HLE). The N64 SDK is well known and high level emulators detect API calls in code and translate them to host API calls. The difference here is that HLE has to generalize this approach in a way to make any game work which is why few games have glitches since they're trying for one size fits all approach and it doesn't always work out. The approach in the video posted is doing exact same thing but on a game by game basis, fixing any glitches by patching code to fix the glitches and then saving the result to an EXE.

    In any case, low level N64 emulation is pretty accurate these days. The only hurdle is emulation of the MIPS pipeline which causes timing sync issues with few sensitive games. But even thats being worked on.

  18. 2 weeks ago
    Anonymous

    >everyone making fun of this anon in IQfy but afaik he is correct?

    • 2 weeks ago
      Anonymous

      decomp will be 1000x more useful than some unlabelled static recompiled turd

      • 2 weeks ago
        Anonymous

        Well this is ready now and does the job without complex input/setup/controls.

      • 2 weeks ago
        Anonymous

        this
        IQfy is actually turbotarding rn

        • 2 weeks ago
          Anonymous

          >10 year lead time

Your email address will not be published. Required fields are marked *