Some stuff I've been working on

[pompom454]

As of recently, decomp.me's matching system has updated a bit to be more reliable. This lowered leskal's work into a high-70s compared to the 80.99% he seemingly had. My code is a fork of leskal's and thus has some improvements, including the better accuracy to the target asm. While it's not 100% matched, it is a few steps closer to matching.

[pompom454]

I would like to leave a quick note that the game seems to refer g_wipe to actually be g_pwipe, as hinted by the assembly. Unless you guys were already on top of that, I would just point that out.

[pompom454]

I've also got vprintf working! 100% matched too!

https://decomp.me/scratch/HjnSN

Since I don't know how I will be integrating the function into the project, I figured you guys could help me. This is my first game decomp project and, while I do reverse engineer games, I haven't contributed yet... so yeah.

[545u]

I've also got vprintf working! 100% matched too!

https://decomp.me/scratch/HjnSN

Since I don't know how I will be integrating the function into the project, I figured you guys could help me. This is my first game decomp project and, while I do reverse engineer games, I haven't contributed yet... so yeah.

I checked out the scratch you linked. OSTRM is a C++ class, so you'll need to change the code to accommodate for that.

[pompom454]

Strange, as that seems to be one of the only solutions. Additionally, the language is set to C++. ¯\_(ツ)_/¯ I don't know what could be wrong...

[545u]

Strange, as that seems to be one of the only solutions. Additionally, the language is set to C++. ¯_(ツ)_/¯ I don't know what could be wrong...

Here is a cleaned up version that calls the class methods: https://decomp.me/scratch/7xN0t.

[pompom454]

I have checked and my code seems to be correct to that of the target assembly. I DO make a OSTRM instance on the stack, I called __5OSTRMi(&strm, -1); as the "constructor" you may say, setting up the object as if it was C++, then I call the member function CchOstrmPrintf__FP5OSTRMPcT1(&strm, s0, s1); which is our golden ticket as I am passing the pointer as this which is usually what C++ expects of me, and then I clean up with _$_5OSTRM(&strm, 2);. Because of the constraints of this project, I am essentially just wrapping C++ as C.

[545u]

Yes, your code compiles to the same assembly, but I see no reason why you would write it that way? The whole code base is C++ so you don't need to "wrap C++ as C".

[pompom454]

I mean...how in this way...my code is more correct in that it's accurate. I don't need pretty'd up stuff for a simple function (as matching > readability, and at that anything else is nice). Optimizing for human readability isn't good if we already have working code in that sense. I know, there is a "stylistic change" that can happen. HOWEVER, I noticed that quite a bit of the codebase does have the binary-intent readability mine had. vprintf is a very small function in this sense and, while it does handle an enormous amount of text in-game, is only ever used to print out text.

Additionally, most decomp projects do need the closest you can get to with a binary-identical output. Your code is also theoretically pretty fragile and prone to failing if we ever change code structure and/or optimization flags. Mine is fragile in the sense that if people decide to toy around and try to break it. Also, we cannot rely solely on RAII for critical timing or functions that are sensitive to the stack/register layout. It's also really compiler-dependent. The compiler was smart enough to know your code...but other compilers might handle it a lot differently. I've also added some comments just in case mine is used.

[545u]

1. We use the exact same compiler and flags as the game when it was originally compiled.
2. In this context the structure of the code won't affect how this single function compiles.
3. By looking at the prototype build's debug symbols you can determine what fields the OSTRM struct has and how big it is.
4. The goal of this project is to write clean, human-readable and matching code.
5. The original developers most likely wrote the function the same way as I did because it just makes the most sense. Your code looks like it was copied straight from a decompiler.

[pompom454]

1. My saying was just a theoretical in which it COULD happen but is unlikely.
2. You oversimplified that. Same compiler ≠ portability. Sure, you can get away with "matching the game's code" but every decompilation program has its own biases and tendencies. If you pretty up code, on some platforms will match it while others it won't. You need the reliable solution and reliable code, not just "hey my code seems to compile with 100% matching I guess".
3. I know the OSTRM struct has a stack frame of 0x450. I didn't object to this nor did I mention it.
4. Nowhere does the markdowns or code mention a "clean human-readable matching decomp project". And some of the code isn't as readable as you think it'd be. Like, to the blind eye no one will know what FUN_001c3c00 means. Additionally, things like src/P2/transition.c or src/P2/zap.c are very unreadable. Sure, the former is not complete at this stage, but we just need matching code.
5. If I remember correctly, (most if not) all decompilation projects don't care about if the code looks like the original developers intended, it's really about if it works the way the developers intended. And really, quite a few decomps have helped me understand how my favorite games work. It's not if the developers wrote it your way, it's if the developers made it work the way you made it.

[Joseph-DiGiovanni]

matching > readability

If all we cared about was matching, we'd just throw in some inline assembly and call it done. The objective is to reconstruct what the original developers could have actually wrote so the code is understandable. This is more archeological reconstruction than clean room reimplementation.

The best matches are the ones that look like production game code from 2002, not compiler output golf.