Re: [Alephmodular-devel] TS Draft: File abstraction

[Br'fin <br...@ma...>]

On Monday, January 27, 2003, at 12:02  PM, Woody Zenfell, III wrote:
>
> 2.  Just a reminder that there ought to be a way to enumerate the 
> entries (probably optionally matching a type) in a directory.  (This 
> probably will be later fleshed out in the "stub interface for now" for 
> directory desc's.)

Yeah, I skimmed over that. I accept that there should be a way to 
interface with directories, But since my focus has been on the files I 
rather blanked on what functions we need from a directory.


> 3.  Should the Unknown file type really never match anything, 
> including Unknown file type?  I understand the reasoning - if you 
> can't tell what type it is, you surely can't tell whether it's the 
> same as some other type you don't recognize - but I could see it being 
> useful in certain circumstances to be able to, say, enumerate all the 
> files in a directory that *aren't* recognized as some other type.  
> Maybe this uses a special enumeration call rather than the Unknown 
> type designator, etc.  Shrug.

By matches I was referring to the way we try to determine type from 
CFileSystemDesc. The is_a check should still say 'Yes we have an 
unknown file type.' Initially we get a file desc but have no clue what 
it is. So we loop through our type tests. All of our type tests fail so 
we give up and give the description the CUnknownType.


> 4.  Perhaps there should be a distinction drawn in the interface 
> between "looks like" a type (quick to determine from extension/Type 
> Code/etc.) and "really is" a type (requires examining the file 
> contents to be sure).  I know you proposed a 'toggle', which might 
> work out, but having this explicitly exposed in the interface will 
> make programmers think a little more about what they're really working 
> with (which may be particularly good for files that Look Like, say, 
> Shapes or something, but Really Are, like, umm, a film file).

My assumption with the toggle and all was that this toggle would be 
pretty much encapsulated in the type checking facility. Then again my 
reasoning is 'if it claims to be a shapes file (shp2) treat it as such, 
and of course report 'bad shapes file' if it betrays us by being a 
film' and the full out peek into the file check was for cases where the 
first checks fail. We have a random file 'foo', no type, no extension. 
Is it anything we think we recognize?


> 5.  Should types be hierarchical?  (Is this already implicit in your 
> design?  sorry...)  That is, I mean you talked about a general "Shapes 
> file" identifier that encompasses several specific Shapes-file 
> representations I think, but I got the impression there was a strict 
> two-level hierarchy there, probably with the general identifiers and 
> the specific identifiers in two separate matching spaces.  Instead, 
> should there be a more general, potentially multi-level matching 
> mechanism that's a bit like, perhaps, class inheritance?  So one can 
> ask for things matching some more general type and get things of 
> various specific types that are subtypes of the general type?

I think I brought up the concept of hierarchy, but brushed over it 
poorly. But I was thinking along those lines. You have specific file 
types for M1 Map, M2 Map, Minf Map, etc. But if all you care about is 
that it's a Map file, then you'd be set by specifying the Map type that 
all those other map types inherit from.


> Of course hmm kind of harkening back to some of my earlier notes in 
> this regard, I'd advocate hiding the distinction between a Shapes file 
> and a Sounds file etc. as much as possible, and treating all such 
> files simply as 'archives of objects'.  An m2-format Shapes file 
> happens to provide only objects of type M2 High-Level Shape, M2 
> Low-Level Shape, M2 Bitmap, M2 CLUT, etc. (whatever's in there), but 
> in the future potentially some single new-format archive file could 
> contain Shapes information, levels, terminals, etc. all together.  
> This means that instead of caring about what type a file *is* (except 
> for finding the appropriate file-decoder to use), we care about what 
> kinds of objects (and there could be many, per file) a file > *provides*.

My own thought, and this is, alas, very general at the moment. Is to 
aim for a bundle type of structure. A folder with a well defined 
location for scenario information. (Required Bio, descriptions of other 
resources needed or provided)

The Environment preferences wouldn't go away, but would be overhauled.

Something along the lines of Choose Scenario (With options like Custom, 
---, M1, M2, Minf, Devil in a Blue Dress) With a the custom option 
being a pane similar to the current one: Choose Bio, physics, shapes, 
sounds, map.

This isn't exactly an uber-file though and many of the subcomponents 
can be handled with the existing file readers.

> So, if we play an M2 Level, it refers (thanks to the M2 Level Unpacker 
> object) to the monster type M2 Trooper, which the engine finds in a 
> 'bio' somewhere (possibly compiled-in, possibly not).  The bio 
> (right?) refers to the M2 Trooper Shape information etc., which the 
> engine locates one way or another in some M2-format Shapes file.  The 
> user chooses only the level (possibly implicitly, by starting to play 
> a scenario, or by linkage from another level); the level determines 
> the Bio; the Bio determines the other objects needed.  The user never 
> deals with any of this "Environment" nonsense (though there ought to 
> be a mechanism for optionally explicitly overriding one thing with 
> another, so that the user can choose to play M1's Waldo World Arena 
> with all M1 standard stuff but using his own "Jetpack" physics model 
> instead of the normal M1 physics model - or M1 Waldo World Arena with 
> M1 weapons and wall textures etc. etc. but with all major Pfhor 
> replaced with Moo Hunters, or whatever... this latter would probably 
> require some sort of configuration file be created and specified; I 
> wouldn't expect to be able to set up a situation this complex in the 
> game's UI).  Note that this approach allows for future (significant!) 
> expandability/flexibility without compromising support for existing 
> files as-is.

I agree that we want to hit this kind of target functionality. Unsure 
on the full flexibility with respect to the scenario with the 
configuration file. Though if we do allow multiple shapes files (either 
adding to or overlaying aspects of an existing one) then yes, that 
seems better controlled in the scenario setup file.


> The M2 Shapes loader (etc.) could be told what names to use for the 
> objects it finds by an additional external naming file.  This way 
> existing scenarios could use their standard data files as-is, but 
> could provide differently-named objects by way of these drop-in add-on 
> files.  (Perhaps these naming files could specify which files they 
> apply to by checksum etc. so that there could be a standard 
> distribution of them, covering all existing scenarios that folks have 
> bothered to create naming information for - but without of course 
> requiring that the user actually *have* all the scenarios already.  
> This way users can download and use existing scenarios - in their 
> existing distributions - but AM can still benefit from the generalized 
> referencing.)

I'm not quite following this, I fear.


> Yeah I'm going to keep advocating this 'runtime dynamic linking of 
> game objects' model because I feel strongly that it's The Right One.  
> :)  At least, until it's sufficiently refuted or a stalemate appears 
> (as in the SDL-as-baseline-platform debate).

Currently I'm mixed. Like in the rendering engine. Is it better to 
support drawing multiple forms of shapes at draw time or would it be 
better to pick one format, work with that and reconvert any other 
shapes on at load time for compatibility?

Most explicitly, we pick M2 shapes as the way a sprite should be 
encoded. Hence, when working with M1 shapes, we need to read the M1 
shape in then convert it, in memory, to the M2 shape structure before 
we continue loading the level.


Other areas, like children of Monster that manage monster AI in the 
game, I definitely agree with having dynamic runtime classes.


> While we're at it, should we talk about the possibility of keeping 
> some sort of table of properties about files?  Like a quick index of 
> what we've determined various files to Really Be, a unique identifier 
> for the file contents a la the 'checksum's role in Bungie's 
> formulation, to locate the correct file (for film playback, netgame, 
> etc.) even if its name has changed, what objects the file provides, 
> etc.?  Ehh, probably not, these operations are probably used 
> infrequently enough that it's not worth keeping a separate table.
>
> Well hmm I mean, I had pictured storing this table on disk, which is 
> probably a bit unnecessary, but OTOH caching/memoizing the results of 
> operations like Really Is in memory (during a single run of the 
> application) may be appropriate...?  Not that this has to be addressed 
> now of course, just thought I'd mention it before it left my brain 
> again.
>
I could see going with some kind of in memory list of properties about 
files. I haven't really decided, but there is room for this, especially 
with my edict about CFileSystemSpecs... to navigate you don't edit an 
existing one in place, instead you use it to navigate to a newly 
allocated one. Right now things are just being ditched instead of being 
stored, though.

-Jeremy Parsons