Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: halkun on 2006-03-31 05:29:59
-
I've been contemplating writing the framework for an engine this coming summer. Here's the rub. I suck at coding. But I don't think that's a huge problem ^_^
Here's some bare bones...
1)Platfrom: Cross platfrom
2) Language - C - (GCC)
Rational: It's mature, portable, cross-platfrom and the language I know. It will lend itself to more help if I need help as C++ people can do C, but not the other way around.
3) 3D Graphics - OpenGL
Rational: It's mature, portable, cross platfrom, and the only 3D API I know. It's pretty simple to pick up and whole books to learn it are downlaodable for free.
4) Display Management - SDL/Allegro
Rational: Both of these are a much better manager than GLUT. Allegro is a really pretty API, but I don't know how AllegroGL can co-operate with OpenGL. SDL has lots of pretty add-ons including MIDI and stuff. Both are also cross platform. I don't know which one to use. I've done SDL, but it's a little too "low level" for me. I'm used to the Allegro API
5) Repository: CVS
For a project like this a code repository would be cool. Sourceforge gives them away.
6) Licence: GPL
I'll need the help ^_^
----------------
My first task will be to load kernel.bin and initalize the savemap. After that, a framwork menu system for starting the system and then seeing if we can get a field file to "boot"
small steps
Then again, I might just be playing pretend again.
-
I'll have a look, maybe I can donate some text rendering code that uses the ff7 font. I'll have to rip it out of my test framework, first.
-
2) Language - C - (GCC)
Rational: It's mature, portable, cross-platfrom and the language I know. It will lend itself to more help if I need help as C++ people can do C, but not the other way around.
I think we shoud use C++ instead of C.
Rational: It's not much harder than C. It can do everything that C can do.
It has a lot of standart containers and algorithm in STL. The C++ code easily reusable in other projects (Xenogears engine for example or something else we may want to write) unlike the C implementation. And we can find more pluses of uses C++ instead of C.
-
Another less obvious point is C++ can be used like C if need be :D
If you are going for a generic system. SDL might be OK. I would prefer the use of GTK since it would allow the frame work and I believe you can still use SDL with it. GTK will make portability easier as well as developement of the GUI easier. It is highly portable to Win32 platforms as well as win?? (XP is the ?? Longhorn is going to be a problem I fear).
I recomend looking at this from a virtualization perspective also. IE what is the best way to make everything function the same from perspective of the engine across multiple platforms. I know you like linux so do I.
I also recomend looking at Eclipse.
What MEDIA are you planing on using for the engine? There is PC and PS1 media for FF7. this will be an important decision since it will affect how the engine deals with data. I don't believe the original FF7 operates quite the way we think it might to be honest. I'm fairly certain that the ISO system information is just there because they didn't bother obscuring it. I will check if it has something similiar to Xenogears hidden in it :D
As for handling the source code, I think Source forge will give you the tools, whatever they are using I recomend using. I use to have a sourceforge account which I couldn't find the information for if my life depended on it.
-
Oh, and feel free to use the battle background rendering code I posted ages ago.
-
If you want to release it GPL, I would recommend using QT.
As much as I love C, the code tends to get very messy after awhile. Plus, it'll be tougher to keep it cross platform. Since you already know C, you won't have a problem using QT, beings that it's C++.
-
I'm not sure what you'd use QT or GTK for? FF7 is a full-screen game, so there is little use for all the stuff that a UI library provide.
-
@ C vs. C++: Why not a mix then? I've found that C++ is most useful at the low levels of programming. Smart types/objects, templates, containers, all the "base" code that you write once and then just use, greatly simplifying the mundane tasks. That having been said, using C++ at the higher levels of programming can be bothersome and present unnecessary problems, unless you have a very clear code design document from the start (which I believe a project like this won't have, since so much of the wanted functionality is ...well, yet unknown). Therefore, you could have a bunch of C++ people writing the "tools" which the C people can then use without too much adjustment (learning to write "object.method()" instead of "function(objectptr)" is the easy part).
Just my two cents, since IMHO where C++ really shines is being able to make your code more abstract, more functionality and less form, and being able to do so at neglible or no performance loss.
-
I'm not sure what you'd use QT or GTK for? FF7 is a full-screen game, so there is little use for all the stuff that a UI library provide.
QT is FAR more than a UI library. It's an entire API, complete with it's own ADTs, pointer types, Sockets implementation, SQL and OpenGL plugins among other things. GTK in no way BEGINS to compare to QT.
-
WOW! Talk about over-engineering!
Ok let me backtrack. I'm glad we got this discussion going. Let's indulge.
Here's the goal: make a small, cross platform engine that is compatible with FF7PC, FF7PSX, and user created data.
Here's the problems I have, and why some of this discussion became very silly.
First.
I absolutely loathe OO Programming. Period. I've given C++ more than a few shots, but I just don't like the abstraction. I come from the days of programming when computers were considered procedural systems. They still are. I just don't like the concept of placing a function within a structural entity. (Classes) I've tried. I really did. But I simply don't grok the OO discipline as a whole. I can perfectly concede that there are those who swear by at, and use it very elegantly. I can't. My roots are in Machine Code and C sits on it really well. It's human enough to work with the system, but Machine-y enough to see what's going on under the hood.
Another facet is the C++ is what the original FF7PC was written in. The last thing I would like is have undue stress if Square tries to pull some kind of copyright heartache. It's best to write it in another language. I just want to do the engine. No data unless it's user supplied. (I.E. SummVM) The "big" project is to make an RPGMaker kind of system. (Think FreeSCI) In the end, I don't want to use square's data at all.
I also know C. It's silly to start a project in a laguage I simply can't speak.
++++++++++++
On the display Management side. I saw GTK+ and QT tossed around. To quote Tycho from Penny Arcade... "That went to a weird place"
What I mean by a "display manager" is the ability to make a 2D surface for OpenGL to draw in. GLUT is the "Native" manager, but it doesn't have any ability to do other cool things like thread support, MIDI and wave support, and it's 2D texture support is a little clunky. SDL is cool, but a little low level. There are modules available that could fill the gap. Allegro is "higher" but has no threading support and can't do GL management without a special extension. I want this to be cross-platform. (Think PDA or PSP) I'm not going to recompile GTK or QT just to get a display surface hook for OpenGL.
That's silly.
Keep in mind the ORIGINAL FF7 ran on 2MB of ram, with a very tiny BIOS interface (512k)
QT is FAR more than a UI library. It's an entire API, complete with it's own ADTs, pointer types, Sockets implementation, SQL and OpenGL plugins among other things. GTK in no way BEGINS to compare to QT.
We don't need ANY of this crap. Why does FF7 need sockets of *any* kind. SQL? I need a OpenGL *surface* that's it. GLUT will work, but I'd like to use a gaming lib to gave me access to MIDI and stuff along with a GL surface. Something small, modular, and compact.
I don't know where you guys are getting a GUI idea from. The FF7 GUI is in the system iteslf and uses mostly 8 buttons. (up, down, left, ok- , cancel[X], menu[triangle], and.... that other button[square]
++++++++++++++++++
Right now simply writing a program that allocates memory for the savemap and initializes the "new game" data should be fine. This information is found in Kernal.bin and the only lib needed is zlib to make it happen.
Here's some problems.
I have found that my linux computers can't read the FF7PSX disks. They were written in mode 1 and my CD-R/DVD-R simply barfs on them. This is going to be an issue with Linux users as that means you have to loop-mount an ISO or do direct hardware reads, bypassing the OS. That will suck.
Let's work out problems like this first.
I'm also going to be making a UML flowchart with Dia to get a framework down on FF7's execution strategy. I'll be putting this up online. You can download Dia yourself and we can play with psudocode before committing anything to a compiler.
Comments?
-
First.
I absolutely loathe OO Programming. Period. I've given C++ more than a few shots, but I just don't like the abstraction. I come from the days of programming when computers were considered procedural systems. They still are. I just don't like the concept of placing a function within a structural entity. (Classes) I've tried. I really did. But I simply don't grok the OO discipline as a whole. I can perfectly concede that there are those who swear by at, and use it very elegantly. I can't. My roots are in Machine Code and C sits on it really well. It's human enough to work with the system, but Machine-y enough to see what's going on under the hood.
Ok :D
Well don't get all bothered about C++ you can use a C++ compilor and write in C. I suggest you follow Qhimm's logic a bit. The C++ abstraction of low level things makes your C simpler. Let me explain, I write for embeded systems. I use prefer using C++. Why? because low level code using C is complicated and eventual ends up what C++ would do anyways. Otherwise working with low level hardware requires a special version of ansi C (IE with extensions and #pragma's to make things work cleanly on the hardware). And I'm talking lower level than a device driver here. Abstract your low level interface using C++ it makes things significantly more portable OK? That's as simple as it gets. Everything else can be in C.
Another facet is the C++ is what the original FF7PC was written in. The last thing I would like is have undue stress if Square tries to pull some kind of copyright heartache. It's best to write it in another language. I just want to do the engine. No data unless it's user supplied. (I.E. SummVM) The "big" project is to make an RPGMaker kind of system. (Think FreeSCI) In the end, I don't want to use square's data at all.
I also know C. It's silly to start a project in a laguage I simply can't speak.
No problem it can use C++ without you even knowing it. It's as simple as that.
What I mean by a "display manager" is the ability to make a 2D surface for OpenGL to draw in. GLUT is the "Native" manager, but it doesn't have any ability to do other cool things like thread support, MIDI and wave support, and it's 2D texture support is a little clunky. SDL is cool, but a little low level. There are modules available that could fill the gap. Allegro is "higher" but has no threading support and can't do GL management without a special extension. I want this to be cross-platform. (Think PDA or PSP) I'm not going to recompile GTK or QT just to get a display surface hook for OpenGL.
OK I can see QT... why are you hell bent on no UI to manage the game outside the game? You expect people to launch this from the CLI with the options they want?
We don't need ANY of this crap. Why does FF7 need sockets of *any* kind. SQL? I need a OpenGL *surface* that's it. GLUT will work, but I'd like to use a gaming lib to gave me access to MIDI and stuff along with a GL surface. Something small, modular, and compact.
That I agree too We don't need QT's features. GTK just allows a nice GLUE the darn thing together interface.
I don't know where you guys are getting a GUI idea from. The FF7 GUI is in the system iteslf and uses mostly 8 buttons. (up, down, left, ok- , cancel[X], menu[triangle], and.... that other button[square]
The original system is an embeded system a PC is not. I suggest not trying to make a UI like those anoying games that possess your PC :(
Right now simply writing a program that allocates memory for the savemap and initializes the "new game" data should be fine. This information is found in Kernal.bin and the only lib needed is zlib to make it happen.
Hmmm OK this is doable right now no?
I have found that my linux computers can't read the FF7PSX disks. They were written in mode 1 and my CD-R/DVD-R simply barfs on them. This is going to be an issue with Linux users as that means you have to loop-mount an ISO or do direct hardware reads, bypassing the OS. That will suck.
Ummm Mode 2 Form 1 and 2 primary form1 though. (See xenogears playing I've been doing).
Let's work out problems like this first.
I'm also going to be making a UML flowchart with Dia to get a framework down on FF7's execution strategy. I'll be putting this up online. You can download Dia yourself and we can play with psudocode before committing anything to a compiler.
Comments?
Well for the Media handling a RAW iso is the only way for Linux to run the media.
This is because most of the data is recorded in Mode 2 form 1 and form 2 (this includes XA audio).
The sectors are as a resullt 2352 bytes of raw data. By examing the first 16 bytes of the sector header (12 bytes sync 1 minute 1 second 1 frame 1 mode), you get the mode. All PS1 CD's are mode 2 and mode 1. So you MUST read this header. Mode1 sectors are 2K data 32bit CRC 8 bytes unused and 276 bytes error correction data (reed solomon parity data) This breaks the data up as block size 4 bytes. 79 blocks repair data (ECC data) and 512 blocks data for the ability to repair 15% corruption in the data. Mode 1 form 2 I believe has No error correction data.
Mode 2 has 2 forms
Form 1 and 2 have a subheader 1 byte FileNumber 1 ChannelNumber 1 SubMode 1 CodeInformation. (there are 2 copies of this data).
Mode 2 form 1 is almost identical to Mode 1 form 1 (save it doesn't have 8 unused bytes because of the subheader). Form 1 is used for Data on the PS1. Form2 has the subheader and 2334 bytes this is used for audio on the PS1. The Ps1 setup is such that things are setup in an almost nonsensical manner however it's a result of the PS1 hardware requiring 2x speed for reading all data so audio files etc are formated in odd ways. For example 1 file might have the audio for 8 different conversations. An FMV may have 7 video and 1 blank sector or 3 video and 1 audio interleaved throughout the disk. Again a result of the PS1 2x requirement and the system expiring if you do anything else.
Bottom line is the PS1 media is complicated because of the hardware requirements. You have to use an ISO 2352 sector image for Linux because Linux doesn't do raw data. :D
Cyb
-
I'm hell bent on no UI because managing the game outside the game can be handled by another program altogether. I'm happy simply to read the configuration from an .ini file and call it that. If someone wants to write a front-end to manage this before the program executes (ala an installer), more power to them.
Keep in mind that the menu module in the engine is going to be tricky. The original FF7 used modules that seem to be scriptish, (the .mnu files) but I can't tell if that's native code that's banked in (most likely) or some sort of script language ala fieldscript.
Either case, the menu module was rewritten in the PC version and placed within the executable. (Which leads me to believe that the PSX .mnu files are compiled machine code banked in from the CD-ROM) At a later date we can debate if we want to hard-code the menu system or make some external TCL script thingy to make it more end-user configurable.
Now about mouting the PSX disks. When I put in a "normal" ide cdrom. I can mount the PSX files just peachy, or at least get a directory. I have a feeling the mode 2 problems (oops I got my modes messed up) is because I'm running my DVD-R/CD-R through a virtual SCSI driver, even though the devices are IDE. The kicker is even when I do a direct /dev/hdd hexdump, the device hangs after a few sectors, leading me to believe that it's a driver issue. For some reason, however, epsxe can read the disk just fine.
I'm not much on CD-ROM authoring modes. I bearly know what a "mode" is other than the PSX uses something different than "normal" data CDs. (hense why I call the mode by the wrong name). I know red book (audio) and yellow book(mode 1). That's it. It would seem, that's all my writers support as well.
The other modes, in linux speak are these...
XA Form 1 and Green/White Book Mode 2
XA Form 2
I'm guessing these are what you are talking about, I don't think my driver supports these. (which is the same story on any CD-R drive I've owned.)
I'm going to look into cdfs for fun. That might be helpful .
On another level, I have no idea how to do all kinds of low-level stuff lin linux. My code-fu is weak.
Very weak.
The extent of my coding ability is I can somewhat use pointers in C. Use that as a gauge. In a perfect world, I would like to just use an open("filename") command to get the data and not muck about with raw device access.
I know much more about the PSX side of things. I hack via savestates and epsxe. In that case, I've never had a disk issue as the format the disk was in wasn't important. I would like to support both the PSX and PC versions. I need to be able to mount both under linux.
Why linux? It's the only OS I own.
-
I'm hell bent on no UI because managing the game outside the game can be handled by another program altogether. I'm happy simply to read the configuration from an .ini file and call it that. If someone wants to write a front-end to manage this before the program executes (ala an installer), more power to them.
Hmmm Ok not a big deal. I suppose unless you want to pause the game execution and examine things. Not sure, perhaps a UI and an Engine. The engine being the portable part and the UI being the non portable part. Not a big deal as far as I see it.
Keep in mind that the menu module in the engine is going to be tricky. The original FF7 used modules that seem to be scriptish, (the .mnu files) but I can't tell if that's native code that's banked in (most likely) or some sort of script language ala fieldscript.
I had not thought of that possibility. I had assumed the menu's were scripted and the engine did stuff from there.
Either case, the menu module was rewritten in the PC version and placed within the executable. (Which leads me to believe that the PSX .mnu files are compiled machine code banked in from the CD-ROM) At a later date we can debate if we want to hard-code the menu system or make some external TCL script thingy to make it more end-user configurable.
Or DLL's not terribly important I suppose at the moment :D
Now about mouting the PSX disks. When I put in a "normal" ide cdrom. I can mount the PSX files just peachy, or at least get a directory. I have a feeling the mode 2 problems (oops I got my modes messed up) is because I'm running my DVD-R/CD-R through a virtual SCSI driver, even though the devices are IDE. The kicker is even when I do a direct /dev/hdd hexdump, the device hangs after a few sectors, leading me to believe that it's a driver issue. For some reason, however, epsxe can read the disk just fine.
That's a bit odd unless the game only uses Mode 1 most seem to use both.
I'm going to look into cdfs for fun. That might be helpful .
All right but I've only been able to run games by using ISO cdrom plugins under linux.
The extent of my coding ability is I can somewhat use pointers in C. Use that as a gauge. In a perfect world, I would like to just use an open("filename") command to get the data and not muck about with raw device access.
Would be nice however with any PS1 data it's not pretty like that :D
I know much more about the PSX side of things. I hack via savestates and epsxe. In that case, I've never had a disk issue as the format the disk was in wasn't important. I would like to support both the PSX and PC versions. I need to be able to mount both under linux.
Why linux? It's the only OS I own.
I don't see Linux being a problem. Some thinking obviously needs to go into this though. Ignore a Jihad of personal favorite concepts is always good. However as long as there are people there will be different ways of looking at things I suppose :D
You can directly read the PS1 data from an image file under linux until something better comes up. that would be the simplest approach at the start. Actually both Win32 and Linux varients should start this way as it's rather portable to open("filename") and read the disk image. Brute Force is always the start. Things like that can be improved later.
So back to the start of things.
First order of business would be load kernal.bin?
Cyb
-
Well, It's getting late, so here's what I know about FF7's init system.
When you start the game, during the various "splash screens" (the squaresoft logo... etc) the system is actually the loading of the base kernel system and the supporting low level functions. For now let's just say that the engine is loaded, along with window.bin
A range of memory 0x10F4 bytes in length is allocated. A 256 byte scratchpad is also allocated. This is the savemap. Then file 3 of kenel.bin is uncompressed, (offset 0x063A) and placed in the savemap. This is the base structure of the map.
From here, on the psx, begin.mnu is loaded, this is (I think) the credits program. When you press "start" save.mnu is loaded in a special mode that loads and paints the buster sword and gives you the choice to have a New game or continue. When you Select "New Game", kernel.bin is opened and file 3 once again opened, uncompressed and copied to the savemap. After this file 4 (offset 0x0F7F) is uncompressed and copied at the top of the savemap to "reset" the character data. The menu system then hands over execution to the fieldscript engine and STARTMAP is executed. We then see the opening movie.
On a "Continue" The file picker is used to select a savegame. (save.mnu is still banked in and executing) Only the very head of each savegame is read for speed's sake. (Which is why the very top of the savemap is cosmetic, the only "real" data kept there is the window colors). When you select the game, CRC check is done, and the savemap is copied from the memory card to ram and the fieldmap that was saved in the savegame is executed.
That's how it all starts anyways ^_^
-
Halkun, when I was looking for something cd-related I found this:
http://www.gnu.org/software/libcdio/
That is a library for low-level cd access on Linux that maybe is some help for you. You'll need raw access to load the movie files.
If you use it through a wrapper then other people on Windows or MacOS can just plug their own code in later.
-
We don't need ANY of this crap. Why does FF7 need sockets of *any* kind. SQL? I need a OpenGL *surface* that's it. GLUT will work, but I'd like to use a gaming lib to gave me access to MIDI and stuff along with a GL surface. Something small, modular, and compact.
You're absolutely right. I realize you don't need any of that. I got carried away and went off topic, and for that I apologize.
If you like low-level, SDL is the way to go (then again, you said that was a little TOO low level.)
As for the OO thing goes: there are some cases where it's approprate, some cases where it's not. The choice is yours, here. I wouldn't try to convince you to change your mind.
Sorry I don't have more to add to this topic.
-
I would suggest using FreeGLUT or OpenGLUT to handle opening the surface, if that's what you need. They can do keys, also. They are under a the MIT license, IIRC.
To load images, I have used corona (http://corona.sourceforge.net/). It worked very well for me. Just make sure you know how to use it.
I haven't found a sound library that I liked. I was going to use OpenAL, but I couldn't get it to work with Dev-C++.
If you want to be portable, I suggest that you either not use MIDI, or use a software synthesizer. I never got MIDI working in Linux.
I also suggest C++ as a language. 3D engines greatly benefit from objects.
-
Guys, do me a favour and read this short article on bike sheds:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
And yes, it does matter for this topic. :)
-
Guys, do me a favour and read this short article on bike sheds:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING
And yes, it does matter for this topic. :)
My name is Halkun, and I approve of the above link.
-
How about this:
Do what is the easiest for you, and don't just hack something together. Make sure your code is clear by commenting and using appropriate variable names so I can understand it.
I guess your stuck using structures instead of objects, unfortunately.
Make sure you learn about things like transparency and frustum culling if you are going to make it so you can walk around. An FF7 style engine doesn't really need the culling, but you should definitely research transparency.
Another thing, you might want to peak at the code for Quake to see how Id did it.
-
Halkun:
I'll see if I can get something to work with an ISO image, I suppose ye olde CLI will be a start. I think an @<filename> setup method for testing is appropriate. We do need debugger output on STDERR as well. (IE what line was executed and what were the results).
Cyb
-
We do need debugger output on STDERR as well. (IE what line was executed and what were the results).
We could use this class (http://server.titansoft.ru/akari/logger.rar). It cross platform (It uses only standart library). It log info together with time (Maybe we need to do it optional?).
Of cource only if we deside to use C++ 8)
-
Does anyone already writing something?
-
Well I've been fighting/installing Eclipse on my Linux box.
:D
I'm also writting up a Plan Of Attack for it.
Has anyone here installed the CDT for eclipse? For some reason it's complaining about permissions. I installed it as root but I'm adding the CDT as a user. I think this is causing a few problems. Should I run and install the CDT for Eclipse SU root? (CDT is the C/C++ Eclipse plugin).
Erstwhile the plan is this.
[list=1]Read Config File
Mount Media - by this I mean locate the media image and set up to read the ISO.
proceed with Halkun's operations[/list:o]
I'm using Eclipse specifically since it's cross platform.
I have it for Windoze and Linux.
Makes things more consistant for me. Halkun it's OK you don't HAVE to have Eclipse to build the binaries of the code ;) (LOL) It creates a makefile that's all you should need.
I suppose this is the SFFVM (S_quare F_inal F_antasy Virtual Machine)
Cyb
-
This was going to be a summer project... Like when I was done with school (Almost there)
I haven't had time copy so much as Kernel.bin from my CD yet, much less write a quick a dirty zlib decompressor.
-
Too Late?
I've already got some of the ISO9660 structure done. It's just a bit of time before I finish the code to read the image and file system of the Image. I'm working to keep the whole thing working with streams this way the underlying IO is ignored and all the high level operations are all the same.
This way you can assign an ISO image file to a ISO_stream type and be able to open and read files from the image just like you would fstream. Also since the underlying IO would be an ISO image absolute reads are quite easy to handle. I might have the underlying ISO_stream etc. done by the end of the week. It takes time to carefully think these things through. I've already implemented this once, so this is my second iteration, and thus I'm using what I learned already. ISO9660 file system is NOTHING like windows. If you ever wondered why the SYSTEM file in FF7 has SCUS_941.63;1 in it well that's because the file Identifyer is SCUS_941.63;1 (not SCUS_941.63 as windows shows it). This is a translation of the file name by windows (and can be a source for problems). The ;# is the version information in ISO, I'm not sure why they elected to do that, It may have had to do with being able to add new versions of files to the CD Data.
Because the CD file system is ISO9660 things are a bit more complicated in some ways to read the CD completely on the PS1.
My 'layers' so far are thus. ISO object handles the ISO Image and File system where as ISO_stream should work just like a fstream (as it inherits istream's functionality with a different low level IO).
This fixes at the very least the ISO Issue versus mounted media. On the playstation media most of the files are readable without this. The movie files are the exception of this. So I figure one can make it fully compatible this way and less of a hassle.
I can worry about opening the kernal.bin and fetching files after this is worked out :D
How were you planing on using zlib? I'll have to look at it's interface to see how to use it. (Nary used that lib had to ADD it to compile packages before though).
Cyb
-
Wait a minute. If I have time I can post my kernel/window loader and font renderer. It shows how you can interface with zlib. I'm not sure if I can convert it to plain C tonight, though...
-
I'm not sure if I can convert it to plain C tonight, though...
I still don't get.... we are using C or C++ after all? ^^''
If I have time I can post my kernel/window loader and font renderer.
Post it =)
It really will be helpful.
-
// GLUT
#include <GLUT/glut.h>
// OpenGL
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
// System
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
// STL
#include <string>
// ZLib
#include <zlib.h>
using namespace std;
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
const char * ff7Path = "<path to your ff7 directory>";
// This is a table that contains 16-bit unicode codes for all chars in the FF7 font. (US/NTSC Version)
const u16 charMatrix[] = {
0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, 0x0028, 0x0029, 0x002a, 0x002b, 0x002c, 0x002d, 0x002e, 0x002f, 0x0030, 0x0031, 0x0032, 0x0033, 0x0034,
0x0035, 0x0036, 0x0037, 0x0038, 0x0039, 0x003a, 0x003b, 0x003c, 0x003d, 0x003e, 0x003f, 0x0040, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047, 0x0048, 0x0049,
0x004a, 0x004b, 0x004c, 0x004d, 0x004e, 0x004f, 0x0050, 0x0051, 0x0052, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057, 0x0058, 0x0059, 0x005a, 0x005b, 0x005c, 0x005d, 0x005e,
0x005f, 0x0060, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, 0x0068, 0x0069, 0x006a, 0x006b, 0x006c, 0x006d, 0x006e, 0x006f, 0x0070, 0x0071, 0x0072, 0x0073,
0x0074, 0x0075, 0x0076, 0x0077, 0x0078, 0x0079, 0x007a, 0x007b, 0x007c, 0x007d, 0x007e, 0x007f, 0x00c4, 0x00c1, 0x00c7, 0x00c9, 0x00d1, 0x00d6, 0x00dc, 0x00e1, 0x00e0,
0x00e2, 0x00e4, 0x00e3, 0x00e5, 0x00e7, 0x00e9, 0x00e8, 0x00ea, 0x00eb, 0x00ed, 0x0069, 0x00ec, 0x00ef, 0x00f1, 0x00f3, 0x00f2, 0x00f4, 0x00f6, 0x00f5, 0x00fa, 0x00f9,
0x00fb, 0x00fc, 0x0000, 0x00b0, 0x00a2, 0x00a3, 0x0000, 0x0000, 0x0000, 0x00df, 0x0000, 0x0000, 0x0000, 0x00b4, 0x00a8, 0x2260, 0x00c6, 0x00d8, 0x221e, 0x00b1, 0x2264,
0x2265, 0x00a5, 0x00b5, 0x2202, 0x03a3, 0x03a0, 0x03c0, 0x2321, 0x00aa, 0x00ba, 0x03a9, 0x00e6, 0x00f8, 0x00bf, 0x00a1, 0x00ac, 0x221a, 0x0192, 0x2248, 0x0394, 0x00ab,
0x00bb, 0x2026, 0x0000, 0x0041, 0x0041, 0x004f, 0x0152, 0x0153, 0x2013, 0x2014, 0x201c, 0x201d, 0x2018, 0x2019, 0x00f7, 0x2662, 0x00ff, 0x0178, 0x2044, 0x0000, 0x2039,
0x203a, 0x1278, 0x1279, 0x275a, 0x00b7, 0x201a, 0x201e, 0x2030, 0x00c5, 0x00ca, 0x0041, 0x0045, 0x0045, 0x0049, 0x0049, 0x0049, 0x0049, 0x004f, 0x004f, 0x0000, 0x004f,
0x0055, 0x0055, 0x0055, 0x007c, 0x02c6, 0x02dc, 0x02c9, 0x02d9, 0x02da, 0x00b8, 0x02dd, 0x02db, 0x02c7
};
u8 * ucodeToChar;
void * kernelBinData;
void * windowBinData;
GLuint fontTextures[8];
u16
get_u16le(void const * const buf)
{
return ((u8*)buf)[0] | (((u8*)buf)[1]<<8);
}
u32
get_u32le(void const * const buf)
{
return ((u8*)buf)[0] | (((u8*)buf)[1]<<8) | (((u8*)buf)[2]<<16) | (((u8*)buf)[3]<<24);
}
int
load(const string & name, void ** data)
{
size_t size = 0;
*data = NULL;
int fd = open(name.c_str(), O_RDONLY, 0);
if (fd >= 0) {
struct stat sb;
if (fstat(fd, &sb) >= 0) {
assert(sb.st_size > 0);
void *tmp = malloc(sb.st_size);
if (tmp!=NULL) {
if (read(fd, tmp, sb.st_size) == sb.st_size) {
*data = tmp;
size = sb.st_size;
} else {
free(tmp);
}
}
}
close(fd);
}
return size;
}
int
load_bingzip(const string & fileName, void ** buf)
{
// load library
u8 * buffer = NULL;
int size = load(fileName, (void**)&buffer);
// calc overall decompressed size and number of blocks
int offset = 0;
int output_size = 0;
int output_count = 0;
while (offset < size) {
int comp_size = get_u16le(buffer + offset + 0);
int uncomp_size = get_u16le(buffer + offset + 2);
offset += 6;
offset += comp_size;
output_size += uncomp_size;
output_count ++;
}
// allocate enough memory for output buffer
int bufsize = output_size + output_count * sizeof(u32);
u32 * table = (u32*)malloc(bufsize);
// decompress all blocks with zlib
z_stream s;
memset(&s, 0, sizeof(z_stream));
s.next_out = (Bytef *)(table + output_count);
s.avail_out = output_size;
s.total_out = 0;
offset = 0;
int count = 0;
int out_offset = output_count * sizeof(u32);
while (offset < size) {
table[count++] = out_offset;
int comp_size = get_u16le(buffer + offset + 0);
int uncomp_size = get_u16le(buffer + offset + 2);
int unknown = get_u16le(buffer + offset + 4);
offset += 6;
s.next_in = buffer + offset;
s.avail_in = comp_size;
s.total_in = 0;
offset += comp_size;
out_offset += uncomp_size;
// compressed/uncompressed?
inflateInit2(&s, 16 | 15);
inflate(&s, Z_FINISH);
inflateEnd(&s);
}
free(buffer);
*buf = table;
return bufsize;
}
void
build_font_textures()
{
u32 * table = static_cast<u32*>(windowBinData);
u8 * data = static_cast<u8*>(windowBinData);
glGenTextures(8, fontTextures);
u8 * fontData = data + table[1];
u32 id = get_u32le(fontData + 0);
u32 type = get_u32le(fontData + 4);
u32 clut_size = get_u16le(fontData + 16);
u32 clut_count = get_u16le(fontData + 18);
u32 pic_ofs = clut_size * clut_count * 2 + 20;
u32 width = get_u16le(fontData + pic_ofs + 8) * 4;
u32 height = get_u16le(fontData + pic_ofs + 10);
u8 * bitmap = new u8[256 * 256 * 4];
for (unsigned int i=0; i<clut_count; i++) {
u8 clut[256 * 4];
for (unsigned int j = 0; j<clut_size; j++) {
u16 col = get_u16le(fontData + 20 + (i * clut_size + j) * 2);
clut[j * 4 + 0] = (col & 31) * 255 / 31;
clut[j * 4 + 1] = ((col >> 5) & 31) * 255 / 31;
clut[j * 4 + 2] = ((col >> 10) & 31) * 255 / 31;
clut[j * 4 + 3] = (col >> 15) * 255;
}
for (unsigned int y=0; y<height; y++) {
for (unsigned int x=0; x<width; x++) {
u8 pixel = fontData[pic_ofs + 12 + y * (width / 2) + x / 2];
int index = x & 1 ? pixel >> 4 : pixel & 15;
bitmap[(y * 256 + x) * 4 + 0] = clut[index * 4 + 0];
bitmap[(y * 256 + x) * 4 + 1] = clut[index * 4 + 1];
bitmap[(y * 256 + x) * 4 + 2] = clut[index * 4 + 2];
bitmap[(y * 256 + x) * 4 + 3] = clut[index * 4 + 3];
}
}
glBindTexture(GL_TEXTURE_2D, fontTextures[i]);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB5_A1, 256, 256, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8, bitmap);
}
delete[] bitmap;
}
unsigned int
getKernelStringCount(unsigned int i)
{
u32 * table = static_cast<u32*>(kernelBinData);
u8 * data = static_cast<u8*>(kernelBinData);
u8 * base = data + table[i + 9];
return get_u16le(base) / 2;
}
void
getKernelString(unsigned int i, unsigned int j, wstring & s)
{
u32 * table = static_cast<u32*>(kernelBinData);
u8 * data = static_cast<u8*>(kernelBinData);
u8 * base = data + table[i + 9];
u8 * ptr = base + get_u16le(base + j * 2);
if (*ptr != 0xFF) {
while (*ptr != 0xFF) {
if (*ptr == 0xf9) {
// simple string compression, reference an earlier substring
ptr++;
int dist = ((*ptr) & 0x3F)+2;
int count = ((*ptr) >> 6)*2+4;
for (int k=0; (k<count) && (*(ptr-dist+k)!=0xFF); k++) {
s += charMatrix[*(ptr-dist+k)];
}
ptr++;
} else if (*ptr == 0xf8) {
// unknown escape code..
ptr++;
ptr++;
} else {
s += charMatrix[*ptr];
ptr++;
}
}
}
}
// build inverse lookup table from unicode to FF7 font index
void
build_ucode_to_char_table()
{
ucodeToChar = new u8[65536];
memset(ucodeToChar, 0, 65536);
for (unsigned int i=0; i<sizeof(charMatrix)/sizeof(charMatrix[0]); i++) {
ucodeToChar[charMatrix[i]] = i;
}
}
void
drawString(int colour, int x, int y, const wstring & text)
{
u32 * table = static_cast<u32*>(windowBinData);
u8 * data = static_cast<u8*>(windowBinData);
u8 * widthTable = data + table[2];
glBindTexture(GL_TEXTURE_2D, fontTextures[colour]);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
glBegin(GL_QUADS);
for (wstring::const_iterator i = text.begin(); i != text.end(); i++) {
u8 glyph = ucodeToChar[*i];
int gx = (glyph % 21) * 12;
int gy = (glyph / 21) * 12;
glTexCoord2i(gx, gy);
glVertex2i(x, y);
glTexCoord2i(gx, gy + 12);
glVertex2i(x, y + 12);
glTexCoord2i(gx + 12, gy + 12);
glVertex2i(x + 12, y + 12);
glTexCoord2i(gx + 12, gy);
glVertex2i(x + 12, y);
x += widthTable[glyph] & 0x0F;
}
glEnd();
}
void
ReshapeWindowFunc(int width, int height)
{
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0, width, height, 0.0, 0.0, 1.0);
}
void
MainRenderLoop(void)
{
glClearColor(0.0f, 0.0f, 1.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
drawString(0, 8, 8, L"Kernel Strings:");
for (unsigned int i=0; i<getKernelStringCount(10); i++) {
wstring text;
getKernelString(10, i, text);
drawString(i&7, 16, i*12+20, text.c_str());
}
glFlush();
}
void
SpecialHandler(int key, int x, int y)
{
}
void
KeyboardHandler(unsigned char key, int x, int y)
{
switch (key) {
case 27:
exit(0);
break;
}
}
int
main(int argc, char * argv[])
{
// glut stuff
glutInit(&argc, (char **) argv);
glutInitWindowSize(640, 480);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGBA | GLUT_DEPTH);
glutCreateWindow(argv[0]);
glutDisplayFunc(MainRenderLoop);
glutIdleFunc(MainRenderLoop);
glutReshapeFunc(ReshapeWindowFunc);
glutKeyboardFunc(KeyboardHandler);
glutSpecialFunc(SpecialHandler);
// opengl stuff
glDisable(GL_LIGHTING);
glDisable(GL_DEPTH_TEST);
glEnable(GL_CULL_FACE);
glEnable(GL_TEXTURE_2D);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.0f);
glViewport(0, 0, 640, 480);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glMatrixMode(GL_TEXTURE);
glLoadIdentity();
glScalef(1.0f/256.0f, 1.0f/256.0f, 1.0f);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0, 640, 480, 0.0, 0.0, 1.0);
load_bingzip(string(ff7Path) + "/INIT/KERNEL.BIN", &kernelBinData);
load_bingzip(string(ff7Path) + "/INIT/WINDOW.BIN", &windowBinData);
build_font_textures();
build_ucode_to_char_table();
glutMainLoop();
delete[] ucodeToChar;
return 0;
}
Features:
- loads kernel.bin and window.bin
- converts font into textures
- converts ff7 strings into unicode
- draws unicode strings with ff7 font
- expands kernel strings
TODO:
- control codes for field text
- layout of text into a window
- decide on C++ or C and convert
- split into files
- you'll have to change the path to your ff7 directory (I'm using the PSX version)
-
Ok, here's something...
I've been reading a new book called "The Pragmatic Programmer" (http://www.amazon.com/gp/product/020161622X/002-3243867-3216816?v=glance&n=283155) which tell you how to design OO programs.
Here's the thing.
It's the first book that doesn't tell me *how* to write OO programs, but *why* to write them. It explains *why* you should write accessors to classes and *why* you should have public vs pivate variables. It gives examples and compares them to other ways that are simply less elegent.
After looking at this, I think a C++ framework will be much better. I'm no good at setting up frameworks, simply because I don't know how to do it yet. But now I can at least get the concept of classes right. (Though I think they way they are expressed in C++ is still dumb)
I should be able to follow along...
-
After looking at this, I think a C++ framework will be much better. I'm no good at setting up frameworks, simply because I don't know how to do it yet.
Could you please register account on Sourceforge.net. We'll need CVS to work together.
And we need some auto documentation system (Doxygen is good http://www.doxygen.org/). It will be easier to use and expand framework if we have complete documentation on it.
-
Hmmm so you now understand it's not just some wacked out religious thing? ;)
Erstwhile I've nearly finished my ISO class for handling the images. Next will be the ISO_stream.
Cyb
-
Ok, here's something...
I've been reading a new book called "The Pragmatic Programmer" (http://www.amazon.com/gp/product/020161622X/002-3243867-3216816?v=glance&n=283155) which tell you how to design OO programs.
Here's the thing.
It's the first book that doesn't tell me *how* to write OO programs, but *why* to write them. It explains *why* you should write accessors to classes and *why* you should have public vs pivate variables. It gives examples and compares them to other ways that are simply less elegent.
After looking at this, I think a C++ framework will be much better. I'm no good at setting up frameworks, simply because I don't know how to do it yet. But now I can at least get the concept of classes right. (Though I think they way they are expressed in C++ is still dumb)
I should be able to follow along...
I was a very strong supporter of C, but then things like STL (and especially std::string) won me over to C++.
But you'll actually have to start coding and improving yourself over time. And you'll have to spend time reading books (Design Patterns, Large Scale C++ Development, Effective C++...) and apply them to your own projects. It is nothing you can learn and then apply immediately, and I have seen absolutely terrible designs from C++ newbies... Use what you're most comfortable with.
-
Erstwhile I've nearly finished my ISO class for handling the images. Next will be the ISO_stream.
I'm working on Savemap. It's awfully big, so it will take a while =)
We need only one savemap in the game I believe?
-
That one savemap is the global variable holder, that's why I was so leary of C++. Globals are a no-no, but it's needed as it's the basis for most critical varible management in FF7.
=======
I have a sourceforge account. Give me a bit to fill it out.
-
I updated the loading/font rendering code on the previous page. That fixes the winding order of the quads for the glyphs, creates textures with an alpha channel and has some minor tweaks to the code.
Let me know if anyone gets it to work or has any problems. You'll most likely want to change the OpenGL and GLUT includes (to GL/gl.h, GL/glu.h and glut/glut.h), and change the path to your FF7 directory. Oh, and I'm using the PSX version.
I imagine you just want to use it as a guideline, but feel free to rip out whatever you need.
-
All right I've hit the first 'win32' versus POSIX issue.
FindFirst FindNext FindClose are used by Windows.
whereas POSIX uses opendir closedir readdir telldir seekdir. There is no glob function that I can recall (IE you do your own file matching in this case) in POSIX.
Suggestions anyone? I could use scandir but that's a BSDism. However this is the same as 'doing your own file matching".
Why am I asking this? Well we want to access things the same weather it's an ISO image or CD. :D
Has anyone found any real file references in the script?
There are some file references in the executable. These appear to be \MINT\DISKINFO.CNF;1 and \MINT\MOVIE_ID.BIN;1
These I suspect are just to be certain what disk is in the drive and get an absolute index for a movie. (MOVIE_ID.BIN has 5 UINT32 numbers per movie that appear to have sector and length information in them). Although it's possible that DISKINFO.CNF may have the FF7 engine boot information (IE kernal loading etc.) The only thing I can find is "DISK0001<cr><lf>" and "FinalFantasy7 Disk1<cr><lf>" The rest of the data is an enigma too me ;)
I can't seem to find Min:Sec:Frame indexs however either :/
Cyb
-
Has anyone found any real file references in the script?
Looking at the fieldscript, I'm afraid we are going to have to make a lookup table for them. The JUMPMAP command only refrenced field files by numbers.
MOVIE also only refrenced files by number, so it's kind of critical you have the correct disk in the drive when the fieldscript executes the movie or else the wrong movie plays.
Doing in-memory fieldscript hacking while the game is running will allow us to enumerate the files. (change the JUMPMAP number and look in the menu to see where you landed after the new file loads, the trick is linking that to what fieldscript we are in, but that can probably be done by looking at fieldscript dumps)
As for movie variables, there is a movie player in the debug rooms
Also, I'm leary of ISO reading unless we absolutly have to. For linux it's becuase some drives simply can't read the disk at all. Is there a reason why Windows needs the fuctionality? Can't they read the files fine? (With the exclution of reading the movie and sound files?)
-
Has anyone found any real file references in the script?
Looking at the fieldscript, I'm afraid we are going to have to make a lookup table for them. The JUMPMAP command only refrenced field files by numbers.
MOVIE also only refrenced files by number, so it's kind of critical you have the correct disk in the drive when the fieldscript executes the movie or else the wrong movie plays.
Doing in-memory fieldscript hacking while the game is running will allow us to enumerate the files. (change the JUMPMAP number and look in the menu to see where you landed after the new file loads, the trick is linking that to what fieldscript we are in, but that can probably be done by looking at fieldscript dumps)
Oh.. hmmm I wonder where the silly table is.. I think the DISKINFO.CNF;1 file might be the 'big' index (Index of indexs!). I suppose I need to make an ISO disk image map viewer (more stuff to do).
As for movie variables, there is a movie player in the debug rooms
Also, I'm leary of ISO reading unless we absolutly have to. For linux it's becuase some drives simply can't read the disk at all. Is there a reason why Windows needs the fuctionality? Can't they read the files fine? (With the exclution of reading the movie and sound files?)
With some low level IO manipulation yes it can be. This is the problem. Essentially in order to read the entire sector you have to by pass the normal windows VXD drivers. This also happens to be drive specific. In simple terms it's the most common problem with playing movies on playstation games.
-
For the record, Memory Hacking Software (http://www.memoryhacking.com/) comes with a FileWatcher plug-in that allows you to monitor all file activity in the target process.
You can set it to stop Final Fantasy VII when it loads any file or part of a file and step through with the debugger to see how the code is using the file, or, for your current purposes, how it came to load the file (the mythical “tableâ€).
It also shows you every file that is opened, how they are opened (flags), when they are read, when bytes are written to them, and when they are closed.
Speaking of which, all of you can use this to watch how it opens files and decodes them.
We can decode all unfinished file formats this way…
It also comes with source so you can modify it how you please.
L. Spiro
-
Since this is a form of emulation, I thought I'd pop the question.
Has there been any thought to being able to replace the in-game models/textures/animation with user created models/textures/animations? I'm an artist, not a programmer, but I've taken a couple of programming courses and can think a bit in that way.
I'm not sure how ff7 currently calls the model and texture, but if there were a way that a text file can be used to tell the game to substitute and render a different model with textures and animation for a particular model.
I'm just thinking that this would allow us artists to create better work that can make the game more enjoyable to play.
Cheers!
-
As far as I know the idea is to first make it run the current content.
New content is perhaps another day. You can't build something like this in a few days weeks months.. it's a long term project. I'm sure eventually things may get to that point.
Cyb
-
also, this isn't emulation. It's a re-coding of the original engine.
-
Pretty much the same thing, just that the emulation is specifically targeted towards a particular game.
-
Pretty much the same thing, just that the emulation is specifically targeted towards a particular game.
I suggest looking here (http://www.scummvm.org/) since it's more like that. It's not emulation since emulation takes the original media and system and creates a software variant.
-
I'm just going off some stuff I read on wikipedia.
http://en.wikipedia.org/wiki/Emulation#See_also
-
Finished first version of Savemap struct and GameState class that incapsulate Savemap.
http://server.titansoft.ru/akari/gamestate.zip
There are a lot of mistakes in Wiki and Gears in description of Savemap. Anyway I tested beginning of it and very end - it works correctly. The middle part are just array for time being. I dont think it makes matter now.
Next I create method to initialize Savemap from Kernel.
Is some file system already created? Or I will use standart C functions?
-
Give me a bit to fill it out.
Here it is. http://server.titansoft.ru/akari/engine_ffvii.rar
It still does nothing. But it initialize SDL window and load gamestate with savemap. =)
ps: It has config and logger too. Give me some time to inplement basic OGL render and SDL input handler.
-
I'm setting up CVS now, this way devoplers can commit directly into the repository, I'll have to ok the commits
-
I'm double-posting, I know but there is a reason. I want to tie up the thread and close this. It seems that the "engine fantasy" has indeed become an "engine fact" and there are the begnnings of code.
I want to move discussion of engine development off to SourceForge project page (http://sourceforge.net/projects/q-gears/). It's a really complex subject, and there are forums just for Q-gears there (http://sourceforge.net/forum/?group_id=165417). All deveopers should be on the same page, and SourceForge is a good page to start.
Now, before I lock this, I want to go though a really quick rundown of what's going on. This is all a bit by the seat of my pants, so if it's a little hodge-podge that's just me flapping my admin wings a little harder than usual.
*Akari*
Your need to fix some things in your code before I can put it into CVS on sourceforge. First of all CVS can't do binary data without jumping through all kinds of hoops. This means no object files and no savemap images. Sample savegames and savemap images can be put up on Q-Gears's homepage (http://q-gears.sourceforge.net/), which is currently blank. (Actually, you can download Gears PDF (http://q-gears.sourceforge.net/gears.pdf) from there, but that's it for now.)
I will suggest that savemaps default to the debug room for now.
Also CVS is CaSeSeNsItIve. You need to make sure that your source files have all lowercase letters. It would also be nice to place a CVS ID header in your files to auto-generate version information on check-out.
YOU ARE IN LUCK!
Because open-source is so cool, you can download entire books on how things work for free. To better understand what CVS is, I will suggest reading this online e-bookOpen Source Development with CVS, 3rd Edition (http://cvsbook.red-bean.com/cvsbook.html) It will give you more than enough information.
Also one last thing, I need future deveopers to get a sourceforge account, and to give me their username for sourceforge, so I can add them to the deveoper list. This way you can have CVS write ability, and be able to place your own code into the repository.
*anyone else*
If anyone wants, I can use a webmaster to help pull togeather a homepage for the project. You see, I really can't do anything ^_^ I'm afraid I've fooled you all into thinking I have some sort of "talent" or "coding ability", or heaven forbid, "leadership skills!" My 200 page Gears document aside, I only have the ability to tear things apart and make crap up ^_^.
But in the end, lets see if we can make something.
Let's see, did I forget anything? I'll be keeping this thread open for a day to make sure I didn't forget anything. After that deveopment disscussion should be moved to sourceforge.