Persona 3 FES/4/SMT 3 Decomp when?
Wait for a leak, fan remake or the like. Chances are for PS2 on up it is going to be C++ and that is a far harder target for decompilation compared to C which is what most things on the N64, PS1 and maybe PC games - 5 years from those and such would have used.
These are so awesome. I don't understand how these programming wizards pull this off. Can't wait to see what's next. I'd sell my left nut for a Star Fox 64 project.
I covered a little bit in
https://gbatemp.net/threads/can-i-aka-you-as-i-cant-wont-code-port-this-game-to-this-device.576997/
More generally. Compilation (turning a high level language that humans find pleasing to read/write in to something the computer understands) for many years was seen as a one way affair thanks to something called the halting problem. That is to say you can be all la la la I am pretending I am a computer but when you encounter something that depends on external input (controller, randomness, complicated state of other functions... it matters little) you have to halt pending that input (hence halting problem).
However most halting is boring. In say Mario you might jump in a pit and die but the more interesting path is choosing life or something novel. This reduces the problem space of figuring out what to do massively.
Further to this there are a variety of other tells. You get your hand slapped by the programming masters if you name a function A and just do a bunch of inputs to it as a little black box -- if someone (maybe someone who isn't you) comes to your code in 5 years you are not going to remember what A is or does, nor will others in the team or checking your code for errors. Get a bunch of nice function names (PC will probably have them, sometimes they leak in some file like in the Diablo one, sometimes they are included somewhere or in some other port which likely is similar) and you can infer what things are from play (it is annoying to figure out damage calculations from play, even with cheats, but it is not impossible to get some idea).
The compilers (back then at least) were largely predictable inputs to output as well. Find some copy of the library Nintendo gave to developers (leaked SDKs being useful for this, indeed one of the few things such SDKs are truly useful for post 16 bit era, as will be leaked code) and you can recognise certain input-output combinations. You might have some binary packing (be it protection or devs trying to squeeze that little bit more data in with compression) to cut through though. Anyway this was so predictable that if you know the compiler and target (usually rather limited for consoles compared to PC, though even there you have but a handful depending upon the era)
For decompilations then some will, some won't but the whole dynamic recompilation that N64 (and now most things of that vintage) emulators do works by having the missing inputs from the first thing above a lot of the time thus being able to know what is happening in that instant. Dynamic recompilation then takes the inputs, the instructions it will do and rather than simulating all the chips and timings instead makes it something the host computer understands. This dynamic stuff can then be noted as it is generated and give ideas as to what is happening.
With all the above it is then noted there are also only so many ways to sensibly skin a cat. Sure I can write something 10000 lines long that makes things lower case to capitals (granted that is probably a function of the baseline C libraries). If you are a good coder and know the general input, output and a high level description of the thing in between, and can observe it in play you can probably figure out a way to replicate the original exactly. This is where the byte for byte aspect comes in as it is possible to take the time to figure out exactly what happened, if you are skilled enough at C programming such that you can think how some dev would have thought (and for as buggy as a lot of games of this vintage are* that is potentially quite the skill -- think difference between understanding a foreign language and same from someone that is drunk and has a speech impediment) and recreate accordingly. Byte for byte can have implications for certain things with limited space (if it is larger), bug for bug compatible (normal inputs is one thing, handling bad/corrupt ones is another. Normally a good thing but sometimes bugs make for emergent gameplay and thus you just broke that) and possibly speed (see race conditions; if your replacement is slower then even if it is better code if something tries to execute where normally its baseline would have finished you might get errors or maybe has to be pushed to next frame/cycle you get slowdown where there was not)
*equally this is games not medical machine (
https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/ ) so the proverbial just got through programming school 21 year old that is content to be paid the peanuts that were/are game industry wages and thus speed might be the order of the day.
I find the exact requirement somewhat of an odd goal to have as a line in the sand rather than dream goal for a lot of these projects, though I suppose if it prevents the million forks of code with no lesser cross compatibility then so it goes.
C++, which has a lot of nice perks for game writing compared to C, increases the problem space massively which is why C++ is something of a barrier and most things you see decompiled in the next probably quite a few years will be using C and thus in the window from the end of the 16 bit era to the start of the PS2 and a bit less for the PC (it jumped to compiled languages and then C rather ahead of consoles).
For those that know a bit more programming or at least want a jumping off point then one of the major features of C++ is object oriented programming aka OOP, this changes things radically compared to procedural languages like C (games being the harder aspect of things like this as code can and will jump around, compared to say something converting one image format to another) and allows code to jump in all manner of directions and be jumped into from said same and speak to other aspects happily. This means what is just on the bubble for what computers can sensibly decompile in C is pushed thousands of times for C++.
https://www.geeksforgeeks.org/introduction-of-object-oriented-programming/ https://www.tutorialspoint.com/What-is-object-oriented-programming-OOP
Imagine then writing an FPS in what is essentially going to be handled as a very fast slideshow doing a list of one and done functions vs OOP where you can reach out and touch all manner of things essentially at random and you start to see why people like OOP for things like games. This is why when the memory and CPU performance for C++ became reasonably doable then devs ran to it as fast they could. Newer things can be done if they are not in C++ and instead things like Java (there is a reason the GTA ports for the PS2 era efforts started with the Android ports, Android being largely written in Java) or C# (various Microsoft consoles have used this for a few things, though mostly indie games. See also .NET and XNA) which owing to being just in time compilation and very expansive libraries in the case of C# can be sensibly decompiled. The list of such things is on the shorter side though so instead you will probably be waiting on some nice devs doing a source release (happens from time to time), a new gigaleak type affair, accidental inclusion in something else (see one of the Princess Maker games on the DS, though in this scenario later port on another system is probably going to be it.
https://www.pagetable.com/?p=28 for another thing.), hacks for the companies (most of which will be delighted to have the code back as lost code is a real problem back then) or someone not wiping a development computer in a bankrupt company/dev having a backup in the attic and it going out in a yard sale... that or someone making a functional equivalent (see clean room reverse engineering, which nothing above is even close to and thus shocking me that we don't see more lawsuits) by systems analysis and recreation (what is gravity, what is collision, what is jump height, what is firing rate... yes it is a lot of effort but things have been achieved with this, might even be better than the original). That or the engine it uses is released by one means or another and is similar enough to that version that things can be "ported" across, the rise of unreal potentially being quite nice for that one.
Source
