ReWriting the FF7 Engine

  • Thread starter Thread starter Alhexx
  • Start date Start date
Status
Not open for further replies.
Why bother? Hard disk space is cheap nowadays, and compressing data too heavily just makes the game take too longer to load stuff. Light compression is OK: it's so quick to decompress that you save disk space without slowing down loading. I'd complain if a game applied something like full RAR to all the levels and took an extra minute to load up; Battlefield 1942 takes long enough to load as it is...
 
fice is right, gotta find a sweet spot. If you need to compress so things arent too large, then do, but you dont want to over-do it and end up with massive load times, Id rather a game be on several cds and take up a gig or gig and a half of hard drive space and load fast rather than be on one or two cds and take 6 or 7 hundred and load slow.
 
Erm ... just a question...

I've asked if it would be possible that our team could do it.
But now it seems like we're seriously planning how to start that... am I right?

BTW: Welcome back, fice! :love:  I've missed your posts here!!!

 - Alhexx
 
It seems like a game of tetris...

The blocks are kind of falling into place, if they align, well, cool but it depends on the falling blocks.

I'm documenting Gears as fast as I can. I'm hitting sort of a "hump" with the debug rooms. There's a lot of data go through and I have a lot of corrections to make on this guys doc about it. (I also have to change it enough to make it a proper dirivitve work.)

After that's done, I have to hop back into the kernel and rearrange that badly. I need to place the file formats from the end of my doc into "filesystems" as the PSX filesystem is now becoming more known. (It's overall fuctionality is also being revealed thanks to Cyb)

It's just such a pain to dump every debug room, read how it's supposed to work, and the compare it to the scripting code for the room. There are suprises, but it's so methodical and dull. I hit this point in my PSX doc when doinng the GTE. Didn't help I got a love letter from Sony about that time telling me that if I used Psy-Q, there were going to send a much of mad proctologists to my house with a really rusty drill.

If someone has a copy of the PSX version of the game on ISO, I have a PSX script editor that can edit the field scripting code and re-insert it back into the iso. This will make my life much easier as I need more people to help discover what on earth all those opcode arguments so. The Debug rooms are nothing but examples. That's it. I woudn't be suprised if they cut/pated parts of the debug rooms into the game proper for common tasks.

Woudn't hurt for someone to take my specs and write a script editor for the PC version. That's beyond my ability.

Anyway, I'm working on. Gears is still accessable via my WWW button
 
Halkun:
I could help with tools unfortunately I don't have the PC version, I do have the PSX version.  The idea thing would be to have a Virtual CDROM with shadow files (IE files that reside in global PC memory) that can be edited on the fly.  Then mount that using the Playstation emulator.  So boot check etc.

Ahhh well!

I still need to get the background battle scenes loading.


Allhex
From Halkun's docs I suggest following the original FF7's system. Break it up into modules.  Using a kernal (core) with all the functionality the applications use.  Think of it like KERNAL.DLL in win98.   So Halkun's reversing of it is actually a better way to get there.  If you understand what 'causes' something you can better run it, and edit it.  This makes making content much easier.

To be blunt though it's not a matter of IF you can do it, that's entirely possible, the real question is.. WILL you do it. Many people have the ability but they don't do it in other words.

All
I'm contemplating making tools for FF7 but I need to know the underlying data and formats.  I'm quite familiar with making compilor tools, so its not a big deal too me.  Essentially if you want to do what you are thinking about you have to build these tools irregardless.

The preferable thing to do is encode the scripts into XML'ized stuff and compile from that (been there done that).
 
I was reading this thread and I was thinking about the state of psx emulation right now.

Since you guys seem to be saying that the psx and pc games are pretty much the same except with some minor file conversions, shouldn't it be, in theory at least, possible to use the sound and graphic plugins as a basis for the engine ?

I mean most of the problems of the pc version are solved with these plugins such as 32 bit support, higher resolution, better movies rendering, better sound, etc.  If you also factor in that there are opengl pluigns available it could also simplify croos-paltform compatibility no ?

Although this might be totally impossible.  I have no programming knowledge whatsoever.  It's just a thought.
 
As there are only two versions of the game, I don't think that's really neccasary. I'm still pluggin aling on the scripting language, however, you all have some new tools at your disposal to help me.
 
Actually Halkun I'm making a small deviation to get a decent debugger interface working with Pixels PCSX debugger add on. Once that gets going ( 2 week delay my guess), I can focus on examing the FF7 interaction.  

You wouldn't have a 'clean' listing of function calls commonly used in PS1 games would you?
I have a list of the bios function calls, I guess that would be a reasonable start.  Anyone 2 weeks before I can get the debugging system working then I can start mangling FF7 data again.

Unfortunately it will be for Windows (need a good way to translate borlands dpr information into thier GTK equivalent to port to Linux).

Cyb
 
You wouldn't have a 'clean' listing of function calls commonly used in PS1 games would you?
I have a list of the bios function calls, I guess that would be a reasonable start.  Anyone 2 weeks before I can get the debugging system working then I can start mangling FF7 data again.
Click to expand...

I've never played with Psy-Q... ever. I have no idea what kind of calls that lib makes to the metal. When I was making my doc, sony was very very very very direct in telling me that no libs were go into my psx doc.

I don't even have the bios calls... (I used to)
 
You wouldn't have a 'clean' listing of function calls commonly used in PS1 games would you?
I have a list of the bios function calls, I guess that would be a reasonable start.  Anyone 2 weeks before I can get the debugging system working then I can start mangling FF7 data again.
Click to expand...

I've never played with Psy-Q... ever. I have no idea what kind of calls that lib makes to the metal. When I was making my doc, sony was very very very very direct in telling me that no libs were go into my psx doc.

I don't even have the bios calls... (I used to)
Click to expand...
Hmmm.. I suppose if I will then need to use a derivation system to create C level function call listings.  IE when you find a call to a subroutine find out where it goes/does then give it a name and guessed parametric reference.  Should work.  I plan on storing this data in an XML database so I can compare it with other information.  I think I have the Yaroze function list.. and I think I have the PS1 bios list as well. Hmmm.

I should get to work on that soon.

Cyb
 
You are assuming that there are standard calls that are commonly used, there isn't

Though it is true that many game companies use Psy-Q libs to make games ...LoadTIM(), playSEQ()... These are very often tweaked and stripped for the individual application. The PSX does not use shared libaries like DLLs, a PSX executable is a static COFF-type. I don't think you are going to find entry points very easily as they can be anywere, and custom within the executable.

The FF7 kernel is amazing because it manages threading and several sub programs, each with a scripting language, all without a Memory manager. (FF7's MMU is software(!)) This reqired many of the libs to be tweaked to run in such an environment.

However there is a strict programming rule that the PSX executable must use the BIOS fuctions. You can't talk directly to the metal. This is why PS1 games work on a PS2  even with a massivly different architecture. This is also why Virtual Game station ran so well. Connectix wrote thier own BIOS.

Also it's why Bleem was only 512K. It caught BIOS calls and made DirectX calls.
 
You are assuming that there are standard calls that are commonly used, there isn't

Though it is true that many game companies use Psy-Q libs to make games ...LoadTIM(), playSEQ()... These are very often tweaked and stripped for the individual application. The PSX does not use shared libaries like DLLs, a PSX executable is a static COFF-type. I don't think you are going to find entry points very easily as they can be anywere, and custom within the executable.

The FF7 kernel is amazing because it manages threading and several sub programs, each with a scripting language, all without a Memory manager. (FF7's MMU is software(!)) This reqired many of the libs to be tweaked to run in such an environment.

However there is a strict programming rule that the PSX executable must use the BIOS fuctions. You can't talk directly to the metal. This is why PS1 games work on a PS2  even with a massivly different architecture. This is also why Virtual Game station ran so well. Connectix wrote thier own BIOS.

Also it's why Bleem was only 512K. It caught BIOS calls and made DirectX calls.
Click to expand...
That explains why I never saw a program use the TLB hardware in the PS1.. odd that.  I suppose if they had things would be much more difficult (LOL).

Well if they use the BIOS I can deal with the bios calls easily enough. That at least will give an idea of what they are doing at that level.

Cyb
 
On top of which ^_^

Yaroze and and Psy-Q are totaly different beasts. Yaroze allows no access to the CD-ROM at all. Also the executible format is different It was an "ecoff" bin and not compatable with a PSX-EXE type coff file. The yaroze libs are massively different and made by Sony. Psy-Q was deveoped by Psygonsis.

You also can't boot a Yaroze ecoff from a cd-rom. The BIOS would halt the disk.

The TLB was used for caching purposes when needed. Because all the memory segemnts were hard wired togeather, depenending on what memory mirror you worte to, that would engaguge and disengauge the cache. That's really it.

PSX also doen't have a math co-prossesr either. The GTE is a fixed-point matrix trasformation engine. It also is horrably buggy and that's why the texture perpectives suck so badly. Many games relied on the buggy GTE and sony coudn't fix it later on.
 
...we know that FF7pc was written in C++. Therefore, we must think within the limitations of that language when trying to reconstruct how FF7 can access and decode battle operations, etc, and that includes file I/O, and memory storage.

That leaves us with commands like ".read"; ".get"; and ".getline" for loading the battle animation data into memory, if I'm not mistaken...
Click to expand...

C++ doesn't really have any limitations. Its not uncommon for most video games to have a lot of the operations that need to run very very fast (thousands of times per seconds, in some cases) written in ASM (assembly) blocks.

.read, .get, and .getline are not really effecient for the very specific and repetative purposes of a lot of the FF7 files. I would be more surprised if they didn't write thier own low-level file and memory IO functions than if they did.

They teach that in intermediate C++ classes. Its a fairly common practice as far as I can tell.

Remember that C++ and ASM pretty much go hand-in-hand, and you can write ASM directly into your C++ programs.

But then, Square programmers may also be a fairly lazy lot. So who knows?

And in case anyone is wondering, PSX games are programmed in a version of C++ as well -hooking into a propriatary Sony hardware API.[/b]
 
Maybe you're thinking of the much-disputed LZW patent? (read: "The GIF bitch")
 
Maybe you're thinking of the much-disputed LZW patent? (read: "The GIF b*tch")
Click to expand...

Which has expired, I wrote a compressor that used it as a college project lot of fun, but tottally useless :)
Unisys had the patent on it and decided to 'exercise' the patent, they got a rude awakening as people deleted the standard unix compress off there systems and used something else instead.  "Yes we are compliant .. we don't use your software at all or a variant we deleted it, you can come and look if you wish."

sfx1999
LSZ compression is used which is a very different animal.

Cyb
 
Status
Not open for further replies.
Back
Top