alephmodular-devel — AlephModular Developers Mailing List

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

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

A couple thoughts up front...

On Friday, January 24, 2003, at 01:39  AM, Br'fin wrote:

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

And perhaps rightly so, at least for things like resource forks that we 
have to deal with but which (obviously) impose a Mac bias.  (I haven't 
reviewed portable_files.h, so maybe there is more Mac bias than the 
"some" that needs to be there.)

Obviously at the moment the SDL and Mac A1s are sharing code at some 
level and splitting apart into separate file handling code at some 
level - any analysis/comments on the situation there?  My guess would be 
that the split comes too high since (IMO) that seems to be the case with 
most Mac/SDL splits in A1.

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

So will there be a standard interface for things like "locate files that 
match my filter" (which  may be used for populating a file browsing 
dialog) etc.?  Such a thing would also be useful for a set of paths to 
search for a given file.

> Platform specific stuff can use the platform specific CFileDesc  
> constructor.
> IE Mac would wave CMacFileDesc(FSSpec&)
>
> But in order to naviagte, you can't use CFileDesc(...) You would need  
> to use a factory to build up the CFileDesc... ala
>
> CFileDesc *foo = FILE_DESC_FACTORY->ConstructFileDesc(CFileDesc  
> *directory, "file");
> ...
> delete foo;

So far this is a comment, an observation, not a quibble or 
recommendation etc., but... note that if you have multiple factories at 
once, the above construction requires that the program know which 
factory it should use at all times.  If directory FileDescs that came 
from Factory A should always produce FileDescs from Factory A (and never 
from Factory B), then it would be better to have FileDescs know which 
factory they came from (either by virtue of the class structure, or by 
explicitly keeping a reference to the factory) and ask a FileDesc for a 
sub-FileDesc.  (Or ask a FileDesc for its factory, and ask that for a 
sub-FileDesc, which maybe should be an option but asking the FileDesc 
directly is provided as a convenience method.)

> The factory is also the most reasonable place to provide access to  
> CFileDescs for specific platform specific places. Ala preferences  
> directory and application directory
>
> CFileDesc *foo =  FILE_DESC_FACTORY- 
> >GetSpecificDir(CFileDescFactory::ApplicationsDirectory);
> // It is an error to delete this foo
>
> Specific directories so far are
> 	ApplicationDirectory - The directory the application has been run from
> 			(Current dir if command line, directory of application 
> executable  otherwise)
> 	PreferencesDirectory

Note that some platforms may want to install and find data files 
somewhere other than the application directory.  In general I think 
having more "specific directories", even if they map to the same real 
directory in practice, is going to be a Good Thing as it gives different 
platforms the opportunity to put things where they want at a finer 
granularity.

Maybe on the whole I'm not understanding the role this plays in a larger 
system, but I have questions like: what about resource forks?  what 
about searching multiple places?  what _about_ support for file 
browsing?  what about retrieving a directory's contents?  etc.  I like 
centralizing (in a Factory) all the explicit paths etc. - and since 
every FileDesc will come from one of these root FileDescs (right?  well 
except for FileDescs that come from the OS-native representation I 
guess, but the Factory could be used for those too), the Factory gets to 
determine the C++ type of the FileDesc we end up using - but I am not 
sure what other benefits it offers (e.g., why _is_ it better to ask the 
Factory for a FileDesc every time we want a file within a directory, 
instead of asking the directory's FileDesc?).  Please discuss.

> CFileDesc represents a file'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 file within that directory.
> Most notably this has functions for creating the specified file,  
> opening the file for reading, or opening the file for writing.
>
> A given platform specific derivative should accept platform native 
> file  specifications. (For interfacing with native file browsers)
>
> Operations include
> 	create_file
> 	open_file_for_reading (Returns CFileRef)
> 	open_file_for_writing (Returns CFileRef)
> 	delete_file
>
>
> CFileRef represents an open file
>
> Operations include
> 	get_fpos
> 	set_fpos
> 	set_eof
> 	get_file_length
> 	read_file
> 	write_file
> 	close_file

And a CFileRef is, I hope, a subclass of some more-general "read and 
write chunks of data" scheme that's also the basis for the "Packing" 
(serialization) stuff, rather like SDL_RWops, that provides the same 
interface for working with chunks of data in memory as it does for 
working with chunks of data in files.  (SDL_RWops provides seek, tell, 
get length, close, and various read and write operations, both "raw" and 
packing- (and byte-swapping-) oriented.)

A CFileRef would be allowed to return its CFileSpec on request of 
course.  Memory chunks would return a special value (maybe NULL?) 
instead to indicate they're not file-backed.  I'm not sure whether this 
involves a dynamic_cast<> and a subclass-specific query, or a 
"top-level" query to the CDataRef itself.  (There may wish to be a 
corresponding method to get the base address of a CBufferRef also, for 
example.)

Perhaps there would be a mechanism to associate a memory chunk with a 
file, that creates the file and writes out the memory chunk.  But that 
could be dangerous if some folks start using the new CFileRef object for 
reading and writing, but others have still retained and are trying to 
use the CBufferRef (or whatever).  Perhaps the interface should only 
support saving the buffer into a file, forcing the programmer to 
explicitly close the buffer (hmm, should be reference counted somehow?) 
and open the file, and then give the CFileRef to whomever needs it, to 
emphasize that they're two separate objects.

What about "safe saves"?  Should there be sort of built-in support for 
that sort of thing at a fairly low level?

Man all this reinventing-the-wheel stuff really does make me wish we 
were sitting on top of libFoundation or something ;)  I guess the 
important question to ask is "what flexibility/better platform-dependent 
conformance/etc. are we buying with this extra layer of wrapping?"  I 
mean, why NOT just use some kind of standard mechanism like iostreams or 
stdio?  at least for most of the interface?  (you could supplement those 
mechanisms with some kind of abstraction only where needed.)  I mean, 
they're there, they're familiar, they're tested, and they're not going 
to be going away any time soon.  (I recognize that there are benefits to 
wrapping.  I would just like to see them made explicit as part of the 
reasoning/justification.)

Anyway please don't take any of the above really as 'argument', I'm glad 
to see a specific suggestion as a starting point and hope that a 
discussion (including "devil's advocate" questions to expose more detail 
and strengthen the underlying reasoning) will bring to light any 
appropriate alterations.  Like I said, I don't have a good picture of 
where CFileSpec fits into the bigger structure, so a lot of the things I 
asked about could be irrelevant in the limited context of CFileSpec 
itself - but if they're not handled there, then where?

Now I guess I'd better get on the stick with regard to the 
networking/input system eh?  :)

Woody

[Alephmodular-devel] TS Draft: File abstraction

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

I've been trying to resist the urge to just get in and tussle with  
portable_files.h If I'm going to ask Woody to try and document stuff, I  
should hold myself accountable too.

Is this too much overhead for our backwoods project? No idea. On the  
other hand, you do get to see some of my thinking before I commit it to  
the source tree. And I get to do my thinking before hand instead of  
waffling over where to put a detail after the fact.

Let's see if we can keep me doing it.

-Jeremy Parsons

Here is my current thinking on redoing portable_files.h Now is it too  
high or low a system? On one hand, it's fairly straight forward. It  
opens and closes files. It reads files. And with most system with a c  
stdio library, some of it is downright lazy/lame. On the other hand, it  
  is one of the bones I have to pick with AlephOne.

Also there is waffle room.
To me FILE_DESC_FACTORY->ConstructFileDesc(CFileDesc *directory,  
FileName) seems no better or worse than CFileDesc *foo =  
myCFileDesc->ConstructFileDesc(FileNameToAdd) So I'd not mind some  
feedback on the issue. And while I can see doing everything within  
CFileDesc (Using the class in many/all of the circumstances where I'm  
using the factory) It doesn't seem like the right thing to do.


And finally, here's the draft:

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 Mac would wave CMacFileDesc(FSSpec&)

But in order to naviagte, you can't use CFileDesc(...) You would need  
to use a factory to build up the CFileDesc... ala

CFileDesc *foo = FILE_DESC_FACTORY->ConstructFileDesc(CFileDesc  
*directory, "file");
...
delete foo;

The factory is also the most reasonable place to provide access to  
CFileDescs for specific platform specific places. Ala preferences  
directory and application directory

CFileDesc *foo =  
FILE_DESC_FACTORY- 
 >GetSpecificDir(CFileDescFactory::ApplicationsDirectory);
// It is an error to delete this foo

Specific directories so far are
	ApplicationDirectory - The directory the application has been run from
			(Current dir if command line, directory of application executable  
otherwise)
	PreferencesDirectory
	

CFileDesc represents a file'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 file within that directory.
Most notably this has functions for creating the specified file,  
opening the file for reading, or opening the file for writing.

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

Operations include
	create_file
	open_file_for_reading (Returns CFileRef)
	open_file_for_writing (Returns CFileRef)
	delete_file


CFileRef represents an open file

Operations include
	get_fpos
	set_fpos
	set_eof
	get_file_length
	read_file
	write_file
	close_file

[Alephmodular-devel] On Dialogs

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

The external view of a dialog is something like this
	Setup dialog
	Fill dialog with preliminary necessary info
		Think a list of maps for instance
	Fill dialog with current options
	Process the dialog
		During dialog processing, certain elements may perform callbacks to
		code the originated the dialog.
		Think a network dialog polling for people
	If Ok is hit
		then extract info from dialog into options
	Tear down the dialog

Taking a peak through Woody's A1 code reveals what he said before. Most 
specifically the fill_dialog and extract_dialog routes are mostly 
handled by cross-platform code under A1 for the network game options.

I do find myself wondering if fill_in_game_setup_dialog as presented is 
too... verbose?

It sets values from player prefs and network prefs.
It refers to controls of roughly a specific type

Now, I might be over-designing things. But wouldn't one abstraction be 
to treat all controls the same? For each control we're setting a value. 
And as a second element deciding which controls are enabled. And 
wouldn't a second abstraction treat the options we're dealing with as 
some kind of dictionary or hash?

Which ends up translating into a list of SetMyWidget(iControl, 
options->valueFor('icontrol_setting'); commands. Regardless of which 
are check boxes, menus, text boxes or radio groups.

Now, I admit, going the dictionary route (completely generic incoming 
options hash) could indeed be going too far. On the other hand, it 
might be appropriate to have such a dictionary anyhow in a re-handling 
of preferences to be more flexible.

-Jeremy Parsons

Re: [Alephmodular-devel] Build-selectable binding time

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

On Wednesday, January 22, 2003, at 11:01  AM, Woody Zenfell, III wrote:

> Hi,
>
> I was thinking, for a lot of this stuff it may make sense to use like 
> classes, so that we can easily group interfaces and ensure some degree 
> of consistency in their use, and also so that some modules can inherit 
> some routines but override others.
>
> So that would tend to point toward using effectively an 'interface', 
> i.e. a base class with lots of pure virtual functions, that subclasses 
> override.
>
> But in many cases there will always be only one actual concrete 
> subclass used in any given build of the program.  (For example, the 
> Carbon build is probably always going to use the CarbonWidgetManager 
> or whatever, and a build with SDL widgets will always use the 
> SDLWidgetManager.)  So it seems to make sense to allow that choice of 
> subclass to be made at compile-time; thus the compiler and linker can 
> take advantage of this "advance knowledge" to produce better code.
>

One one hand it sounds like a good idea.
On the other hand it's an optimization and makes the code trickier.

I'm inclined to nix the idea for now. It adds to the code complexity 
while possibly solving an inappropriate problem. I admit the question 
is much more interesting with respect to game responsive elements. Such 
as the sound manager and the graphics handler. On the other hand, this 
is Marathon, not Doom III. We shouldn't be taxing the system that badly 
:)

Now if we actually find that we're having problems with a particular 
area being slow, then I'm more likely to say yes to optimizations, but 
just for that specific area.

-Jeremy Parsons

Re: [Alephmodular-devel] Networking module thoughts (was re: Random musings online and thoughts towards 0.4)

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

On Wednesday, January 22, 2003, at 09:24  AM, Woody Zenfell, III wrote:

> It sounds like what you're picturing mimics A1's current layering 
> etc., we should just make the various interfaces more explicit (group 
> related functions in a class, e.g.).  That's fine with me.  :)  I've 
> been wanting to clean up A1's network subsystem code anyway; maybe I 
> should just do this in the context of A1 at the moment, and AM can of 
> course use the code as well.

Shows you what I know. I honestly haven't really *looked* at Marathon's 
networking code and organization. And what I did for A1 doesn't count, 
because I still wasn't looking at the code, but just connecting things 
together cluelessly :)

> I'm concerned about what you mean by "SDL should be just another 
> platform"; currently all A1 platforms use SDL_net for their networking 
> (though the Classic version also uses Open Transport directly for one 
> module).  I assume what you mean is that if somebody wanted to write 
> an all-OT implementation (though why they would want to do that when 
> the cross-platform code works fine is beyond me) that they would be 
> able to drop it in with a minimum of fuss.  That's already the case 
> essentially, the only sticky bit is in the handling of addresses 
> (which should be relatively straightforward to take care of).

It's a cleanliness thing to my thinking. I admit in the case of 
networking I'm less picky about having CLowLevelNetworking and 
CLowLevelNetworkingSDL be separate classes. But the stuff including 
CLowLevelNetworking.h shouldn't also need to include "SDL_Networking" 
anywhere along the way either.

Basically, given what I've said before regarding other modules, I 
*should* hold the networking platform elements to the same standards. 
Even if there's only ever going to be one implementation.

> It's a bit funny to think that interfaces like sockets and XTI (the 
> basis for Open Transport) are wrappers that try to hide the details of 
> an implementation - and then we're wrapping those in SDL_net to hide 
> the details - and then we're wrapping SDL_net to hide the details.  
> But I suppose each layer buys us something.

If each layer did everything that a given app needed from it, we 
wouldn't need more layers. OpenTransport wasn't about when M2 
networking was setup. Sockets weren't the only networking target for 
the initial networking either.

I admit for AM we have simpler networking targets. Internet based 
sockets. I would suspect that our low level network layer would 
actually be simplifying some of the SDL stuff. (One of our calls 
translates to one or more SDL calls for instance, or the same call but 
with out all the flexibility that the initial SDL call needed to allow)

> It's my understanding that the network_modem and AppleTalk stuff 
> should be treated as dead code at the moment - yes?  (I mean in AM; I 
> already consider it dead in A1 and plan to strip it out Real Soon > Now.)

Yes. I just haven't had the heart to cvs remove any of the network 
files yet.

> The interesting questions in my mind all have to do with scheduling, 
> which hasn't really come up yet.  I'll see what I can think up.  I 
> mean, different schemes are going to have different scheduling 
> requirements - like, the ring scheme requires that the machine drop 
> everything and get the ring packet passed on ASAP when one arrives; in 
> a star scheme, the incoming data is only needed just before render 
> time, for doing updates (whoops, need to talk some more about your 
> overall architecture, I just remembered) and so the incoming data can 
> be handled in the main thread.  Well probably the simplest option is 
> to provide the hooks for both schemes, and have a given protocol only 
> use whichever it needs.  (i.e. in a star scheme there's no "packet 
> listener" associated with the UDP socket, so the star code doesn't use 
> whatever interface lets it associate one; in a ring scheme there's no 
> special processing to do just before update, so 
> NetworkStuff->AboutToUpdate() (called by the update routine) doesn't 
> do anything.  That sort of thing.)

Flexible hooks are good, yes. :)

Scheduling, I agree, is still a hazy issue. I haven't yet researched 
what threads are necessary and what the requirements around them may be 
for different platforms.

Classic was ok with a VBL timer task for input and letting the main 
thread handle rendering. (And I admit I don't know where networking 
fits in here!)

Carbon, on the other hand, would much rather have the OS Event loop in 
the input thread and have the main game thread with rendering as the 
separate entity.

> [snipped, regarding action flags]
Yes, you're probably right here. I don't have a good grasp on when 
certain game internal structures are going to be redone as classes. It 
may be on an as needed basis.

> I consider the netgame-related dialogs to be outside the network code, 
> though clearly they need to communicate.  [The dialogs being 
> considered separate] is probably a Good Thing, because at my last 
> count we still vigorously disagreed on the best design for 
> dialog-related code, what with me advocating a more flexible, more 
> modular, more "layered" approach that lets developers share code.

Dialogs I've not done enough thinking on. But I now have some thoughts. 
I'll try and get to them in another email later today.

>
> Anyway, I'll see what I can come up with with regard to networking and 
> input.
>
> Do we have any consistent style guidelines with regard to naming 
> classes, methods, data members, locals, file-global (static) storage, 
> class methods, globals, class (static) storage, ordinary functions, 
> files, etc.?  Placement of braces?  Layout of a function's formal 
> parameters at the function definition?  etc.  I figure the clearest 
> way to express my design is going to be to write code, and the code 
> may turn out to be useful to boot.  :)
>
> Woody
>
Style-wise I'm working to stay consistent with the current Marathon 
code. Failing that possibility where there's new code features, I'm 
inclined to go with ISample interfaces and CSample classes. And if 
casting needs to be done, try and use the C++ style casts.

Alright on the code if it helps you think. Some documentation would be 
nice (And Yes, i need to get on my own case regarding this too :) )

-Jeremy Parsons

[Alephmodular-devel] Build-selectable binding time

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

Hi,

I was thinking, for a lot of this stuff it may make sense to use like 
classes, so that we can easily group interfaces and ensure some degree 
of consistency in their use, and also so that some modules can inherit 
some routines but override others.

So that would tend to point toward using effectively an 'interface', 
i.e. a base class with lots of pure virtual functions, that subclasses 
override.

But in many cases there will always be only one actual concrete subclass 
used in any given build of the program.  (For example, the Carbon build 
is probably always going to use the CarbonWidgetManager or whatever, and 
a build with SDL widgets will always use the SDLWidgetManager.)  So it 
seems to make sense to allow that choice of subclass to be made at 
compile-time; thus the compiler and linker can take advantage of this 
"advance knowledge" to produce better code.

But we don't want to _require_ that it be specified at build-time, in 
case e.g. some platform can use any of several different implementations 
of a given interface, and the choice may be made at runtime (either 
automatically, or by some kind of explicit configuration in the UI or in 
a file of some sort).

I haven't thought this all the way through, but it seems to me that 
using preprocessor symbols for the type names (and probably for the 
'virtual' keyword) could let us choose.  That is, maybe you have

class DatagramSystem { lots of pure virtual methods };
class SDLNetUDPDatagramSystem : public DatagramSystem { yadda };
class OpenTransportUDPDatagramSystem : public DatagramSystem { yadda };

Now typically, code that's going to use this would like, ask for the 
current DatagramSystem with NetworkCoordinator->GetDatagramSystem(), 
which would return a DatagramSystem* that really points at, say, an 
SDLNetUDPDatagramSystem.  Everything works fine.  But maybe this 
DatagramSystem is the only one that's ever going to make sense in this 
build (at least until there are more DatagramSystems written).  So we'd 
rather have it appear that all of SDLNetUDPDatagramSystem's methods are 
nonvirtual, and that GetDatagramSystem() returns an 
SDLNetUDPDatagramSystem*, so that the compiler and linker have better 
information to work with.

So maybe there's some kind of post-configuration file (that's always the 
same) that does

#ifndef DATAGRAMSYSTEM
#define DATAGRAMSYSTEM DatagramSystem
#define DATAGRAMSYSTEM_VIRTUAL virtual
#else
#define DATAGRAMSYSTEM_VIRTUAL
#endif

so then a configuration file (or build flag etc.), which can be 
different on different platforms or in different builds, can optionally 
do

#define DATAGRAMSYSTEM SDLNetUDPDatagramSystem

to establish the binding early, or leave DATAGRAMSYSTEM undefined to get 
the most-generic, most-dynamic behavior.

class DatagramSystem { would have DATAGRAMSYSTEM_VIRTUAL bool 
SendDatagram(...); etc. }, so the preprocessor could determine whether 
the methods are really virtual or not.

users of the DatagramSystem would use DATAGRAMSYSTEM* instead of 
DatagramSystem*, so that the preprocessor could rewrite them to the 
specific subclass if desired.

Hmm, although, users of DATAGRAMSYSTEM would also have to somehow 
#include the proper header for the specific subclass if a subclass is 
used at compile-time.  Hmm.  Well could you just do

// This part would be in a standard header file somewhere
// I think this two-level separation is needed to make sure that 'a' 
gets expanded to the real classname before being stringified.
#define MAKE_HEADER_FILENAME(a) REALLY_MAKE_HEADER_FILENAME(a)
#define REALLY_MAKE_HEADER_FILENAME(a) #a ".h"

// This part would be found in files that use DATAGRAMSYSTEM
#include MAKE_HEADER_FILENAME(DATAGRAMSYSTEM)

This is just a random thought I had, it seemed reasonably 
straightforward and made sense to me, but maybe any gains to be gotten 
from it are not worth the extra fuss.  Virtual method calls aren't 
_that_ expensive I suppose, at least not when only made once (or a 
hundred times) a tick or so.  (Now, tens of thousands of times per 
tick... maybe it'd be worth it ;) )

Whatdya think?  Kooky?  Or, surely someone else somewhere has thought of 
this before, and has come up with The Best Way of doing it...

Woody

Re: [Alephmodular-devel] Networking module thoughts (was re: Random musings online and thoughts towards 0.4)

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

It sounds like what you're picturing mimics A1's current layering etc., 
we should just make the various interfaces more explicit (group related 
functions in a class, e.g.).  That's fine with me.  :)  I've been 
wanting to clean up A1's network subsystem code anyway; maybe I should 
just do this in the context of A1 at the moment, and AM can of course 
use the code as well.

I'm concerned about what you mean by "SDL should be just another 
platform"; currently all A1 platforms use SDL_net for their networking 
(though the Classic version also uses Open Transport directly for one 
module).  I assume what you mean is that if somebody wanted to write an 
all-OT implementation (though why they would want to do that when the 
cross-platform code works fine is beyond me) that they would be able to 
drop it in with a minimum of fuss.  That's already the case essentially, 
the only sticky bit is in the handling of addresses (which should be 
relatively straightforward to take care of).

It's a bit funny to think that interfaces like sockets and XTI (the 
basis for Open Transport) are wrappers that try to hide the details of 
an implementation - and then we're wrapping those in SDL_net to hide the 
details - and then we're wrapping SDL_net to hide the details.  But I 
suppose each layer buys us something.

It's my understanding that the network_modem and AppleTalk stuff should 
be treated as dead code at the moment - yes?  (I mean in AM; I already 
consider it dead in A1 and plan to strip it out Real Soon Now.)

The interesting questions in my mind all have to do with scheduling, 
which hasn't really come up yet.  I'll see what I can think up.  I mean, 
different schemes are going to have different scheduling requirements - 
like, the ring scheme requires that the machine drop everything and get 
the ring packet passed on ASAP when one arrives; in a star scheme, the 
incoming data is only needed just before render time, for doing updates 
(whoops, need to talk some more about your overall architecture, I just 
remembered) and so the incoming data can be handled in the main thread.  
Well probably the simplest option is to provide the hooks for both 
schemes, and have a given protocol only use whichever it needs.  (i.e. 
in a star scheme there's no "packet listener" associated with the UDP 
socket, so the star code doesn't use whatever interface lets it 
associate one; in a ring scheme there's no special processing to do just 
before update, so NetworkStuff->AboutToUpdate() (called by the update 
routine) doesn't do anything.  That sort of thing.)

I think one of the most important things, looking forward, is to further 
abstract the action_flags - have a class for them that can return info 
about whether the user is pressing the second trigger, etc., can set the 
values for a given action_flag as to whether the user is pressing his 
action key etc., and which knows how to pack/unpack them (possibly using 
different schemes for films vs. network packets) and copy them.  I 
suppose the same code module should probably be responsible for handling 
queues of action_flags.  This way we can leave our options open in the 
future - using something other than a 32-bit word to store action_flags, 
adding new kinds of input, etc. - and making the change shouldn't 
require significant alterations outside the action_flags code itself.

I consider the netgame-related dialogs to be outside the network code, 
though clearly they need to communicate.  [The dialogs being considered 
separate] is probably a Good Thing, because at my last count we still 
vigorously disagreed on the best design for dialog-related code, what 
with me advocating a more flexible, more modular, more "layered" 
approach that lets developers share code.  (This being the high-level 
dialog logic/low-level system widget implementation split; nothing to do 
with using SDL as the default dialog system or not.  I have made several 
arguments for this scheme and have pointed to its successful use in 
practice (the A1 netgame dialogs), but have heard no reason as to why we 
would want to separate the dialogs by platform at a high level and thus 
*force* every platform to provide its own implementation of the same 
basic logic, instead of letting them share if they wish to but letting 
them diverge if they find they must.)

Anyway, I'll see what I can come up with with regard to networking and 
input.

Do we have any consistent style guidelines with regard to naming 
classes, methods, data members, locals, file-global (static) storage, 
class methods, globals, class (static) storage, ordinary functions, 
files, etc.?  Placement of braces?  Layout of a function's formal 
parameters at the function definition?  etc.  I figure the clearest way 
to express my design is going to be to write code, and the code may turn 
out to be useful to boot.  :)

Woody


On Wednesday, January 22, 2003, at 07:19  AM, Br'fin wrote:

> At the moment, the things that come to mind are
> 	
> 	Modular networking
> 		So things don't care if they are talking with CNetworkRing or 
> CNetworkStar
> 	Modular layers
> 		So one object is doing the actual interfacing with the 
> network libs and a
> 		higher level is dealing with the actual data being sent back 
> and forth. I should say 		that SDL should be treated like 
> another platform even down here. (I'm not so sure I
> 		have the heart for it down here in networking, but I should ;) )
> 	Separation of GUI and implementation
> 		I know, I know, this is an ill defined area. But network 
> setup should probably
> 		be of the form GUI->DoNetworkGatherDialog(..., networkGatherOptions)
> 		If we can bump off the GUI class for another intermediary 
> class, that's even better.
> 		this->networkConfiguration->GetNetworkGatherOptions(...) Thus letting
> 		configuration come more transparently from a file or other 
> source as well.
> 	Replays need to be maintained
> 		Even if the server is driving everything, I guess the local 
> machine still needs
> 		the action flags for its own personal replay recording.
>
> As for how closely you accommodate existing code? What is defined and 
> documented now is most likely going to stay as is for a good long 
> while. Unless there is a decent way to have networking overall be 
> flexible enough to affect the action flags like it does now, and later 
> be driving a shallow game core that mostly updates the animation's game 
> states, you're probably going to be locked into one or another method 
> of networking and driving the game.

[Alephmodular-devel] Networking module thoughts (was re: Random musings online and thoughts towards 0.4)

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

On Wednesday, January 22, 2003, at 01:28  AM, Woody Zenfell, III wrote:

> On Tuesday, January 21, 2003, at 08:12  PM, Br'fin wrote:
>
>> I'll try and come up with a better document in the coming days. But 
>> something I'm curious about now is whether any of the programmers we 
>> have here have an interest in researching and planning a particular 
>> area of code? There is a reason this project's status on SourceForge 
>> is listed as 'planning' we need to develop/derive our own 
>> architecture for this if we want the modules :)
>
> Yeah shall I take a stab at the networking/input system?  I suspect 
> I'm sort of the resident expert on that area.  Anything special you 
> have in mind for that that could inform the design?  How closely 
> should it accomodate the existing code?  (Depends on how willing I am 
> to rewrite it?  I see.  ;) )
>
> Woody
>
>
At the moment, the things that come to mind are
	
	Modular networking
		So things don't care if they are talking with CNetworkRing or 
CNetworkStar
	Modular layers
		So one object is doing the actual interfacing with the network libs 
and a
		higher level is dealing with the actual data being sent back and 
forth. I should say 		that SDL should be treated like another platform 
even down here. (I'm not so sure I
		have the heart for it down here in networking, but I should ;) )
	Separation of GUI and implementation
		I know, I know, this is an ill defined area. But network setup should 
probably
		be of the form GUI->DoNetworkGatherDialog(..., networkGatherOptions)
		If we can bump off the GUI class for another intermediary class, 
that's even better.
		this->networkConfiguration->GetNetworkGatherOptions(...) Thus letting
		configuration come more transparently from a file or other source as 
well.
	Replays need to be maintained
		Even if the server is driving everything, I guess the local machine 
still needs
		the action flags for its own personal replay recording.

As for how closely you accommodate existing code? What is defined and 
documented now is most likely going to stay as is for a good long 
while. Unless there is a decent way to have networking overall be 
flexible enough to affect the action flags like it does now, and later 
be driving a shallow game core that mostly updates the animation's game 
states, you're probably going to be locked into one or another method 
of networking and driving the game.

-Jeremy Parsons

Re: [Alephmodular-devel] Random musings online and thoughts towards 0.4

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

On Tuesday, January 21, 2003, at 08:12  PM, Br'fin wrote:

> I'll try and come up with a better document in the coming days. But 
> something I'm curious about now is whether any of the programmers we 
> have here have an interest in researching and planning a particular 
> area of code? There is a reason this project's status on SourceForge is 
> listed as 'planning' we need to develop/derive our own architecture for 
> this if we want the modules :)

Yeah shall I take a stab at the networking/input system?  I suspect I'm 
sort of the resident expert on that area.  Anything special you have in 
mind for that that could inform the design?  How closely should it 
accomodate the existing code?  (Depends on how willing I am to rewrite 
it?  I see.  ;) )

Woody

[Alephmodular-devel] Random musings online and thoughts towards 0.4

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

I've decided to toss some of my random thoughts and explorations and 
notes regarding Marathon and AlephModular into my Sourceforge diary. 
Consider them proto-notes and curiosities. It's not like AM has a lot 
of documentation yet. (It probably should in some fashion)

Right now I just started it off with a couple explorations of the 
rendering code, looking at details that a display class would need to 
deal with.

Head to http://sourceforge.net/users/brefin/ and check the View Diary & 
Notes link.


As to 0.4, I definitely want to address the basic hardware abstraction 
layer. Files, sounds, screen. I'd also like to settle some of the other 
basic support areas. wad files, preferences (internally, not gui). 
Further inspection needs to be done on areas like shell.cpp and 
interface.cpp and the preferences gui. Most notably and difficulty, 
abstracting the event loop.

I'll try and come up with a better document in the coming days. But 
something I'm curious about now is whether any of the programmers we 
have here have an interest in researching and planning a particular 
area of code? There is a reason this project's status on SourceForge is 
listed as 'planning' we need to develop/derive our own architecture for 
this if we want the modules :)

-Jeremy Parsons.

[Alephmodular-devel] AlephModular 0.3.0 preview released

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

Ok, I went and did it. I compiled and assembled a new MacOS X Release 
of AlephModular.

You can download the new release from the project page at
http://sourceforge.net/projects/alephmodular/


Here's the Readme (such as it is)


AlephModular has been released under the GNU GENERAL PUBLIC LICENSE. 
See gpl.txt
for more information on the rights available to you.

This is a preview release of AlephModular. At v0.3 it is still 
pre-alpha.
Currently it only runs under MacOS X, but should work under 10.1 or 
10.2.

For all intents and purposes this should be a rough Carbon port of 
Marathon 2.

Put all the Marathon 2 shapes, maps, and sound files in the same 
directory and
it should run. If you don't have the full files, then you should be 
able to use
the Marathon 2 demo files.

Mouse is not enabled, networking is not enabled. Saved games and 
preferences are
not compatible with Marathon 2. The GUI is not yet polished (This 
includes
mis-fades and lousy framerates, low-resolution is much improved over
high-resolution)

There's probably more stuff that is or isn't working.

Bugs in the GUI are not likely to be addressed at the moment, not when 
that area
is going to see a rewrite. However crashing bugs and bugs in gameplay 
or replays
should be reported at 
http://sourceforge.net/tracker/?group_id=69003&atid=523091

Have fun and keep an eye on our homepage at 
http://alephmodular.sourceforge.net/

-Jeremy Parsons
Br'fin

Re: [Alephmodular-devel] MacOS X 10.1 users?

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

On Monday, January 13, 2003, at 08:17  PM, Woody Zenfell, III wrote:

> Aha, so when AM is busy horking the processor continuously in hi-res 
> mode for its rendering, the system hardly ever gets to step in and blit 
> results to the screen.  (Does lo-res drawing somehow bypass this 
> mechanism?  It seems to not suffer from this restriction, and also 
> tends to "tear", both of which suggest that it might?)

From: "Br'fin" <br...@ma...>
Date: Mon Jan 20, 2003  05:04:30  PM US/Central

> I think I found part of why low-resolution mode is so speedy. I was 
> preparing a build for the a 0.3 preview release. And I happened to have 
> it compiling then running in the background. Well it's running, I have 
> low-resolution turned on, and suddenly it starts overwriting my 
> foreground windows when AM kicks into demo mode.
>
> Apparently the low-res code doesn't do a copy from back buffer to 
> foreground window, it's setup to copy directly to the *screen*

Glad an explanation materialized.  But you're right, AM should do things 
"by the rules".

Woody

[Alephmodular-devel] Very interesting detail - Low Resolution

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

I think I found part of why low-resolution mode is so speedy. I was 
preparing a build for the a 0.3 preview release. And I happened to have 
it compiling then running in the background. Well it's running, I have 
low-resolution turned on, and suddenly it starts overwriting my 
foreground windows when AM kicks into demo mode.

Apparently the low-res code doesn't do a copy from back buffer to 
foreground window, it's setup to copy directly to the *screen*

I certainly doubt that this is the right way to do things. (I believe 
DrawSprockets is. I think the Draw Sprockets also handles alt-tab 
issues as well) But I find it interesting and I find I must resist the 
urge to tweak high-resolution like that and check it in :)

-Jeremy Parsons

Re: [Alephmodular-devel] A note on films

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

On Sunday, January 19, 2003, at 10:08  AM, Alexander Strange wrote:

>
> On Sunday, January 19, 2003, at 02:35 AM, Br'fin wrote:
>>
>> I don't think AM appreciably diverges yet. At the very least I as 
>> checking through a couple of the demos in M2 proper and all the key 
>> points seemed to be hit, including player death in one of them.
>>
>
> You might try the Vidmaster Central 
> (http://marathon.bungie.org/vidmaster/). They're longer and more 
> intricate, so are probably easier to trigger bugs with.
>

Oh wonderful. I just downloaded Marathon2_TC_JimM_films.sit from there 
and watched it go through Ex Cathedra. Impressive job of getting though 
and a nice demonstration of why if we add to the AI it should be kept 
separate from the base AI. :)

Matt, I think you should include a link to the vidmaster site among the 
AlephModular links. And if you have any FAQs on 'how can I help or 
test?' or the like, include not just playing, but watching prior M2 
films for anomalies.

-Jeremy Parsons

Re: [Alephmodular-devel] A note on films

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

On Sunday, January 19, 2003, at 02:35 AM, Br'fin wrote:
>
> I don't think AM appreciably diverges yet. At the very least I as 
> checking through a couple of the demos in M2 proper and all the key 
> points seemed to be hit, including player death in one of them.
>

You might try the Vidmaster Central 
(http://marathon.bungie.org/vidmaster/). They're longer and more 
intricate, so are probably easier to trigger bugs with.

Re: [Alephmodular-devel] A note on films

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

On Sunday, January 19, 2003, at 02:58 AM, Woody Zenfell, III wrote:
> Actually, if the (exact) same checkfile mechanism were used in A1, we 
> could make sure that A1 is still film-file compatible with M2 (well, 
> or at least the current AM) (which A1 may not be; even very subtle 
> changes can break films).
>

It's not. I don't think it's even film-compatible with itself.

Re: [Alephmodular-devel] A note on films

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

On Sunday, January 19, 2003, at 01:35  AM, Br'fin wrote:

> On Saturday, January 18, 2003, at 03:38  PM, Woody Zenfell, III wrote:
>>
>> (I assume it's obvious that the "checkfile" would be generated from 
>> the filmfile as early as possible... then occasionally in the game's 
>> development lifetime, that original filmfile and checkfile would be 
>> used to make sure everything's still working the same way internally.)
>
> Output a game tick and all the attitude changes of objects within that 
> tick.
>
> I agree that this could be useful, unfortunately I'm unsure when such a 
> test harness could be implemented. (It seems to require we have our 
> interfaces defined already :/ )

Right, this could be a stronger form of checkfile for later use.

In the meantime, one could dump the value of get_random_seed() at the 
beginning of each tick (when generating) or compare the value against 
the checkfile's value (when playing back a film that has a checkfile).  
Should be reasonably straightforward, no?  And you can check for 
divergence throughout the restructuring against the *current* logic, not 
merely the logic you might end up with post-restructuring 
(post-test-harnessing).

Actually, if the (exact) same checkfile mechanism were used in A1, we 
could make sure that A1 is still film-file compatible with M2 (well, or 
at least the current AM) (which A1 may not be; even very subtle changes 
can break films).

> I rather like the idea of the diffable checkfiles. You don't just know 
> that things diverged, but you know the tick and calculations where they 
> did.

Diffable is good - that's effectively how I used this technique to debug 
A1 - but having the machine check for you (while the film is playing 
back) would be even more convenient I think.

Woody

Re: [Alephmodular-devel] A note on films

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

On Saturday, January 18, 2003, at 03:38  PM, Woody Zenfell, III wrote:
>
> (I assume it's obvious that the "checkfile" would be generated from 
> the filmfile as early as possible... then occasionally in the game's 
> development lifetime, that original filmfile and checkfile would be 
> used to make sure everything's still working the same way internally.)
>
> I guess I didn't get my point across very well - must not have used 
> enough words.  ;)

Your initial posting didn't seem to be clear on working with a 
separately generated state file. I must say, the idea is interesting. 
I'm almost wondering if, for, debugging such a state file could be the 
output of either an alternate or pass through Animation layer 
implementation...

Output a game tick and all the attitude changes of objects within that 
tick.

I agree that this could be useful, unfortunately I'm unsure when such a 
test harness could be implemented. (It seems to require we have our 
interfaces defined already :/ )

> OHH, or maybe there's a concern that AM *already* diverges from M2 
> behavior.  Well, right, obviously the checkfile scheme can't detect 
> that since M2 doesn't write checkfiles.  (I guess you could carefully 
> hack the binary or something to add this capability in, but...)

I don't think AM appreciably diverges yet. At the very least I as 
checking through a couple of the demos in M2 proper and all the key 
points seemed to be hit, including player death in one of them.

> A checkfile alternative could be to use a saved-game at the end of the 
> film, the idea being that if the states diverge at some tick, they 
> will be different for all subsequent ticks, and thus will show up in 
> the final state.  And of course a saved-game captures all relevant 
> game-state, and so *might* be able to catch things that merely the 
> value of get_random_seed() would not.  (Though I rather doubt it, in 
> practice.)  And, automatically comparing two whole game states is not 
> nearly as easy as comparing two 16-bit values.  (Yeah you could 
> actually write the two saved-games out and diff them or something, but 
> it's more painful to automate.)

Yeow, that just sounds really really painful. I rather like the idea of 
the diffable checkfiles. You don't just know that things diverged, but 
you know the tick and calculations where they did.

-Jeremy Parsons

Re: [Alephmodular-devel] A note on films

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

Sounds like a worthwhile to file engine based bug in the code.

Vidmaster dance? I obviously missed out on some of the lingo in the 
realm of Marathon :)

-Jeremy Parsons

On Sunday, January 19, 2003, at 02:16  AM, Aaron Davies wrote:

> If this is what I think you mean, it dates back to M1. This is why in 
> Vidmaster films, the end usually consists of the player running around 
> randomly for a few seconds--to make sure the important stuff all gets 
> saved. It's called the vidmaster dance.
>
> On Saturday, January 18, 2003, at 12:40  PM, Woody Zenfell, III wrote:
>
>> Random thought: A1 films seem to stop after the last recording 
>> "chunk" is put into the action_queues, rather than once the machine 
>> gets a chance to read and render the results - so the end of the film 
>> is sort of clipped off.  I think.  Does M2 (and thus AM) exhibit this 
>> behavior as well?
>>

Re: [Alephmodular-devel] A note on films

[Aaron D. <ag...@co...>]

If this is what I think you mean, it dates back to M1. This is why in 
Vidmaster films, the end usually consists of the player running around 
randomly for a few seconds--to make sure the important stuff all gets 
saved. It's called the vidmaster dance.

On Saturday, January 18, 2003, at 12:40  PM, Woody Zenfell, III wrote:

> Random thought: A1 films seem to stop after the last recording "chunk" 
> is put into the action_queues, rather than once the machine gets a 
> chance to read and render the results - so the end of the film is sort 
> of clipped off.  I think.  Does M2 (and thus AM) exhibit this behavior 
> as well?
>
-- 
     __                        __
    /  )                      /  )
   /--/ __.  __  ________    /  / __. , __o  _  _
  /  (_(_/|_/ (_(_) / / <_  /__/_(_/|_\/ <__</_/_)_

Re: [Alephmodular-devel] A note on films

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

On Saturday, January 18, 2003, at 03:14  PM, Mark Levin wrote:

> On Saturday, January 18, 2003, at 12:40  PM, Woody Zenfell, III wrote:
>
>> Might I suggest that it may be more practical to have a facility for 
>> dumping and another for comparing against an existing "checkfile", so 
>> that the game can automatically detect and warn you about 
>> inconsistencies?
>
> Heh... Might as well let the game record the playing film into a 
> brand-new film and diff them :P

No no no no no this is **totally** different from what I'm saying.  I 
agree that what *you* said is useless.  :)  (Unless by "playing film" 
you mean the M2 filmfile and by "record into a brand-new film" you mean 
"render into a QuickTime file" or something... which I doubt.)

Remember a film file only has the "inputs", i.e. the action_flags 
stream.  The checkfile would be a representation of (part of) the game's 
*state* (i.e. something gotten by extensive computation within the 
engine, based on the inputs but very definitely distinct from them).

The problem we're trying to detect is when applying the same input 
stream produces a different "state stream" - indicating that that 
extensive computation within the engine is no longer coming up with the 
same results it once did.  And the checkfile/filmfile combo would be 
*quite* helpful in this regard.

(I assume it's obvious that the "checkfile" would be generated from the 
filmfile as early as possible... then occasionally in the game's 
development lifetime, that original filmfile and checkfile would be used 
to make sure everything's still working the same way internally.)

I guess I didn't get my point across very well - must not have used 
enough words.  ;)

OHH, or maybe there's a concern that AM *already* diverges from M2 
behavior.  Well, right, obviously the checkfile scheme can't detect that 
since M2 doesn't write checkfiles.  (I guess you could carefully hack 
the binary or something to add this capability in, but...)

A checkfile alternative could be to use a saved-game at the end of the 
film, the idea being that if the states diverge at some tick, they will 
be different for all subsequent ticks, and thus will show up in the 
final state.  And of course a saved-game captures all relevant 
game-state, and so *might* be able to catch things that merely the value 
of get_random_seed() would not.  (Though I rather doubt it, in 
practice.)  And, automatically comparing two whole game states is not 
nearly as easy as comparing two 16-bit values.  (Yeah you could actually 
write the two saved-games out and diff them or something, but it's more 
painful to automate.)

Woody

Re: [Alephmodular-devel] A note on films

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

On Saturday, January 18, 2003, at 12:40  PM, Woody Zenfell, III wrote:

> Might I suggest that it may be more practical to have a facility for 
> dumping and another for comparing against an existing "checkfile", so 
> that the game can automatically detect and warn you about 
> inconsistencies?

Heh... Might as well let the game record the playing film into a 
brand-new film and diff them :P

--Mark

"Today's lesson: Time. Imagine a donut, fired from a cannon at the 
speed of light while rotating. Time is like that, except without the 
cannon and the donut."

Re: [Alephmodular-devel] A note on films

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

Might I suggest that it may be more practical to have a facility for 
dumping and another for comparing against an existing "checkfile", so 
that the game can automatically detect and warn you about 
inconsistencies?

To help ensure the checkfile's integrity, the game would probably 
generate a checkfile with a name based on the film file's name, and it 
would refuse to create a new checkfile - which is something you'd have 
to explicitly ask it to do anyway - if one already exists.  On playback 
it could automatically detect the presence of the checkfile and use it 
if it's there.  You could even alter get_heartbeat_count() to always 
return a really high value when you're in 'checking vs. checkfile' mode 
so that the engine effectively only does the state updates and doesn't 
waste time rendering and waiting for the next tick-time etc.  Or maybe 
that's pretty unnecessary since you can just crank up the replay speed 
manually.  :)

Something like simply dumping out the get_random_seed() each tick (and 
comparing to that dumped value when playing back) would go a long way 
toward detecting inconsistencies.  It's a very tiny piece of state that 
is very likely to get messed up if things go awry (since changes in 
other parts of the state will likely result in different numbers of 
calls to global_random(), at least at some point).

This is effectively how I found the A1 out-of-sync problem... though, my 
code actually only dumped, and I had to manually shuffle files around to 
produce multiple copies, and run command-line diff on them.  (Since I 
knew I was going to be 'diff'ing, I dumped a textual representation out, 
one tick per line - more choices that would likely be incorrect for an 
automated dump-n-check scheme.)

Random thought: A1 films seem to stop after the last recording "chunk" 
is put into the action_queues, rather than once the machine gets a 
chance to read and render the results - so the end of the film is sort 
of clipped off.  I think.  Does M2 (and thus AM) exhibit this behavior 
as well?

Woody


On Saturday, January 18, 2003, at 12:12  PM, Aaron Davies wrote:

> I believe there's already a prog for doing film->mov conversion; 
> perhaps you could just run them through that to get a canonical version 
> you can compare them to.

Re: [Alephmodular-devel] A note on films

[Aaron D. <ag...@co...>]

I believe there's already a prog for doing film->mov conversion; 
perhaps you could just run them through that to get a canonical version 
you can compare them to.

On Thursday, January 16, 2003, at 11:20  PM, Br'fin wrote:

> These would be the various Replays or Films that Marathon 2 had.
>
> In this case I'm asking for transcripts of the 3 demo films that 
> either Marathon 2 or AlephModular play when you let the game sit idle 
> at the main menu.
>
> Detail wise, I'm looking for recognizable events.
>
> Like one of the levels starts with you and a bunch of Bobs on a 
> platform overlooking a large bay as various S'pht counter-attack.
>
> 	Bobs fire on S'pht
> 	Player dodges, takes pot shots
> 	Bob on player's right takes a hit and dies
> 	Player fires on stray S'pht to right
> 	Player takes a hit from S'pht.
> 	Player dodges behind bob who takes the hit
> 	Player and bobs fire upon lone hunter in balcony
> 	Bobs teleport out
> 	Player collects a second pistol
> 	Player empties single bullet from pistol then pulls up both pistols
> 	Player dives into ooze
> 	Player uses map under ooze
> 	Player finishes with map, sees Fusion Pistol and batteries teleport in
> 	Player finds underwater life panel
> 	Player heals to 2x life meter (yellow)
>
> Details people watching could pick out and nod at to say "Yes yes, 
> that's where it's supposed to be. Oops player died there... ok, right, 
> he was supposed to"
>
> -Jeremy Parsons
>
> On Friday, January 17, 2003, at 12:04  AM, Michael Adams wrote:
>
>> What are these films everyone is refering to?  How do
>> I get them?  If I can find them and run them, I would
>> be glad to build a check list.  How detailed and/or
>> long would shuch a list need to be?
>>
>> Michael D. Adams
>> mdm...@ya...
>>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com
> Understand how to protect your customers personal information by 
> implementing
> SSL on your Apache Web Server. Click here to get our FREE Thawte 
> Apache Guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>
>
-- 
     __                        __
    /  )                      /  )
   /--/ __.  __  ________    /  / __. , __o  _  _
  /  (_(_/|_/ (_(_) / / <_  /__/_(_/|_\/ <__</_/_)_

[Alephmodular-devel] AlephModular Web site

[Matt L. <ze...@ze...>]

Hi everyone,

As you may already know, I have been working on a Web site for 
AlephModular. Today I put it up. You can see it here:
     http://alephmodular.sourceforge.net/

It has a few rendering quirks in browsers like IE 5.5/Win, but it 
works fine in most modern browsers, Safari and Chimera (or any 
Gecko-based browser) being the best examples.

On my to-do list still are a general development roadmap page, 
cleaning up and simplifying of the CVS instructions, some more code 
cleanup, and adding vision/direction/developer rant type posts.

If you have any suggestions or comments, I'd be interested to hear them.

-Zebe

-- 
Matt Lee      | PGP key available:
ze...@ze... | http://zebe.net/pgp.asc