[Alephmodular-devel] General status overview
Status: Pre-Alpha
Brought to you by:
brefin
From: Br'fin <br...@ma...> - 2003-01-03 04:16:11
|
0.3 STATUS I've cleaned up the variables to have a platform neutral length. I've worked through to squash warnings. While I haven't done anything major with Mallocs or Enums, those are still potentials. But I'm still waffling on necessity. Mallocs are apt to fall by the way side in the course of shifting everything to classes. If there is anything memory wise to worry about at the moment it would be the mix of Mac Memory handling (NewPtr, NewHandle), and the more neutral C/C++ style memories (malloc, new). Enums of the sort I would be targeting are also firmly in the realm of the 'Bio' stuff we've been talking about. So typedef'ing them now could just work out to being premature. I've been doing some thinking, and while I'm not sure what other things should go into 0.3, I have come up with an issue that should be worked into the system now. alephversion.h and config.h under the auspices of autoconf and a configure/configure.in. Yes even for using Project Builder this would work out to cvs co alephModular cd alephModular ./configure open build/macosx/AlephModular.pbproj (or double click on the project :) ) Especially considering that configure should be able to use AlephModular.pbproj/project.pbxproj.in to feed the version information set during configuring into PB's build process. Now does anyone have experience or links on setting up the necessary files for autoconf? Especially since I don't currently have a makefile proper. 0.4 PLANNING _High Level Modules_ We still need some clarity here. GUI seems obvious. Though certain elements are far more obvious than others. 'Bios' is definitely there, but it's much harder to determine where the barrier is between Bios and other functions. For instance, monster definitions are unquestionably within the Bios, but is monster AI within the Bios? Is Monster pathfinding? where's the extent of monster behavior flags? What else do we want here guys? Conceptually? Actually? Game Core? Animation? Rendering? Where does unifying saving/restoring game information lay? Where does the various information and strings currently stored in marathon2.rsrc go? _Process_ I'm finding myself leaning more and more towards Chris Bergmann's suggestion of first trying to transition the current structures into classes. Should we have a sub 0.4 milestone for full classification or make that 0.4 and push out the high level modules to 0.5? Other comments on Milestone planning? At any rate, folks should not be surprised that I want a slow and progressive transitioning of things. I find myself very leery about big changes. (This has been most notable recently in the GUI discussions. I like the basic argument for the one GUI, but I'm not ready to commit to it without it having proven itself first) -Jeremy Parsons --------------------- +------------------------------------------------------ Br'fin | TIMSter, MU*er, Web Programmer, ... Insane? The Denim Warrior | You be the judge... br...@ma... | --------------------- +------------------------------------------------------ |