[FF7 PC] Full source code reversing project?

  • Thread starter Thread starter paul
  • Start date Start date
Status
Not open for further replies.
ergonomy_joe should be able to share code that he has personally written, character for character, out of his own brain.

It is really interesting to see the logic underneath, even for the game over/insert disc. Those address-for-var names make it just a little harder to digest :)
 
The conversation concerning the reversed source code has moved to private for now.
But to answer the questions:
.I would like to post my work somewhere
.I am aware of the legal issues

In the meantime I will try to update my blog with bits of code.
Especially, some of you maybe aware of the fact that the ORIGINAL EXE includes 3 different graphic drivers (Direct3D hardware accelerated, software, [broken]OpenGL) plus the option to load the driver as an external DLL. The sofware part is really interesting: it is a complete STATE OF THE ART (for 1997) sofware rendering library. I find it hard to beleive that EIDOS developped it only for the FF7 port, but I couldn't find traces of it in other games of that era. Anyway, this part of the code is really fun (mostly inlined ASM) and I'd like to make some post about it.

BTY, I might not be able to post anything during weekdays so don't blame me for not answering please
 
The conversation concerning the reversed source code has moved to private for now.
But to answer the questions:
.I would like to post my work somewhere
.I am aware of the legal issues

In the meantime I will try to update my blog with bits of code.
Especially, some of you maybe aware of the fact that the ORIGINAL EXE includes 3 different graphic drivers (Direct3D hardware accelerated, software, [broken]OpenGL) plus the option to load the driver as an external DLL. The sofware part is really interesting: it is a complete STATE OF THE ART (for 1997) sofware rendering library. I find it hard to beleive that EIDOS developped it only for the FF7 port, but I couldn't find traces of it in other games of that era. Anyway, this part of the code is really fun (mostly inlined ASM) and I'd like to make some post about it.

BTY, I might not be able to post anything during weekdays so don't blame me for not answering please
I think what you've managed to achieve is pretty outstanding! Your method of verification is quite interesting too. Btw perhaps SW renderer could have been used in Tomb Raider ports?
 
Square did made the port not eidos. Eidos was chosen to publish the game because they had a name by PC players. Halkun has more info about that.
 
Where I live its legal to rewrite c++ from assembler, because its your own work as long as you don't have been given a zip file of Squaresoft or Eidos code.

The FF VII engine is that big, that you better do it semi automatic like with
The state of the art multi platform open source decompiler:
https://github.com/uxmal/reko/
 
I think where you live really doesn't matter, it's probably more like Japan's rules that matter. I'm not a lawyer though, so take this with a grain of salt.

That being said, I think disassembling and manually rewriting the code isn't illegal anywhere. Am still not a lawyer though, so don't take my word for it.
 
Decompiler still almost needs a rewrite to obtain clean readable code, which is what ergonomy_joe has already done for 80% of the engine.
 
You can find others amples on my (not very good) blog concerning decompilation: http://magnetiktank.blogspot.jp/
Hey i think you have a great idea. And let me tell you have done a wonderful job.

Just by looking at your "lgp lib", seams very familiar with my lgp class i wrote from the wiki data and myst6re docs.

I'm specially interested in all hardcoded functions which access and modify directly some Savemap vars that can't be reversed from the script file.

So, if you guys are gonna start a new project count on me.
 
Last edited:
That dude already has reversed it to the point of it compiles again and field works etc :)
 
Any update on what ergonomy_joe is doing, from what I can see on his blog, he has most of the game working except the battle3d module!  Congrats

As to what I have been doing, is trying to figure out a bit battle stuff and reversing the battle3d module
 
From my understanding Edios was chosen because they had a project they had already ported to the pc from psx . A little game called Tomb Raider, at that time there was no other psx -> pc ports
 
You think the company that did the port still has the source somewhere on some forgotten disc?
 
Any update on what ergonomy_joe has done?  I have not seen anything on his blog for a while
 
I saved this discussion well in my head and from time to time I check his blog as well. While it sad there is no progress but what can we do with the current information? It would be great if we could start to replace the modules through dll's even if they do nothing yet, but this could be a big step for moders.
 
Auto decompilers simply do not work. This will result in a horrible mess that is unlikely to compile, if it does it will probably just crash. The real work done here is in understanding and documenting the internal game structures, not just the function and var names.
 
You think the company that did the port still has the source somewhere on some forgotten disc?
One would think that by now it would have been leaked, or at least its fate would have been leaked, but who knows. Squaresoft made a whole studio to create FF7 and it was torn apart after the game was done (see http://q-gears.sourceforge.net/index.phtml?content=4), but there is not a word anywhere AFAIK about what happened to EIDOS' copy of the code. Many fans and modders have been pining to know. Hopefully an insider who knows can post the info anonymously someday. I hope leaks about that will be more likely now that Square-Enix cares more about the remake now.
 
Auto decompilers simply do not work. This will result in a horrible mess that is unlikely to compile, if it does it will probably just crash. The real work done here is in understanding and documenting the internal game structures, not just the function and var names.
The gears document has a lot of stuff in it but with an auto decompiler maybe you can put together working stuff together with what you know from the gears doc.  I think thats how ergonomy_joe has been doing it.  Still, very interesting project and hope to see more!
 
The gears document has a lot of stuff in it but with an auto decompiler maybe you can put together working stuff together with what you know from the gears doc.  I think thats how ergonomy_joe has been doing it.  Still, very interesting project and hope to see more!
No seriously you can't, read my last post. He has been doing it by reading the asm, converting to C by hand and compiling with the SAME compiler used on the real game. Then compares the ASM output is the same. You simply can't automate this and get meaningful source code at all.

Even if it worked you'd have 100,000's of vars and functions that overlap etc and have no meaning until someone looks at each one in turn and figures out what its doing.

E.g something like:

void* g1 = 0xdeadbeef;
void* g2 = 0xcafebabe;

int F12343()
{
  int v1 = *g1;
  int v2 = v1 + *g2;
  return v2;
}

Is useless when the real code would probably have been like:

struct Player
{
 int x,y;
};

struct World
{
 int x,y,w,h;
};

Player* gPlayer;
World* gWorld;

int GetPlayerWorldPos()
{
 return gPlayer->x + gWorld + x;
}
 
If you have code that compiles, even if you don't know how any of the variables work, just by having compilable code you can add in bits of code that change the variables and see how the game responds and name them appropriately, ex comment out a function, see what breaks etc etc.

Also, the way he is going it is great, I would like to learn how he does it.
 
Status
Not open for further replies.
Back
Top