For the last 7 years and some change, I've been reverse engineering Final Fantasy 7 with a small band of international cohorts.
For the last year-or-so, I've been recording all the findings into a huge 200 page technical document, called "Gears". (A slightly updated wiki exists too, but a little leery of posting it here) Now it doesn't have everything. Actually, it's missing some pretty important stuff, like the worldmap format, Fieldscript opcode definitions, and almost all minigame subsystems except for Chocobo breeding.
Well, every once in a while me and my fellow teammates talked how cool it would be to take this information and re-implement the FF7 engine for newer computers. Nothing ever happened, of course, but we talk about how cool it would be nonetheless. Amusingly enough, the only reason why my tech document exists is because we kept talking about how cool it would be to document our findings all in one place and I was the only one who got around to doing it.
So the other day, we were one again discussing about how cool it would be to make an engine. This time, for giggles, I decided to make a SourceForge project to create a FF7 drop-in executable, much like ScummVM. (Actually, almost exactly like ScummVM)
Now, next thing I know, some programmers I know start sending me code snippets. Keep in mind, I like breaking things apart and seeing how they tick. My coding abilities are very weak. (I've done things to pointers that should be illegal in seven states.) So here I am looking at this code, having little idea what it does and saying "ok, that looks good, you need to get rid of the binaries so that SVN can accept it." And then they do it, and show it to me again.
Dear God! I'm now the project leader and they are looking to *ME* to like, lead... and stuff.
The partial upshot of the project is I want to implement FF7 so I can play it natively on Linux, (and other platfroms) The engine is actually very expandable. Like ScummVM, the engine has been tweaked for newer games and actually has a growth path.
FF7 -> Parasite Eve -> FF8 -> PE2 -> FF9
Going backwards, the engine actually has artifacts and design philosophies going all the way back to FF1.
In a perfect world, a full, portable implementation of FF7 would be nice, with the ability to extend the engine to include the processing of data from the
Parasite Eve series and later Final Fantasy games. Going further, I would also like to have the engine accept user data. (Non-mixable with square data) so end users can use the engine to make their own RPG games.
Now, here's the funny bit.
I have no idea what I'm doing ^_^. It was decided that the engine would be written in C++, a language that I don't even know. The repository is Subversion, which I'm also ignorant in. I can barely use CVS, and even then I've used it to archive shell scripts and have never done a reversion. I have people giving me code and telling me they can't access SVN to upload it. They want me to do an initial import and I have no idea how to even upload it.
It kind of exploded on me. I would like to help, the only thing I can do is tell how things work and write it down. I'm not a coder by any stretch of the
imagination, not only that, my access to internet is really limited. In a perfect world I would love to pull down code from SVN, play with the code and upload it. That's a trick to do from an internet cafe on a laptop.
Right now, as the project stands, we need a universal way to read a PSX disk to get the data off of it. A PSX disk is not iso9660 compliant. It's an XA mode disk. When the game is running, the PSX doesn't even access the files by filename, but directly loads data referenced by sector information. The filenames are a cosmetic artifact from the development cycle and were
removed in PE and FF8. (That's why there is only one huge archive file on those games) To access PSX data on a normal computer you have to do direct sector reads and include the subchannel information. (iso9660 ignores and does not read the subchannel information.)
On a PSX disk, the sectors are larger and game data is placed in the area where subchannel data used to be. This means a user-space filesystem has be created. Right now we are discussing if we should require the user to make an iso image of the PSX to play with that data, (I don't like that idea), or directly access the device. (Win32 and POSIX have massively different ways of executing this strategy.)
After we get that down, we need to do the following.
1) Initialize the savemap (global game data) using data stored in kernel.bin
2) load and execute the first debug room.
I'm not really interested in game saving/loading yet, but the savemap needs to be in place to make the initial party, initial gold, and initial menu
configuration. Fieldscript also needs to be decoded further, we only have about 8 of the 256+ opcodes decoded.
Because I seem to be the only one who intimately knows how the game executes, and have a strategy of what needs to be implemented, I became the "leader" for the project. Lucky me! ^_^
Anyways, That's where I am. It's kind of long-winded and That's pretty much what I have in a nutshell. If you have any questions, ask away.
Gotta get to work now. I'll be around.
-halkun
Q-Gears - A final fantasy 7 engine.
Moderator: ScummVM Team
Congrats, Hai-Kun, sounds like you have an exciting time ahead of you
.
As somebody who worked on writing portable software for a long time, let me suggest what I'd do with regards to the CD access: I'd write a "disk layer", which all the code would use to access the track/sector data as required. This layer separates the code which needs to read the data, from the code that implements the actual reading.
Then, you can have multiple modules which all implement the "disk layer" API. One could read the data from disk image; one could use Win32 APIs. One could use Linux APIs; one could use Mac OS X APIs; etc. (I am afraid there is no POSIX API doing what you need, BTW).
This way, everybody can play the game via the disk image code, even if you haven't (yet) written a "native" CD driver/FS for their system, without lossing the possibility of allowing direct access to the CD data on systems that support it (or rather, on systems where *you* support it).
Good luck with the project!
![Smile :-)](./images/smilies/icon_smile.gif)
As somebody who worked on writing portable software for a long time, let me suggest what I'd do with regards to the CD access: I'd write a "disk layer", which all the code would use to access the track/sector data as required. This layer separates the code which needs to read the data, from the code that implements the actual reading.
Then, you can have multiple modules which all implement the "disk layer" API. One could read the data from disk image; one could use Win32 APIs. One could use Linux APIs; one could use Mac OS X APIs; etc. (I am afraid there is no POSIX API doing what you need, BTW).
This way, everybody can play the game via the disk image code, even if you haven't (yet) written a "native" CD driver/FS for their system, without lossing the possibility of allowing direct access to the CD data on systems that support it (or rather, on systems where *you* support it).
Good luck with the project!
- dreammaster
- ScummVM Developer
- Posts: 555
- Joined: Fri Nov 04, 2005 2:16 am
- Location: San Jose, California, USA
Somewhat ironically, I'm well familiar with the Gears document.. late last year I wanted to start a new project, and it was a tossup of whether to start a FF7 reimplementation using the Gears document, or to disassemble Lure of the Temptress and make a ScummVM module. In the end, I chose the latter. But maybe later on in the year when I finish the module I might be able to lend a hand.
I'd just expand on what fingolfin said - make sure to make everything class based. Particularly if you're forward designing the engine to later handle other games, it becomes much easier if everything is modular and replacable. Not only that, it makes it easier to compile on different systems if your I/O layer is properly abstracted; SCUMMVM is a good example, since it's been targetted for many different systems.
I'd just expand on what fingolfin said - make sure to make everything class based. Particularly if you're forward designing the engine to later handle other games, it becomes much easier if everything is modular and replacable. Not only that, it makes it easier to compile on different systems if your I/O layer is properly abstracted; SCUMMVM is a good example, since it's been targetted for many different systems.
the PC ports?
@hal-kun: i know this might be dumb as I have no experience in this field, but did you think of backwards engineering the PC ports of FFVII and FFVIII. At least these will have discs you can read easier than messing around with PSX discs. Have you visited the PSX-emulation chaps/chapettes that are around the net? I'm sure there would be some people there who could give you some pointers if you are determined to use the PSX originals.
Anyway there's my bit of useless help![Wink ;-)](./images/smilies/icon_wink.gif)
An excellent idea for a project and the best of luck to you.
Anyway there's my bit of useless help
![Wink ;-)](./images/smilies/icon_wink.gif)
An excellent idea for a project and the best of luck to you.