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[O], 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?