1. FAST6191

    OP FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    33,467
    Country:
    United Kingdom
    Background.
    Mario 64 saw a decompilation (the act of turning compiled code back into human readable high level source code, generally considered a very difficult task with physics backing that one up) effort that by the time of the first leak ( https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/ ) has managed to recreate the source code such that a suitable compiler would make a 1:1 version of the game. A later more official release of said decompilation effort was slightly more tweaked still but mostly the same.
    Eventually some people managed to convert the console specific code into things so display, sound and controls would happen from a PC. From there it was off to the races with high definition mods, widescreen, control tweaks, longer draw distances and everything else ( https://gbatemp.net/threads/super-mario-64-pc-port-has-been-released.564235/ ), as well as ports to the Switch ( https://gbatemp.net/threads/mario-64-port.564633/ ), Wii U ( https://gbatemp.net/threads/super-mario-64-port-wii-u.571682/ ) and seemingly 3ds ( https://gbatemp.net/threads/super-mario-64-port.564431/ ) these days among other things. We are not here for that, links above for those that care about it all. At time of writing other than the PC most things are still rather in beta form but are often playable, most so than emulation might be as well.

    More recently we saw something referred to as the gigaleak II wherein lots of code and confidential files from Nintendo and partners were found and released to the wider world. https://gbatemp.net/threads/nintend...lopment-repositories-and-source-codes.570616/
    Part of that was apparently a later stage beta dump of the Mario 64 source code.
    Being leaked code one should be aware of all that goes with that, not that the decompilation is that much better for various potential legal purposes ( http://archive.vn/k4cut ).

    Anyway I am curious if someone compared them.
    Even if it was not a beta version a simple file compare is not going to do so it will require some fiddling -- information is lost from source code when you compile it, most notably is comments but function names, file names, formatting and more will also be lost and not necessarily recreated by the decompilation.

    We are however out of my comfort zone here as to the approach necessary for that, or indeed if there is such a thing already in place.
    Were I to speculate.
    I would probably make a virtual file (think change tracking on a wiki, maybe even full GIT style, or something) for this to refer back to for final but that is just a that is just a display trick than something amazingly useful in this.

    Punctuation, spacing/indentation, comments... all stripped back to absolute minimum. Comments might warrant something a bit more as they are still likely of some use in an analysis, hence the virtual file.
    Related to that might be worth crushing things down to one file and keeping things as functions within it rather than separate files but more on that later, any headers similarly.

    Function names would probably want to go/be crushed a la a javascript minimiser. Maybe as a side project one or the other project could be converted to the other's but that is a side project.
    Said functions could probably be fingerprinted -- I imagine most things are called in the same order (or maybe something of a weighted probability), any sub functions are called in the same way, its exit routines and variables passed back/returned (not to mention the stuff passed going in) are probably the same, any hardware calls are likely to be the same too (display still has to display, control still has to read the controller state in its location...). Elimination would likely take care of the rest.

    How much might want to be backfilled or adapted from the decompilation (or maybe vice versa) I don't know. That would be a stylistic debate from where I sit, a valuable one but still of lesser importance than the base approach.

    A lot of that could be done manually (basic regex) or with basic "anonymiser" scripts if needs be. However N64 vintage C is something I could probably poke with a stick, read to determine variables and compile -- the sort of tricks where the decompilers would likely recognise functions in assembly form and know enough C of the era to make an accurate guess is not in my walking around knowledge, and I would like to be a bit further towards that arena. Something more subtle like something likely being the result of a last minute cut and paste (think messing with email formatting but being lazy) because of the formatting used is even less likely to be caught by me.
    I don't imagine much of great interest would be discovered here that would not be found by simply reading comments and maybe having a working knowledge of the decompilation/game in general and what were the last minute bugs squashed and variables tweaked (not sure if any acceleration, slippiness, button timings, camera handling, heights and so forth). I am more curious about what the decompilation got similar and what was quite different but said bugs and variables could also be interesting, as might indicators of missing/cut content beyond the luigi stuff already seen.
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - decompilation, comparison, Anybody