alephmodular-devel — AlephModular Developers Mailing List

[Alephmodular-devel] Re: Questions...

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

On Monday, February 17, 2003, at 01:22  AM, Loren Petrich wrote:
>
> 	I note in passing that OSX's 256-color rendering is rather screwy -- 
> graphics intended to have the current palette are OK, but the other 
> graphics look rather grotesquely dithered.
>
I don't think OSX has the same concept of a 256 color system Palette 
that we're used to.  I honestly don't know *how* to setup the color 
palette in OSX. The original Marathon code was doing low level sets 
which I just couldn't do within Carbon. :/

The stuff that animates the clut for thousands of colors and up seems 
massively inappropriate at 256 colors. Erf >.<

-Jeremy Parsons

[Alephmodular-devel] Map Editing and Liquids

[Kevin W. <lu...@ea...>]

I was doing some work on my scenario that I sorta started a while back=20=

(to be released Not-Soon=99-At-All, probably: it's a Mario conversion),=20=

and I decided to flesh out exactly what I'd need to make it.  Most of=20
the stuff is actually possible with workarounds, but they're clunky,=20
bulky, and not so great.

So, here's the "Stuff that's really good for me, and would be difficult=20=

to do without":
  1) Bridges and Balconies (workaround possible - but very ugly)
  2) Good, solid Networking
  3) Ability to use different liquids within a single map (otherwise=20
ugly workaround)
The rest isn't quite essential, but would be nice:
  4) Jumping (I've thought of a workaround, but it makes all weapons=20
single-firing mode only, and would be pretty ugly)
  5) Ability to set the damage of liquids from within the map/physics=20
model, without having to resort to Fux!
  6) Ability to set certain weapons to use up more than a single clip on=20=

reload (I'm thinking of having a near-universal ammo type)
  7) Ability to set certain projectiles to slide along the ground=20
instead of bouncing or exploding (pretty simple workaround, though it=20
necessitates the End-of-Life to come from a timer instead of being=20
dependent on the shot)
  8) Projectiles that bounce off of walls, or ceilings
  9) 3D models instead of sprites (not necessary at all, though could be=20=

cool)

I submit this list to the AM dev-list simply because I think that AM=20
has more potential than A1 for most of these features.  If these sorts=20=

of things can make it in sometime during development/with modules, I'll=20=

be one happy camper.

All the best,
-Lunair=

[Alephmodular-devel] Random display design foo

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

I'm trying to state what the display abstraction should be doing right 
now. So I toss out my initial notes.

Most likely, progression would work like I did for files. Work up the 
buffer abstraction first, get that in the from the current APIs, then 
expand usage of things before finally swapping all the display stuff 
over to new code.

-Jeremy Parsons

$Id: ... $

Note: This document is still evolving. But is being used to guide the 
process
and is being updated to reflect final code.

Technical Specification: Display Hardware Abstraction

First there was screen.h. But it had some drawbacks and limitations.  A 
mild macintosh bias in soem of the interfaces (Which is probably 
stronger in the functions that provide buffers to be drawn upon) But 
the primary problems relate to legacy.

Also, screen is reponsible for viewport effects as well. We do not wish 
to handle these, but the lower level display abstractions.

Older computers rarely had a screen bigger than 640x480 and Marathon 
itself, while it was geared to also run on slower machines, didn't have 
anything in mind for addressing way faster machines. Way larger screen 
estate. Nor did it ever expect windows to offer their own back buffer 
support.

We need to offer a CDisplay class that performs the following:
Manages either a window or fullscreen as a legitimate display target.
Manages corresponding buffers that are passed to code to draw upon
Manages screen based effects, including fades and pallets

A note on buffers:

Existing code assumes that it will always be dealing with an 
appropriately sized buffer. So Low Res mode will be drawing in a teeny 
display buffer, and if you're playing 640x480 with a HUD, then the 
buffer will be 640x(480-HUD height) And things like the interface 
tended to be drawn directly to the screen window.

We are going to need the ability to pass code a larger than expected 
buffer with appropriate offsets and limits such that the rendering code 
will only use a portion of it.

Re: [Alephmodular-devel] CFileDesc landed

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

On Wednesday, February 12, 2003, at 06:45  PM, Br'fin wrote:
>>> Ah, I didn't realize that that processing was a feature of AlephOne 
>>> specifically. I'll have to look into it. Does A1 deal with a 
>>> MacBinary of a map file too? Or does that still need to be 
>>> explicitly split out into two files?
>>
>> It looks like (though I have not tested this myself) that it should 
>> indeed be able to read both forks from the single MacBinary file, no 
>> need to split.
[snip]
> That's just cute. Insanely cute :)
>
> Hsm. I'm not sure how on earth I would do that with iostreams. I mean, 
> I know how I might do it, but I honestly have no idea as to whether I 
> can do it that way, I don't know which kinds of methods I can override 
> safely. Durn C++.
>

Pester some folks on the newsgroups, and I think I understand what I 
would need to do on my end now.

-Jeremy Parsons

Newsgroups: comp.lang.c++
Subject: Re: Limiting an ifstream to part of a file?
Simon Turner wrote:

Br'fin wrote:
 >  "White Wolf" wrote:
 >
 > > "Br'fin" wrote:
 > > > I'm trying to find a safe way to open an ifstream or equivalent
 > > > subclass, but set it up to that it is limited to only a portion 
of a
 > > > file.
 > > >
<snip>
 > >
 > > IMHO you will need to make a custom stream buffer to achieve that.
 > >
 > > WW
 >
 > Offhand, subclassing filebuf looks straightforward. As would
 > interfering with its seek and other methods to treat the artificial
 > bounds limits as actual ones.
 >
 > But I'm having trouble understanding how I would use this subclass
 > with an ifstream.

You can create an ifstream to use with your custom streambuf by
passing a pointer to the constructor, like:

   my_restricted_filebuf mf( "file.ext" );
   std::ifstream restricted_file( &mf );

If you have an existing ifstream you want to redirect to your custom
streambuf, you can use:

   my_file.rdbuf( &mf );

 >
 > It seems like I would need to ditch ifstream and use the
 > basic_ifstream code as a sample or nearly verbatim for writing my
 > own istream subclass

Fortunately not, although you need to take care of the streambuf's
lifetime if you do it this way.

 > :/

PS.I just looked this up in my copy of "The C++ Standard Library", by
Nicolai Josuttis. If you're doing a lot of tricky iostreams work, it
might be time to go shopping.
;-D

 >
 > -Jeremy Parsons

Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

Yeah Timothy, this is just for backwards-compatibility with existing 
files.  (But still, it has to be handled somehow, in a 
cross-platform-friendly way... which is what the current discussion is 
about.)  Any new AM file formats will be single-forked; I don't think 
there's any disagreement on that.

Woody


On Wednesday, February 12, 2003, at 09:33  PM, Timothy Collett wrote:

>>> Resource fork: look in resource_manager.cpp for the 
>>> resource-fork-parsing routines... see e.g. around line 124, in 
>>> res_file_t::read_map() (which reads a resource-fork-map, not a Map 
>>> file :) ).  (Since my resource forks are in files on my Windows 
>>> machine, and I can play... well this code seems to work.)
>>>
>>> Data fork: look in FileHandler_SDL.cpp, e.g. line 363 
>>> FileSpecifier::Open().
>>
>> That's just cute. Insanely cute :)
>>
>> Hsm. I'm not sure how on earth I would do that with iostreams. I mean, 
>> I know how I might do it, but I honestly have no idea as to whether I 
>> can do it that way, I don't know which kinds of methods I can override 
>> safely. Durn C++.
>
> OK, I know I don't know much about the code, and I know I already 
> griped about resource files, and I know that I'm not entirely sure what 
> you're talking about.  But.  If this is simply for legacy file formats, 
> well and good; we should support those, and you can ignore the rest of 
> my email as meaningless drivel :-).  But if this is for a more future 
> kind of thing, shouldn't we be avoiding resource forks?  Seems to me we 
> should have a fully cross-platform way of making files that doesn't 
> rely on anything that has now completely been dropped by its creator 
> (Apple).
>
> Again, if I'm simply being dense and repetitive, then please ignore me.
>
> Timothy Collett

Re: [Alephmodular-devel] CFileDesc landed

[Timothy C. <tco...@ha...>]

>> Resource fork: look in resource_manager.cpp for the=20
>> resource-fork-parsing routines... see e.g. around line 124, in=20
>> res_file_t::read_map() (which reads a resource-fork-map, not a Map=20
>> file :) ).  (Since my resource forks are in files on my Windows=20
>> machine, and I can play... well this code seems to work.)
>>
>> Data fork: look in FileHandler_SDL.cpp, e.g. line 363=20
>> FileSpecifier::Open().
>
> That's just cute. Insanely cute :)
>
> Hsm. I'm not sure how on earth I would do that with iostreams. I mean,=20=

> I know how I might do it, but I honestly have no idea as to whether I=20=

> can do it that way, I don't know which kinds of methods I can override=20=

> safely. Durn C++.

OK, I know I don't know much about the code, and I know I already=20
griped about resource files, and I know that I'm not entirely sure what=20=

you're talking about.  But.  If this is simply for legacy file formats,=20=

well and good; we should support those, and you can ignore the rest of=20=

my email as meaningless drivel :-).  But if this is for a more future=20
kind of thing, shouldn't we be avoiding resource forks?  Seems to me we=20=

should have a fully cross-platform way of making files that doesn't=20
rely on anything that has now completely been dropped by its creator=20
(Apple).

Again, if I'm simply being dense and repetitive, then please ignore me.

Timothy Collett

"99 times out of 100, a hero is someone who's hungry enough and cold=20
enough and tired enough not to give a damn.  I don't give a damn!"
=97Hawkeye Pierce, _M*A*S*H_=

Re: [Alephmodular-devel] CFileDesc landed

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

On Wednesday, February 12, 2003, at 11:55  AM, Woody Zenfell, III wrote:

> On Wednesday, February 12, 2003, at 06:13  AM, Br'fin wrote:
>
>> It's doable to setup something that has an innerclass that changes 
>> when it hits that point, but seems somehow... annoying.
>
> Right, this is what I was picturing.  Maybe feels annoying in the 
> implementation half, but then you have a clean consistent interface 
> from the outside that has the capabilities you need on all platforms.  
> Well, I suppose there is an argument to be made for "good enough for 
> now" though; even having a navigate_up() that tops out at the volume 
> root (and won't let you switch volumes) would probably let a 
> from-scratch file browser cover most users' needs.

Well here are my choices in the matter, as I see it:

Implement navigate_up to include a meta-root for volumes and which 
increases the object hierarchy complexity for most platforms. (Adding 
one method to CFileDesc now requires changes to THREE classes for a 
specific platform... basic CFileDesc, and then volume and file 
delegates.)

Or implement an incomplete navigate_up. (It may not be able to back up 
past the current volume) or no navigate_up at all. (But I'm close 
enough now that the incomplete one is doable) And implement a 
get_volumes method on CFileDescFactory that returns a vector with 
CFileDesc that point to each existing volume's root. This doesn't alter 
the object hierarchy and it adds everything that I would think you 
would need. (Well, excluding the directory perusal stuff that isn't yet 
implemented either :))

I'm inclined to go with the latter approach considering the tradeoffs 
that I see.

>> Ah, I didn't realize that that processing was a feature of AlephOne 
>> specifically. I'll have to look into it. Does A1 deal with a 
>> MacBinary of a map file too? Or does that still need to be explicitly 
>> split out into two files?
>
> It looks like (though I have not tested this myself) that it should 
> indeed be able to read both forks from the single MacBinary file, no 
> need to split.
>
> Resource fork: look in resource_manager.cpp for the 
> resource-fork-parsing routines... see e.g. around line 124, in 
> res_file_t::read_map() (which reads a resource-fork-map, not a Map 
> file :) ).  (Since my resource forks are in files on my Windows 
> machine, and I can play... well this code seems to work.)
>
> Data fork: look in FileHandler_SDL.cpp, e.g. line 363 
> FileSpecifier::Open().

That's just cute. Insanely cute :)

Hsm. I'm not sure how on earth I would do that with iostreams. I mean, 
I know how I might do it, but I honestly have no idea as to whether I 
can do it that way, I don't know which kinds of methods I can override 
safely. Durn C++.

-Jeremy Parsons

> Yeah A1/SDL (not SDL itself) also does things like interpreting  'snd 
> ' resources (as long as they're of a specific subtype of course) and 
> 'PICT's (again, not the fully general case of course)... it had to to 
> be able to work with the existing data files as-is.
>

Fwd: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

d'oh.

Begin forwarded message:

> From: "Woody Zenfell, III" <woo...@sb...>
> Date: Wed Feb 12, 2003  10:55:11  AM US/Central
> To: "Br'fin" <br...@ma...>
> Subject: Re: [Alephmodular-devel] CFileDesc landed
>
> On Wednesday, February 12, 2003, at 06:13  AM, Br'fin wrote:
>
>> It's doable to setup something that has an innerclass that changes 
>> when it hits that point, but seems somehow... annoying.
>
> Right, this is what I was picturing.  Maybe feels annoying in the 
> implementation half, but then you have a clean consistent interface 
> from the outside that has the capabilities you need on all platforms.  
> Well, I suppose there is an argument to be made for "good enough for 
> now" though; even having a navigate_up() that tops out at the volume 
> root (and won't let you switch volumes) would probably let a 
> from-scratch file browser cover most users' needs.
>
>>> A1 as you probably know has code to interpret the relevant parts and 
>>> types of the resource fork straight from a raw 
>>> resource-fork-formatted file, from an AppleSingle file, or from a 
>>> MacBinary file.  I think that qualifies as a 'specific format', and 
>>> better yet doesn't really require any conversion for existing content.
>>
>> Ah, I didn't realize that that processing was a feature of AlephOne 
>> specifically. I'll have to look into it. Does A1 deal with a MacBinary 
>> of a map file too? Or does that still need to be explicitly split out 
>> into two files?
>
> It looks like (though I have not tested this myself) that it should 
> indeed be able to read both forks from the single MacBinary file, no 
> need to split.
>
> Resource fork: look in resource_manager.cpp for the 
> resource-fork-parsing routines... see e.g. around line 124, in 
> res_file_t::read_map() (which reads a resource-fork-map, not a Map 
> file :) ).  (Since my resource forks are in files on my Windows 
> machine, and I can play... well this code seems to work.)
>
> Data fork: look in FileHandler_SDL.cpp, e.g. line 363 
> FileSpecifier::Open().
>
> Yeah A1/SDL (not SDL itself) also does things like interpreting  'snd ' 
> resources (as long as they're of a specific subtype of course) and 
> 'PICT's (again, not the fully general case of course)... it had to to 
> be able to work with the existing data files as-is.
>
>> I'll look into it, But there is an advantage to keeping the Resource 
>> Manager implementation separate from a more generic method. You can 
>> toggle between them between builds and confirm what things are errors 
>> in implementation instead of errors elsewhere in the code.
>
> Ok agreed, good point.
>
> Woody
>

Re: [Alephmodular-devel] CFileDesc landed

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

On Wednesday, February 12, 2003, at 01:57  AM, Woody Zenfell, III wrote:

> On Wednesday, February 12, 2003, at 12:10  AM, Br'fin wrote:
>
>> Navigate_up certainly reaches a messy spot at that point. Then again 
>> it might be easier to say 'No you can't navigate past the root of one 
>> volume, buuuuuut, you can do this other command to find get a base 
>> root object for each volume' Iiiick messy yuck. :/
>
> This seems, to me, less clean and no more convenient nor capable than 
> the pseudo-master-root approach...

Messy either way. I agree. But the function that queries for volumes 
returns a set of CFileDescs that aside from being unable to navigate up 
upon are otherwise a normal set of CFileDescs. Remember, navigate_* 
commands affect the current CFileDesc, meanwhile mucking with volumes 
is outside the scope of normal operation. :/ There's no problem with a 
unix style implementation of CFileDesc (Where the entire system is 
rooted under /) but there's a problem with Non-unix setups. Windows, 
MacOS. At the top level all your platform APIs for volumes get 
different :/

It's doable to setup something that has an innerclass that changes when 
it hits that point, but seems somehow... annoying.

(The current code is MacOS based and uses FSSpecs and accesses details 
with param-blocks, I've been debating bumping things over to FSRefs, 
but decided that could wait til after the initial CFileDescs)

>>> Does resource-handling stuff include support for a stronger notion 
>>> of "scenario"?
>>>
>> Actually, no. My current view of resource-handling stuff is that it 
>> should be treated as legacy code. We need it for direct reading of 
>> M1/M2/Minf files and scenarios. But I would prefer a specific format 
>> specified for such things under non-mac platforms and which could be 
>> the basis for the AM specific format going forward.
>
> Oh ok, you really did mean 'resource' as in 'stuff on disk the Mac 
> Resource Manager works with', rather than a more general sense of 
> 'external media and data AM needs to run a scenario' or the like.

Yes yes.

> A1 as you probably know has code to interpret the relevant parts and 
> types of the resource fork straight from a raw resource-fork-formatted 
> file, from an AppleSingle file, or from a MacBinary file.  I think 
> that qualifies as a 'specific format', and better yet doesn't really 
> require any conversion for existing content.

Ah, I didn't realize that that processing was a feature of AlephOne 
specifically. I'll have to look into it. Does A1 deal with a MacBinary 
of a map file too? Or does that still need to be explicitly split out 
into two files?

> Indeed it would make sense to me to use this body of code even on 
> platforms that have the Resource Manager (they could open the resource 
> fork as raw data, e.g. as A1/SDL on Mac OS X does by opening 
> Map/rsrc)... results more consistent/reproducible across platforms and 
> all that.  But maybe I'm silly.

I'll look into it, But there is an advantage to keeping the Resource 
Manager implementation separate from a more generic method. You can 
toggle between them between builds and confirm what things are errors 
in implementation instead of errors elsewhere in the code.

-Jeremy Parsons

> I don't doubt the utility of an AM-specific format in the future, nor 
> do I dispute that such a format should avoid the use of resource 
> forks.  But whether AM has to jump directly to this future format 
> before it can support non-Mac platforms...
>
> Woody

Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

On Wednesday, February 12, 2003, at 12:10  AM, Br'fin wrote:

> Navigate_up certainly reaches a messy spot at that point. Then again it 
> might be easier to say 'No you can't navigate past the root of one 
> volume, buuuuuut, you can do this other command to find get a base root 
> object for each volume' Iiiick messy yuck. :/

This seems, to me, less clean and no more convenient nor capable than 
the pseudo-master-root approach...

>> Does resource-handling stuff include support for a stronger notion of 
>> "scenario"?
>>
> Actually, no. My current view of resource-handling stuff is that it 
> should be treated as legacy code. We need it for direct reading of 
> M1/M2/Minf files and scenarios. But I would prefer a specific format 
> specified for such things under non-mac platforms and which could be 
> the basis for the AM specific format going forward.

Oh ok, you really did mean 'resource' as in 'stuff on disk the Mac 
Resource Manager works with', rather than a more general sense of 
'external media and data AM needs to run a scenario' or the like.

A1 as you probably know has code to interpret the relevant parts and 
types of the resource fork straight from a raw resource-fork-formatted 
file, from an AppleSingle file, or from a MacBinary file.  I think that 
qualifies as a 'specific format', and better yet doesn't really require 
any conversion for existing content.

Indeed it would make sense to me to use this body of code even on 
platforms that have the Resource Manager (they could open the resource 
fork as raw data, e.g. as A1/SDL on Mac OS X does by opening 
Map/rsrc)... results more consistent/reproducible across platforms and 
all that.  But maybe I'm silly.

I don't doubt the utility of an AM-specific format in the future, nor do 
I dispute that such a format should avoid the use of resource forks.  
But whether AM has to jump directly to this future format before it can 
support non-Mac platforms...

Woody

Re: [Alephmodular-devel] CFileDesc landed

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

On Wednesday, February 12, 2003, at 12:36  AM, Woody Zenfell, III wrote:

>> Probably because a 'from-scratch' file browser never occurred to me. 
>> Possibly assuming that even SDL had its methods.
>
> Nope sorry, SDL doesn't try to abstract filesystem navigation.

Nuisance, that.

>> Essentially I was implementing navigate_up, was wondering how to deal 
>> with the case of a volume root. (I'm not at all clear how the 
>> CFileDesc stuff would handle volume switching) and then I remembered 
>> that the code sample I was using had things in front of it along the 
>> lines of "I promise I won't use this stuff for evil" or some such.
>
> navigate_up() from a volume root would probably return an instance 
> (oops, no wait, we can't do that - hmm maybe internally there's an 
> indirection, a little along the lines of a State or Strategy pattern?) 
> of a related (but different) class that's some sort of 
> pseudo-master-root thing whose children are the roots of the various 
> volumes available.  (?)

Navigate_up certainly reaches a messy spot at that point. Then again it 
might be easier to say 'No you can't navigate past the root of one 
volume, buuuuuut, you can do this other command to find get a base root 
object for each volume' Iiiick messy yuck. :/

>> I'm waffling between trying to look into the details of screen 
>> management, and being tugged by some file bastions that need some 
>> kind of stamping. While I haven't committed to a resource handling 
>> API yet, there seems little reason for shapes and sounds to generally 
>> be roaming completely free of the portable_files.h API.
>
> Does resource-handling stuff include support for a stronger notion of 
> "scenario"?
>
Actually, no. My current view of resource-handling stuff is that it 
should be treated as legacy code. We need it for direct reading of 
M1/M2/Minf files and scenarios. But I would prefer a specific format 
specified for such things under non-mac platforms and which could be 
the basis for the AM specific format going forward.

-Jeremy Parsons

Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

On Tuesday, February 11, 2003, at 09:22  PM, Br'fin wrote:

> On Tuesday, February 11, 2003, at 08:52  PM, Woody Zenfell, III wrote:
>
>> Is there any compelling reason to _not_ have it in the interface?
>
> Probably because a 'from-scratch' file browser never occurred to me. 
> Possibly assuming that even SDL had its methods.

Nope sorry, SDL doesn't try to abstract filesystem navigation.

> Essentially I was implementing navigate_up, was wondering how to deal 
> with the case of a volume root. (I'm not at all clear how the CFileDesc 
> stuff would handle volume switching) and then I remembered that the 
> code sample I was using had things in front of it along the lines of "I 
> promise I won't use this stuff for evil" or some such.

navigate_up() from a volume root would probably return an instance 
(oops, no wait, we can't do that - hmm maybe internally there's an 
indirection, a little along the lines of a State or Strategy pattern?) 
of a related (but different) class that's some sort of 
pseudo-master-root thing whose children are the roots of the various 
volumes available.  (?)

> I'm waffling between trying to look into the details of screen 
> management, and being tugged by some file bastions that need some kind 
> of stamping. While I haven't committed to a resource handling API yet, 
> there seems little reason for shapes and sounds to generally be roaming 
> completely free of the portable_files.h API.

Does resource-handling stuff include support for a stronger notion of 
"scenario"?

Woody

Re: [Alephmodular-devel] CFileDesc landed

[Timothy C. <tco...@ha...>]

>> Just so you don't think all your text is going to /dev/null or 
>> something... I've been reading your notes with interest, and wanted 
>> to say it sounds like things are going very well.  Congratulations 
>> and keep up the good work :)
>
> Thank you, I must say that the quiet had been getting to me :)

I would have replied, if only to compliment you, if most of this hadn't 
gone straight over my head...I'm not that good with files yet ;-)  
However, I'm sure that this is all really great!  Keep up the good 
work, Br'fin!

I should really start studying files...gonna need them for my own 
projects before long...

Timothy Collett

You step in the stream,
But the water has moved on.
This page is not here.
~haiku~

Re: [Alephmodular-devel] CFileDesc landed

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

On Tuesday, February 11, 2003, at 08:52  PM, Woody Zenfell, III wrote:

> Just so you don't think all your text is going to /dev/null or 
> something... I've been reading your notes with interest, and wanted to 
> say it sounds like things are going very well.  Congratulations and 
> keep up the good work :)

Thank you, I must say that the quiet had been getting to me :)


> A couple questions:
>
> Is there a way to change one's mind with the safe-save business?  i.e. 
> can I open a file for writing, do some stuff, then say "oops never 
> mind!" and get rid of the file without it actually going through with 
> the swap?

The swap won't occur if the stream is in a bad state. So the following 
will keep a file from swapping:

	fileref->setstate(std::ios::badbit);

If someone has a pointer to something that says that doing this is a 
bad thing, tm, then I'll try and make more of the COFileRef's interface 
available to the rest of the system. (To the rest of the system, even 
with safe saving, OFileRef is still just viewed as a std::ostream*)

> Also, I know you keep saying file browsing is a platform-specific 
> thing, but... a from-scratch file browser would probably quite benefit 
> from the ability to navigate_up() (and then could browse using your 
> FileDesc stuff directly rather than having to implement a parallel set 
> of routines on the platform).  Is there any compelling reason to _not_ 
> have it in the interface?

Probably because a 'from-scratch' file browser never occurred to me. 
Possibly assuming that even SDL had its methods.

Essentially I was implementing navigate_up, was wondering how to deal 
with the case of a volume root. (I'm not at all clear how the CFileDesc 
stuff would handle volume switching) and then I remembered that the 
code sample I was using had things in front of it along the lines of "I 
promise I won't use this stuff for evil" or some such.

So, as of the current time, navigate_up is if'def'd out as it would 
need more work, and navigate_sibling is protected. With caveats along 
the lines that its only used by safe save.

You could label me as ambiguous on navigate_up. I'm a little hazy on 
how to best implement its details mac-wise, and it wasn't needed for 
the current line of work.

> What's next?  :)  Whatever it is, looking forward to it...  :)
>
Thanks. :)

I'm waffling between trying to look into the details of screen 
management, and being tugged by some file bastions that need some kind 
of stamping. While I haven't committed to a resource handling API yet, 
there seems little reason for shapes and sounds to generally be roaming 
completely free of the portable_files.h API.

-Jeremy Parsons

Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

Just so you don't think all your text is going to /dev/null or 
something... I've been reading your notes with interest, and wanted to 
say it sounds like things are going very well.  Congratulations and keep 
up the good work :)

A couple questions:

Is there a way to change one's mind with the safe-save business?  i.e. 
can I open a file for writing, do some stuff, then say "oops never 
mind!" and get rid of the file without it actually going through with 
the swap?

Also, I know you keep saying file browsing is a platform-specific thing, 
but... a from-scratch file browser would probably quite benefit from the 
ability to navigate_up() (and then could browse using your FileDesc 
stuff directly rather than having to implement a parallel set of 
routines on the platform).  Is there any compelling reason to _not_ have 
it in the interface?

What's next?  :)  Whatever it is, looking forward to it...  :)

Woody


On Tuesday, February 11, 2003, at 07:03  PM, Br'fin wrote:

> And there, safe saving should be in the mix as well. Nice and sweet to 
> implement with only one gotcha with resources. Specifically the preview 
> resources added to save games.
>
> And it's always there, whenever you open a file for writing. 
> Automagically.
> I just find the concept so cool :)

Re: [Alephmodular-devel] CFileDesc landed

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

And there, safe saving should be in the mix as well. Nice and sweet to 
implement with only one gotcha with resources. Specifically the preview 
resources added to save games.

And it's always there, whenever you open a file for writing. 
Automagically.
I just find the concept so cool :)

-Jeremy Parsons

On Tuesday, February 11, 2003, at 01:32  PM, Br'fin wrote:

> I just landed the majority of the new file abstraction code.
>
> Most of the details missing involve the following
> 	creating directories
> 	managing resource files and forks
> 	orchestrating safe saves
>
> Application-wise, everything should still be working. From replays to 
> saving the game and loading physics files.
>
> -Jeremy Parsons
>

[Alephmodular-devel] CFileDesc landed

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

I just landed the majority of the new file abstraction code.

Most of the details missing involve the following
	creating directories
	managing resource files and forks
	orchestrating safe saves

Application-wise, everything should still be working. From replays to 
saving the game and loading physics files.

-Jeremy Parsons

[Alephmodular-devel] Good progress on CFiles!

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

After working up the basics of the streams and the files types. Then 
getting the existing API working using the classes, I expanded upon 
CFileDesc and actually managed to push this through the code.

Things appear to be working still for saving and loading files and 
handling preferences and vidmaster replays. All that really remains is 
for me to cleanup the code a bit more so I can land this version.

In the meantime, I updated my document based upon what I've actually 
implemented. So while I work on cleaning up the code, you can check out 
what it looks like. I find myself fairly happy with the way this is 
looking. Especially after having stumbled across clone methods to help 
smooth out some spots that had a lot of potential for trouble.

-Jeremy Parsons

Note: This document is still evolving. But is being used to guide the 
process
and is being updated to reflect final code.

Technical Specification: File Hardware Abstraction

First there was portable_files.h and it was good in concept. But there 
was only a Macintosh implementation. And even so, there was an evident 
bios in the structure towards the Macintosh.

Please note that this does not handle file browsing. That is in the 
realm of the GUI.


Platform specific stuff can use the platform specific CFileDesc 
constructor.
IE MacOS X would support CFileDesc_Carbon(FSSpec&)


CFileDescFactory is a singleton class that provides access to a set of 
base CFileDesc locations.

But in order to navigate, you can't use just create a CFileDesc(...). 
Instead you either use a platform specific filebrowser, or you find 
files programatically by asking for a CFileDesc pointed at a standard 
directory and then navigating through its subdirectories.

Since CFileDescFactory is a singleton, you get access to it's current 
instance via CFileDescFactory::get_instance().

And a CFileDescFactory instance implements the following methods that 
all return a CFileDesc*. You are responsible for deleting the pointer 
when you are done with it.

	CFileDesc* get_application_directory() const
		The directory the application has been run from
		(Typically Current dir if command line, directory of application 
executable otherwise)
		
	CFileDesc* get_preferences_directory() const
		The location to store a user's specific settings
		
	CFileDesc* get_save_game_directory() const
		Default location to save games
		
	CFileDesc* get_replay_directory() const
		Default location to save replays. Most notably the replay that is 
automatically
		recorded whenever you play a game.
		
	CFileDesc* get_resources_directory() const
		Where to find other required support files. For instance theme files 
for an SDL build.


CFileDesc represents a file or directory's location.
Under Unix, this would be the full path to a file. Under Macintosh this 
is akin to a FSSpec. Most typically it refers to a parent directory and 
knows the name of its object within that directory.
Most notably this has functions for creating the specified file, 
opening the file for reading, or opening the file for writing.

The basic strategy for CFileDesc is to get an initial CFileDesc, either 
from a platform specific file browser or by asking CFileDescFactory for 
a CFileDesc to a specific directory. The CFileDesc is then malleable. 
You can navigate it down within subdirectories to specify the file you 
want. And when you are done you free your CFileDesc.

A CFileDesc implements the IFailable interface for reporting errors 
during operations. See CError.h for more information on IFailable.

A given platform specific derivative should accept platform native file 
specifications. (For interfacing with native file browsers)

Basic properties (Not necessarily public!) Internal represenation is 
definitly platform dependant. For instance CFileDesc_Carbon implements 
the basic information using MacOS FSSpec records.
	The parent directory of the pointed to file or directory
	The name of the current file or directory
	The type of the current file or directory
		See CFileType for more about the type of the element

Basic public operations include:
	bool clone(CFileDesc*&)
		Returns whether or not the cloning was successful
		If successful, clone creates an entire duplicate of the current
		CFileDesc. You are responsible for maintaining and deleting this copy.
		If unsuccessful check the IFailable interface for errors. (Hence why
		clone isn't a const method)
		
	bool exists() const
		Returns true if the referred to file or directory exists in the file 
system
		
	bool is_file() const
		Returns true if the referred to item exists and is a file
		
	bool is_directory() const
		Returns true if the referred to item exists and is a directory
	
	void get_name(std::string&) const
		Returns in the passed string the name of the current file or directory
	
	
public file operations (These are errors if called on a directory)
	void set_type(const CFileType& type)
		Specifies the type of the file. You must call this before calling
		create_file()
		
	const CFileType& get_type() const
		Returns the current type of the file. In the future this will be
		expected to confer with the CFileType mechanisms to determine the
		type of an arbitrary file.

	bool create_file()
		Creates the file specified by the CFileDesc at that location. It will 
delete
		a file that already exists in that location.
		Returns true on success or false and an IFailable error state on 
failure.
		
	bool delete_file()
		Deletes the specified file from the file system.
		Returns true on success or false and an IFailable error state on 
failure.

	bool open_for_reading(IFileRef&)
		Opens the specified file for binary reading and returns an istream
		compatible class. You are responsible for deleting the returned class.
		Returns true on success or false and an IFailable error state on 
failure.
		
	bool open_for_writing(OFileRef&)
		Opens the specified file for binary writing and returns an ostream
		compatible class. You are responsible for deleting the returned class.
		Returns true on success or false and an IFailable error state on 
failure.

	open_resources_for_reading (Returns CResourceFileRef)
		Not currently implemented

public directory operations (IDirectoryDesc) (These are errors if 
called on a file)
	Not currently implemented beyond navigate()

	bool navigate(const std::string& _name)
		On success, return true and the CFileDesc points to the new element.
		On failure, for instance drilling down into multiple undefined
		directories, navigate returns false, sets an IFailable error state
		and doesn't change the location of the CFileDesc.
		Note that it should be ok to specify one level of non-existing element
		so you can then create it.

Protected operations
	bool iofname(std::string&)
		Returns an if/ofstream compatible path for the file. Used internally 
for
		initially opening the files for reading/writing. This means a platform
		specific class has less to do, only needing to convert the platform
		specific representation into a path type string.
		
	swap(CFileDesc)
		Safe Save support
		Swaps contents of two file descs
		These should be two files on the same device and use OS file swapping
			calls where available
		Not currently implemented.

Navigation of CFileDescs would include methods to work based on the 
CFileDesc
	ala CFileDesc GetParent() to get the parent of this directory
	and CFileDesc GetNamedChild(itemname)
	GetTemporaryCopy
		Returns a CFileDesc to a temporary file in the same directory as the
		current CFileDesc, the name should be unique and the file shouldn't 
already exist.


IFileRef represents an open file for reading. Specifically it is a
	typedef std::istream* IFileRef

COFileRef represents an open file for writing. Specifically it is a
	typedef std::ostream* OFileRef

To close files of this sort, you should explicitly delete the class.

Save saving is not yet implemented.

A note on saving files. When you open a file for writing the following 
transpires. You are given an ofstream derived object that is internally 
associated with the current CFileDesc and a temporary one. The 
temporary CFileDesc is guaranteed to be in the same directory as 
CFileDesc and to have a unique name.

Upon proper closure of the stream the temporary file the following 
happens.
If CFileDesc exists, than the temporary file is swapped with it and the 
original content of CFileDesc discard (swap occurs, then temporary file 
deleted) Otherwise the temporary file is renamed to the name in 
CFileDesc.
ofstream.close() isn't virtual, so we can't override it, but it does 
have a virtual destructor. Within there we can do:
	this->close()
	if(this->is_good()) // The closing of the file didn't raise any errors
	{
		curFileDesc.swap(tempFileDesc);
		tempFileDesc.delete();	
	}


CResourceFileRef represents an open resource file.
We will support reading of resources. We will support a way of reading 
in resources from a data file. We won't generally support saving of 
resource files. (Any new file formats heading forward should be flat 
files or bundles (multiple files in a strict directory hierarchy)

Resource files are not yet implemented.


CFileType represents the type of a file
CFileDesc is our friend and can use the protected virtual methods for 
getting type_code, type_extension and the type checking.

There are three special cases of CFileType
	CDirectoryType
		a plain old directories
		(a directory that was a bundle would be handled seperately)
	CUnknownType
		If we examine a CFileDesc and it matches no known types,
		then CUnknownType is the tye used for the file
	CFamilyType
		A hierarchy of types for checking a file's type against. For
		instance, checking if a given specific type is a map or a M2 file.
		CCreatorFamilyType is a subset of the family type which also knows
		its creator code.

All others descend from CTypedFileType which has basic operations
A file type generally encapsulates the following:
	The file's creator: ala M2, Minf, or AlephModular)
	The four character code associated with a file on MAcintosh: aka TEXT
	The extension associated with the file on other systems: aka txt (as 
in README.txt)
	a test() method for checking whether or not a CFileDesc matches the 
current type
	a test_contents() method for checking within a file for a type match

Testing CDirectoryType against file decriptions only matches type with 
directories
Testing CUnknownType against file descriptions is always false. It is 
only assigned when either nothing is known, or everything else fails to 
match.
Testing CFamilyType against file descriptions always fails.
Testing CTypedFileTypes against a file succeeds if type and creator 
match or if the extension matches. Subclasses may perform more 
complicated tests, such as inspecting the file's contents (by 
implementing test_contents(FileDesc*))

test_contents() is seperate from test() so that if a first pass by 
inspecting via test fails to locate a file's type, then that file can 
be checked over the available types by performing the content tests of 
the types.

FileTypes support a matches(FileType) method to tell if the type who's 
matching method is being called considers itself to be the type of the 
argument, or a logical element of that type's set.

	CMarathon2MapType.matches(CAlephModularMapType) == false
	CMarathon2MapType.matches(CMarathon2MapType) == true
	CMarathon2MapType.matches(CMapFamily) == true
	CMarathon2MapType.matches(CMarathon2Family) == true

	
I admit, on typing I'm trying to figure out if the class is 
C<whatever>Type and is essentially a singleton. What is a decent way of 
referring to one specific type or another?

A CFileTypeFactory that offers GetTypeFor("<whatever>") with a hash or 
dictionary within?

Here are the existing families
	Creators:
	CAlephModularFamilyType
	CMarathon2FamilyType
	
	Files:
	CImagesFamilyType
	CMapFamilyType
	CMusicFamilyType
	CPhysicsFamilyType
	CPreferencesFamilyType
	CReplayFamilyType
	CSaveGameFamilyType
	CShapesFamilyType
	CSoundsFamilyType
	
Actual File Types:
	CAlephModularPreferencesFileType
	CAlephModularReplayFileType
	CAlephModularSaveGameFileType
	CMarathon2ImagesFileType
	CMarathon2MapFileType
	CMarathon2PhysicsFileType
	Cmarathon2ReplayFileType
	CMarathon2ShapesFileType
	CMarathon2SoundsFileType
	

File organization details:
Initial work will proceed in portable_files.h, files_macintosh.cpp, 
Support/CFiles.cpp, Support/CFileTypes.h, Support/CFileTypes.cpp, and 
CFileDesc_Carbon.h. At a later point in time when files are 
reorganized, this will become
	Support/CFiles.h (was portable_files.h)
	Support/CFiles.cpp
	Support/Carbon/CFileDesc_Carbon.h
	Support/Carbon/CFileDesc_Carbon.cpp (was files_macintosh.cpp)
	Support/CFileTypes.h
	Support/CFileTypes.cpp
	

Re: [Alephmodular-devel] On CfileDesc and handling navigation

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

And after a little further thought and research, I have to wonder. 'Why 
the heck do we need a GetParent/navigate_up anyhow?' If there's 
anything we need, then it should either already be in or under a 
specified directory.

We find the preferences directory and write preferences within it. We 
find the application's directory and find support files within or under 
it.

Unless anyone can field a good argument for why we would want it, I'm 
inclined to nix it from the available APIs.

-Jeremy Parsons

On Monday, February 10, 2003, at 08:36  AM, Br'fin wrote:

> I've been using my draft as a guide and piece by piece implementing 
> portions using or replacing bits of the existing API. (For instance, 
> the checked in code now uses iostreams and CFileTypes)
>
> And my own build has begun using a simpler version of CFileDesc as the 
> internals to the existing API.
>
> Kind of neat having opening a file be in CFile.cpp. With the platform 
> specific bit of converting the platform's internal representation to a 
> name compatible with new std:ifstream being handled by the platform 
> subclass. :)
>
> I am, however, having distinct second thoughts about creating a new 
> CFileDesc for each navigation. Seeing how memory management of the 
> various C++ classes is annoying, the prospect of editing a CFileDesc 
> in place is appealing to me more and more.
>
> instead of
> 	GetParent			- new CFileDesc
> 	GetNamedChild		- new CFileDesc
>
> more of
> 	clone()			- new CFileDesc
> 	navigate_up()		- modifies current CFileDesc
> 	navigate(child)	- modifies current CFileDesc
>
> -Jeremy Parsons
>

[Alephmodular-devel] On CfileDesc and handling navigation

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

I've been using my draft as a guide and piece by piece implementing 
portions using or replacing bits of the existing API. (For instance, 
the checked in code now uses iostreams and CFileTypes)

And my own build has begun using a simpler version of CFileDesc as the 
internals to the existing API.

Kind of neat having opening a file be in CFile.cpp. With the platform 
specific bit of converting the platform's internal representation to a 
name compatible with new std:ifstream being handled by the platform 
subclass. :)

I am, however, having distinct second thoughts about creating a new 
CFileDesc for each navigation. Seeing how memory management of the 
various C++ classes is annoying, the prospect of editing a CFileDesc in 
place is appealing to me more and more.

instead of
	GetParent			- new CFileDesc
	GetNamedChild		- new CFileDesc

more of
	clone()			- new CFileDesc
	navigate_up()		- modifies current CFileDesc
	navigate(child)	- modifies current CFileDesc

-Jeremy Parsons

Re: [Alephmodular-devel] We're on IMG

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

On Saturday, February 8, 2003, at 07:52  PM, Alexander Strange wrote:

> http://www.insidemacgames.com/news/story.php?ArticleID=6982
>
> (They like Aleph One and other Marathon-related projects quite a lot, 
> probably because the head guy Tuncer Deniz is a former Bungie > employee)
>

Yeah, I noticed that. Especially after trying to figure out why we 
suddenly had such a page view and download spike that particular day :)

Going from 50-60 views a day to 960 views on one day and 120 downloads 
was quite the usage spike :)

-Jeremy Parsons

[Alephmodular-devel] We're on IMG

[Alexander S. <ast...@it...>]

http://www.insidemacgames.com/news/story.php?ArticleID=6982

(They like Aleph One and other Marathon-related projects quite a lot, 
probably because the head guy Tuncer Deniz is a former Bungie employee)

[Alephmodular-devel] Fleshing out file types...

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

After getting initial iostreams working for files I decided to handle 
file types and creator codes before working on FileDescs proper. As I 
get my head around the creator codes better and write up the classes I 
thought I would revamp that portion of my file document.

-Jeremy Parsons


CFileType represents the type of a file
CFileSystemDesc is our friend and can use the protected virtual methods 
for getting type_code, type_extension and the type checking.

There are three special cases of CFileType
	CDirectoryType
		a plain old directories
		(a directory that was a bundle would be handled seperately)
	CUnknownType
		If we examine a CFileSystemDesc and it matches no known types,
		then CUnknownType is the tye used for the file
	CFamilyType
		A hierarchy of types for checking a file's type against. For
		instance, checking if a given specific type is a map or a M2 file.
		CCreatorFamilyType is a subset of the family type which also knows
		its creator code.

All others descend from CTypedFileType which has basic operations
A file type generally encapsulates the following:
	The file's creator: ala M2, Minf, or AlephModular)
	The four character code associated with a file on MAcintosh: aka TEXT
	The extension associated with the file on other systems: aka txt (as 
in README.txt)
	a test() method for checking whether or not a CFileSystemDesc matches 
the current type
	a test_contents() method for checking within a file for a type match

Testing CDirectoryType against file decriptions only matches type with 
directories
Testing CUnknownType against file descriptions is always false. It is 
only assigned when either nothing is known, or everything else fails to 
match.
Testing CFamilyType against file descriptions always fails.
Testing CTypedFileTypes against a file succeeds if type and creator 
match or if the extension matches. Subclasses may perform more 
complicated tests, such as inspecting the file's contents (by 
implementing test_contents(FileDesc*))

test_contents() is seperate from test() so that if a first pass by 
inspecting via test fails to locate a file's type, then that file can 
be checked over the available types by performing the content tests of 
the types.

FileTypes support a matches(FileType) method to tell if the type who's 
matching method is being called considers itself to be the type of the 
argument, or a logical element of that type's set.

	CMarathon2MapType.matches(CAlephModularMapType) == false
	CMarathon2MapType.matches(CMarathon2MapType) == true
	CMarathon2MapType.matches(CMapFamily) == true
	CMarathon2MapType.matches(CMarathon2Family) == true

	
I admit, on typing I'm trying to figure out if the class is 
C<whatever>Type and is essentially a singleton. What is a decent way of 
referring to one specific type or another?

A CFileTypeFactory that offers GetTypeFor("<whatever>") with a hash or 
dictionary within?

[Alephmodular-devel] ifstream gotcha...

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

So, I've begun trying to work with the file system.

The first real pass at it, I've replaced fileref from portable_files=20
with ifstream* and iostream=95 values. Kind of annoying all the spots=20
that use a local int16 instead of outright using fileref to begin with.

Anyhow, got hit with one gotcha. It also came back to haunt me around=20
the time I was sorting out replay spooling.

static FileError read_from_file(
	IFileRef file_id,
	int32 offset,
	void *data,
	int32 length)
{
	assert(file_id !=3D NULL);
#if DEBUG
	int32 file_length;
	file_id->seekg(0l, std::ios::end);
	file_length =3D file_id->tellg();
	assert(offset+length <=3D file_length);
#endif
	file_id->seekg(offset, std::ios::beg);
	if (file_id->good())
	{
		file_id->read(static_cast<char*>(data), length);
	=09
		// Explictily return noErr because of a quirk where =
performing
		// a read on the last n bits of a file that would =
exactly hit the
		// eof may very well trigger it. But our read went off =
ok!
		file_id->clear();
		return noErr;
	}
=09
	return ((file_id->eof())?errHitFileEOF:!(file_id->good()));
}

And of course there are elements of shapes and sounds which don't even=20=

use portable_files yet.

-Jeremy Parsons=

Re: [Alephmodular-devel] Sketches on directory layouts...

[Michael A. <mdm...@ya...>]

I like this.  Putting all the platform specific files
in seperate subdirectories, would make it easyer to
maintain the project files.  "Hmm... I want to build
on windows, so lets try adding common/*.cpp and
win32/*.cpp.  Wow! It works!  Lets try common/*.cpp
and osx/*.cpp for my carbon build.  That works too!" 
Right now in A1 tracking down files that are added can
be a pain even when the additions are well documented.
 I'm not so concerned if some of the common/*.[h|cpp]
files have platform #ifdef's in them, just that
figuring out which files need to be linked into a
build for a platform is easy.  That is if x.o (from
x.cpp) only gets linked into the app when on platform
Y then x.cpp should be in Y/x.cpp (or some varient of
that form).  If x.o gets linked for all platforms then
x.cpp goes into common/x.cpp.  I don't know about
files that are linked on more than one platform, but
not all.

Anyway, just some thoughts from the perspective of
someone (potentially) trying to compile the program.

Michael D. Adams
mdm...@ya...

--- Br'fin <br...@ma...> wrote:
> I've been poking at the files and trying to figure
> out how to integrate 
> new code. So one of the things is that Apple has
> these functions, 
> MoreFileX.h/.c. Which has useful code for handling
> files on Macintosh. 
> And I'm thinking along these lines:
> 
> 
> source_code_dir/
> 	Support/
> 		AStream.h
> 		Astream.cpp
> 		CError.h
> 		Macintosh/
> 			MoreFilesX.h
> 			MoreFilesX.c
> 
> Hsm, and if a situation warranted a subdir, then I
> might as well also 
> put CFiles_Macintosh.h/.cpp into such a subdirectory
> as well..
> 
> -Jeremy Parsons
> 
> 
> 
>
-------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =
> Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
>
https://lists.sourceforge.net/lists/listinfo/alephmodular-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com