Re: [Alephmodular-devel] General status overview

[Mark L. <hav...@ma...>]

> 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).

Handles are (should be) only be used by the MacOS/Carbon APIs, and so 
should eventually move to within the Mac-specific code blocks.

> 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?

Having anything more than flat data in a bio would be a) a ton of work 
b) better suited by biting the bullet and declaring that we intend to 
implement some sort of scripting language (which we probably will at 
some point, but it shouldn't be an initial goal). So IMO a bio should 
contain little more than the union of the default physics model and the 
app resource fork already does.

> What else do we want here guys? Conceptually? Actually? Game Core? 
> Animation? Rendering?

-High-level rendering (software, GL, whatever else comes along). This 
part is concerned mostly with the mechanics of drawing to the screen a 
subset of the world that has already been selected and configured as 
much as possible by the low-level renderer.

-Low-level rendering. This is where the scene graph storage, visible 
set determination, etc live. (Possibly this sort of divide is too 
ambitious, in which case just "rendering"). If the pipeline between the 
game state and the high-level renderer can be sufficiently modularized, 
it will be much easier to add new types of world data and/or rendering 
methods.

-World physics, including monster AI.

-Resource loading which would cover all game data stored on disk. This 
would be more of a logical division than an architectural one, but 
everything relating to disk I/O and file formats and so on should be 
encapsulated somehow.

-Preferences, which would have 3 tasks: Manage the prefs file on disk, 
display the preferences dialog with platform-specific methods, and 
expose the user's selections to the rest of the engine in a 
platform-agnostic manner. (On a related note, A1's preferences are 
hideously complex and overdesigned... Does the user really need to be 
able to configure the type of texture filtering used?)

-Input manager, if only because this task is unavoidably 
platform-specific and there has to be a line drawn somewhere.

Probably more I've forgotten...

--Mark

"...and now if you'll excuse me it's time for my daily massacre!"