[boricj]

This depends on what you want to achieve.

Projects that aim for perfect decompilation (i.e. producing a source tree and build instructions that recreates the original artifacts bit-for-bit) like the one for Super Mario 64 are essentially preservation projects in spirit. The advantage with that approach is that once it is done, you can be sure that you didn't introduce any changes or bugs compared to the original release. They can also be a starting point for ports or mods.

Not all projects aim for that. Some like REDRIVER2 (for Driver 2) retains the core of the original game, but with bug fixes and quality of life improvements bordering on a full-blown PC remaster. It obsoleted the original PlayStation release with its atrocious framerate and embarrassingly low draw distance.

Heck, in my own reverse-engineering/decompilation project I went for a highly unconventional approach where I delink the original PlayStation executables into relocatable object files and attempt to relink them as a Linux MIPS program. The idea was to do a Linux port on the cheap, which I can then rewrite piece by piece in C until I don't have any MIPS object files left, at which point I could port the source tree to modern architectures. The first part panned out but not the second one (too many issues to sort out), so instead I think I'll rewrite the game piece by piece while staying on the PlayStation platform.

Decompilation projects are essentially bespoke, one-off R&D projects. The closest to a standard would be decomp.me, but that is geared towards perfect decompilation only. Step outside that and you're basically on your own, writing your own tooling in a barren landscape where everyone do things their own way.