nanaian

The Java compiler is written in Java, so you can run it in CheerpJ just like anything else. JavaFiddle does this: https://github.com/leaningtech/javafiddle/blob/main/src/rout...

To my knowledge: not really. Porting to other platforms is usually an explicit non-goal by the decompilation team. For some reason, port projects tend to attract the wrong kinds of attention, both from the public at large and from dodgy people in the romhacking community.

Thanks! I'll tell my story...

I first played Paper Mario on a PAL N64 when I was around 6 or 7 years old, and I recall not being able to get past certain sections because I could barely understand the dialogue. The cartridge had a previous owner who left a completed savefile, so after getting stuck I loaded it and eventually defeated the final boss. I remember the day vividly where I left the console on overnight displaying the "The End" screen because I thought there might be an easter egg - I'd just learned about Totaka's song in Luigi's Mansion (GCN). There is no postgame in Paper Mario, but I always dreamed of one.

In my time in the modding community I've found that I prefer to create documentation and tools for others to express their creativity than create my own, which is why tools like [1] and [2] exist. The decompilation lets users make mods even more flexibly than previous tools, so I hope to see some people build some cool stuff.

I also just love learning about how this game from my childhood works. It feels kinda like archaeology: discovering parts of the engine where hacks were thrown in at the last minute, finding code that was linked against an earlier version of the engine, etc.

[1] https://mamar.nanaian.town/ [2] https://github.com/nanaian/papermario-dx

SM64 uses SGI's IRIS Development Option (IDO) compiler. And yes, it's unoptimised.

Paper Mario, however, /does/ use GCC, and it's optimised. Figuring out the compiler version was fairly easy as there's a limited number of options - we know when the game began development, so we looked for releases around that time. The harder parts were figuring out compiler flags (consider all the -f flags affecting code generation; papermario used -fforce-addr) and coming to the terrifying conclusion that the compiler was modified!

The majority of papermario was built with a modified build of GCC 2.8.1 [1] at -O2. The SDK code (libultra, nusystem) was built with GCC 2.7.2 at -O3. The iQue Player version, i.e. the Chinese release, was built with EGCS.

[1] https://github.com/pmret/gcc-papermario

I've actually been working on a mod for Paper Mario that aims to make it blind-accessible! However, I'm not sure what the best practices or prior art is as to how to represent certain features. Do you have any good resources?

Depends on your goal. If it's matching decompilation, probably the former.

There's been research into the latter but its in early stages. https://github.com/nforest/awesome-decompilation?tab=readme-...

decomp.me gives us a large database of C(++) <-> target asm to train a model on ;)

As far as I know, yes.. Besides simple differences like register allocation, it's difficult to prove that your code behaves the same as the target if its nonmatching. It's also just really satisfying when you get a match.

When doing standard reverse engineering, you might use something like Ghidra or Hex-Rays. This is what the developer of noclip.website [1] did to reimplement a lot of Mario Galaxy code, such as enemy AI.

[1] https://noclip.website/#smg/AstroGalaxy

Building decomp.me was really worth it. It even helped us match the very last function - someone from the Metal Gear Solid decompilation team finished it off.

https://decomp.me/scratch/GImYC https://github.com/pmret/papermario/pull/1019

Dev here, AMA

Yep! CheerpX's documentation is available here: https://labs.leaningtech.com/cheerpx

Wasm threads via SharedArrayBuffer have been a thing for like 5 years. In Rust you can use wasm-bindgen-rayon, for instance. DOM access is and has always been easily achieved through imports. It's performant, too: https://youtu.be/4KtotxNAwME

Developer here. CheerpX for Flash runs the Pepper API version of Flash, and you're correct about the license. However, we don't do full Linux emulation just to run Flash - we emulate PPAPI and run the Flash player in an x86 JIT (CheerpX).

Yuri talks about CXFF's architecture here:

https://youtu.be/7JUs4c99-mo?t=1045

...but if you wanted full Linux system emulation, we got it! https://webvm.io

Same here on M2 MacBook Air.

CheerpJ developer here! If anyone has any questions about how the integration works, feel free to ask :)