Q-Gears - A final fantasy 7 engine.

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

Post Reply
hal-kun
Posts: 7
Joined: Wed Apr 19, 2006 4:31 am

Q-Gears - A final fantasy 7 engine.

Post by hal-kun » Thu Apr 20, 2006 5:50 pm

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

fingolfin
Retired
Posts: 1466
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin » Fri Apr 21, 2006 12:35 am

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!

User avatar
dreammaster
ScummVM Developer
Posts: 398
Joined: Fri Nov 04, 2005 2:16 am
Location: San Jose, California, USA

Post by dreammaster » Fri Apr 21, 2006 3:46 am

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.

Bobbin
Posts: 65
Joined: Fri Nov 18, 2005 10:41 am
Location: Germany

Post by Bobbin » Fri Apr 21, 2006 10:26 am

Just wanted to wish you good luck with your project. I'm coding for years now but still huge projects like these scare me. But there is always that one point that makes it all worth it - the first time your software does what it should do :)

User avatar
Freddo
Posts: 282
Joined: Mon Oct 31, 2005 4:41 pm

Post by Freddo » Mon Apr 24, 2006 8:53 am

Whoa :shock:

This is so cool 8)

I wish you the best of luck with the project :)

phyber
Posts: 3
Joined: Wed Sep 21, 2005 7:03 am

Post by phyber » Sat Apr 29, 2006 10:40 am

As a massive Final Fantasy VII fan, I wish you good luck in this project.

User avatar
kuir
Posts: 6
Joined: Mon Apr 17, 2006 11:21 am
Location: France

Post by kuir » Thu May 11, 2006 9:07 am

As the world's greatest fan of Final Fantasy VII (yeah, that's about it !), I wish you good luck and wish that someday I will be able to play FF7 on my OSX. May the force be with you !!

User avatar
Dark-Star
Posts: 137
Joined: Sun Oct 30, 2005 9:36 pm
Location: Reutlingen, GERMANY

Post by Dark-Star » Fri May 12, 2006 12:51 pm

Hey, that's awesome! If I only knew about that "Gears" document before.... Last year I started reverse-engineering some FF7 files myself, but I scrapped the project because I didn't have enough spare time. This is definitely something worth watching, I wish you good luck!

Dasaan
Posts: 4
Joined: Sat Jul 15, 2006 10:56 pm

Post by Dasaan » Sat Jul 15, 2006 10:58 pm

Sweet! I look forward to playing FF7 on my Linux box one day.

crosis
Posts: 1
Joined: Mon Jul 31, 2006 1:04 pm

the PC ports?

Post by crosis » Mon Jul 31, 2006 1:20 pm

@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 ;-)
An excellent idea for a project and the best of luck to you.

Post Reply