Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - paul

Pages: [1] 2 3 ... 7
Have a look at psx gpu prims, the other types probably match onto that, POLY_FT4 etc. Perhaps the other types are g/flat/untextured shaded tri and quad?

But Makou Reactor is out side of the game itself, so not sure what you mean by that?

I believe re-creating just the field module via hooks in to the existing game is probably a viable starting point. That way if nothing else is completed at least there is a standalone end-to-end working field.

Yeah loading a a png or whatever is easy enough, seems the code will need some clean up though. Its still using SDL1, immediate mode OpenGL etc. Another striking issue is everything being global :)

Ogre is still far more complex than SDL2 when FF7 engine its self is so simple. On things like Travis-CI you do have to compile it everytime or come up with somewhere to store it because its so large. Where as compling SDL2 on travis-CI takes 1 min. This does matter in open source projects that need free CI.

Edit: Oh btw the 20mins figure is for travis to build QGears when ogre is prebuilt!

Because as discussed in this thread the old version uses the original formats and is far more progressed than then current "generic" version. Also Ogre is a massive dependency to carry, it takes 20 mins to compile latest version compared with about 3 mins of the old.

Seems 0.14 source is no where to be found

I'm thinking maybe making the github repo a compliable version of the 0.14 source might be a good idea. Probably the code will need modernizing now though. I'm making the assumption that implementing the missing field opcodes is enough to get it working.

The whole decompiler itself is a needless complexity VS using the original file formats directly.

Maybe you should get back to work on that?? :):)

I guess because I lost interest due to needless complexity. :)

Try almost any C# decompiler, native code is another matter. And simple script byte code is certainly decompilable. And the topic here is the simple script byte code, I already said many posts ago that decompling native code is a lost cause :P

"It's better to use original scripts because it's not possible for a program to covert them to a higher level language automatically"

It is possible, its not just not easy to do since it means writing a decompiler that produces structured code.

You aren't distributing any data belonging to them, you are distributing converted code to make the data work, still requiring every user to launch it and link to original data folders/archives for the conversion to convert original data that they already have by having bought the game.

So was the chrono trigger remake, 100% remade assets/scripts/code and they got C&D. Its a heavily grey area and the same laws don't apply everywhere. Might as well just make it use the original data files rather than risk being shut down IMO.

For games that are still being sold this does happen, not distributing any data is the only way to be 100% safe, unless of course you are a well vexed lawyer :P

Even if you could whats the point with out the sounds/fields etc? Also its a grey area and would get you C&D'ed for "porting" the scripts.

If I had time to spend on it I would just get the field module 100% working, but I'd probably also design it so it can work with FF7-9 since a lot of the core functionality is the same.

What do you mean by target teh engine? What are you even trying to do? The only way to have a flexible engine is to make a new one either from scratch or using unity/unreal/whatever else.

I've just told you how he does it :P Having compliable code that is unreadable and unstructured is useless, changing asm is easier in that respect. The process of updating them all would literally take years of work.

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;

Maybe its more:

int32_t * v8 = v3 ? (int32_t *)-0x7ff0ed54 : (int32_t *)20;
*(int32_t *)(v1 + 28) = *v8;


*(int32_t *)(v1 + 28) = v3 ? -(int32_t *)0x7ff0ed54 : 20;

And v1 is clearly some structure so it would actually be:

int32_t* g7ff0ed54; // some unknown global
v1->Field_28 = v3 ? -*g7ff0ed54 : 20;

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.

How 'bout posting the answer then!

Team Avalanche / Re: Monster Remodels!
« on: 2016-05-30 22:26:29 »
Don't want to be rude but those models look like 20 min of work.

Looks like a life time of works better than yours.

Graphical Releases / Re: [FF7] Recreating scenes in 3D
« on: 2016-05-23 19:15:38 »
What about just replacing the field of FF7.exe via injection dll? It might be possible to embed unreal within the field.

Graphical Releases / Re: [FF7] Recreating scenes in 3D
« on: 2016-05-11 07:04:42 »
There are a few annoying arbitrary limits - this is why I think replacing parts of the field engine to render actual 3D or some other better effects/models would make this even more worth while.

Pages: [1] 2 3 ... 7