Ok, I have this sudden urge to code. For the last few days I've been pouring over Gears and looking at what I have as far as Kernel/menu and think I have enough to build a frame work of a new engine.
Speaking of legal matters, what would be the legal status of actually coding something like that? A lot of the information in Gears comes from reverse-engineering and such, and even though it enjoys legal protection in many countries, it's still a bit of a gray area, no?
I have been blatently ignoreing the fieldscript opcodes.
Well I haven't. In the process of decoding the instructions I'm pretty much ending up writing a framework for a script enging just to "get a view of the entire puzzle". Oh yeah, that thing I promised you is still work in progress.
However, my coding sucks, and I only know one API, which is Allegro. There is a GL extention(AllegroGL), which in this case, the Allegro part replaces GLUT. I find SDL way too weak for what I want. I've always found it a little too "low level" for me.
Me being me, I'd advise against using a premade high-level library. Better to write your own on top of OpenGL or something. Nothing is more frustrating than having things not work properly because some unknown (possibly even unaccessible) piece of code deep inside a library written by someone else isn't working like you think.
-Good Things-
AllegroGL is cross platfrom, which is great as I run linux.
I'm good with the Allegro part.
A custom OpenGL-based library would be near cross-platform too, and things like window creation, input handling, sound etc. could and should be modularized for that very purpose. You would have to write these things to some extent anyway since no library would give you exactly what you need.
-Bad Things-
I can only code in C, and lothe OO programming execpt in some very special cases. Sadly, the orignal FF7 was done in C++ and I can't use it's code structure as a template.
Heh, I don't loathe OO programming itself, though I dislike how things like virtual functions (what the wonderkids call "the point" of OO) create hidden bottlenecks you can't affect. Personally I see OO as a way to create nice code, and thanks to C++'s C inheritance I can more often than not write code that is as efficient as pure C but incredibly more easy to read and debug. C is great for low-level, and in combination with inline assembler it gives you perfect control, but it is sorely lacking in structure; or rather, you can certainly create well-structured programs but mostly at the expense of code readability.
I'd strongly recommend having a look at some of the more basic C++ concepts. If only for the increased code structure, which helps immensely in larger-scale projects. And let's not forget my favorite, operator overloading. The perfect union of highly custom data types and sensible code. Stuff away the nasty bits of code in a secure place and never risk fucking up the implementation part from your actual program code. But enough C++ advertising.
I've been known to do things with pointers that's probably against the law in 37 states. What I would simply call an "Misallocated pointer" could be misconstrued as a capital offence in some countries.
I'd love to hear your stories.
What, by the way, is a "misallocated pointer"?
I have a very weak idea of how to use filesystems in C, but we all have to learn, right?
Well since all the library calls get translated into the appropriate system calls, I guess it doesn't matter which library you use. For the FF7 engine I guess you'd rarely need more than simple fopen calls, but file structures are really ideally handled by some simple classes. One for normal files, built-in compression handlers, one for LGP encapsulation... well, learning is of course essential in any case. I'm just mumbling incoherently now, it seems.
I'm really attached to C, the fact that the savemap is a huge global resource make me dance with joy. I adore globals, and I know C++ hates them. However, if I was to make the Kernel in C and allow modules to be called, could a C program call a module written in C++ and return in a sane manner?
Well a global is really just a weak implementation of the singleton pattern. Only problem with globals (in any case) is the nasty amount of attention you have to spend to specify where they're allocated. But wrap it up in a simple class with static members and suddenly the C++ guys think it looks better too... Anyways, C++ and C are mostly compatible with a few exceptions; calling conventions (works OK by default), name mangling (hence the need for extern "C" for inter-module calls) and exception handling (which can of course be done using more platform-specific methods, but for portability's sake should be kept to standard forms or not at all. It is quite useful though, especially for writing kernel-like applications). So you have to mind a few things when mixing the two, but generally it's no problem. Without exception handling you really only need the extern "C" to be sure, everything else should work fine.
Should I just document fieldscript?
I could easily start putting together a "real" field script engine, but without a game around it it would merely be a hypothetical machine with very limited use (just a way to test if I got the semantics if certain op-codes right by executing a field script where they occur). I know enough of the FF7 interpreter to implement the basics. The FF7 interpreter is, by the way, flawed in many respects and relies heavily on the discipline of the script writer/compiler to prevent things like control flow jumps and request from being simply lost, resulting in lock-ups. I already have a half-working alpha version of a FF7 script compiler, though I obviously had to invent much of the "uncompiled" language myself.
