alephmodular-devel — AlephModular Developers Mailing List

[Alephmodular-devel] Re: networking, everything over christmas ;-)

[Chris B. <zzk...@uq...>]

> As I stated to the AlephModular development list: "Yes we have a dated 
> 2.5D engine, gosh darn it, but we're going to try and make it the best 
> it can be"

Agree and disagree :-)

Yes, Marathon is a 2.5D engine. It is fairly limited in extensibility 
because of this ('fact', not insult ;-) and because of this it's my 
opinion that the project could achieve more if it allows for growth 
into a full 3D engine. I guess I could ask - list your reasons for and 
against allowing support for 3D rendering? List your reasons for the 
project as a whole? If your focus is purely to bring marathon (with 
modern SW/HW support) to those of the mac gaming community who grew up 
on the game, fair enough. If you're trying to pull new users, you'll 
need to do a little more than just an updated version of the 
same-old-game. That's not to say the gameplay needs to change much. 
(sorry if you've explained this elsewhere, quite possibly i've missed 
it.)

Woody - no insult taken, my original message was posted with exactly 
the idea of bringing argument (and hopefully constructive discussion 
from that.)

Perhaps my outline of the basic networking was poorly explained. I'm 
not opposing (or supporting) the idea of a central server, but rather 
trying to point out the links between physics, animation, and 
networking. They aren't three separate beasts, as much as that would 
simplify life. They need some fairly close ties and if we are to make a 
generic set of systems which can cover different game technologies (as 
suggested by the Modular name) then they will have to communicate to a 
significant degree.

One thing that is required is that local animation and physics 
simulations must be present. They may not be an authority on the game 
state, however they are needed to smooth out the gameplay between 
updates, hide latency, etc.

As was mentioned, animation currently provides the events on which the 
physics system is driven. I'm not at all opposed to this mechanism as 
it simplifies the creation of new (different) models. This doesn't even 
require the animation system to be tied to the physics frame rate, as 
long as it's being simulated (eg.) at some reasonable minimum (maybe 
10-15 fps) frame rate in those situations where the real frame rate 
drops below this.

> What's the problem with larger LANs?

Packet loss, and significantly higher latencies with a ring network. a 
60 player game is going to have > 10x the latency of a 6 player game. I 
can't remember offhand whether marathon uses a ring or not, but even if 
it doesn't, any packet loss / moderately increase latencies is going to 
hurt badly. Even over appletalk it was never the most reliable of 
beasts.


> I am not too big on this idea because of the possibility that the user 
> experience could easily become unpleasant.

Yes, but there is a significant advantage to the developer. It would 
work well on most OSes, the exception probably being macos 9 although 
really that could be done as well with a little IPC. The advantage i 
see is that it splits the project in two definite parts, which is a 
considerable bonus considering the distributed development nature of 
the project. If coded sensibly it could be re-integrated at a later 
date when everything is stable and fairly clean. Again, I think either 
way would work fine, this one just has the advantage of not tying the 
game executable to the (current) limitations of the game interface - 
eg. we could start by simply having it parse a text config (~ 30 lines 
of code) and load the appropriate files and level and settings.

Certainly not ideal for end users, but then, are we expecting end users 
to be able to sit down with the AM code any time soon and start playing 
with it? As soon as people get serious about the development, it's 
probably going to be 6 months before it's any good to anyone..

Again this is just my thoughts, and jeremy gets to make the decisions 
on this, but i think it makes more sense (for now) to have it working 
well for the developers than it does to try and make it polished for 
the end users. I guess it depends if the project #1 priority is (1) 
making marathon work as-is, quickly, or (2) developing the code-base 
and making it modular.


thoughts?

chris

ps. Merry Christmas, everyone.

[Alephmodular-devel] Re: [M-dev]Maintaining AlephOne

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

On Tuesday, December 24, 2002, at 07:39  PM, Michael Adams wrote:

> 2. I'm a little afraid to ask this.  It
> probasoundsunds a little radical.  Maybe I'm mistaken
> (please correct me if so), but the AlephOne code seems
> to bstretchedtreached to its limits.  With all these
> new features that are being bolted onto a product that
> was never intended to have them in the first place,
> would it be more work in the short and/or long run to
> keep patching old code with new features or would it
> be better to try starting from scratch, and build a
> new engine that is cross platform (see #1), can read
> all the old map formats (take "all" to be as general
> or specific as you like (M1, M2, M3, Pathways,
> Doom...)), but also is designed with current and
> future new features in mind?
>
> I know from first had experience that after adding so
> many features to a product, things start getting hard
> to work with.  I also realize that starting over is
> also hard to do.  AlephModular seems to be doing
> something like this (I'm not to clear on its goals),
> but since it is *starting* with the bungie code, I
> worry that I may suffer from the same problems of lack
> of *true* cross platform (see #1 again) and of putting
> new wine in old wineskins.
>
> Michael D. Adams
> mdm...@ya...

Here's the list of my goals for AlephModular. And in many cases I  
started AlephModular because I agreed with some of the issues you  
raised.

The basic AlephModular application should handle the Marathon data  
files (1-3) and essentially be able to play those three games.

It should be stable. It should be clean. It should be cross platform.  
(There is currently an ongoing discussion on  
ale...@li... talking about how  
Cross-platform GUI issues should be handled)

It should allow someone to take the pieces they need for their own  
project, be it a map editor in need of a viewer, or a new game project  
that could use the renderer, but which plans to replace or augment the  
monster behaviour.

As I stated to the AlephModular development list: "Yes we have a dated  
2.5D engine, gosh darn it, but we're going to try and make it the best  
it can be"


As for starting with Bungie's code. I felt a back to basics approach  
was needed. Cross platform code was not neatly added to AlephOne.  
AlephOne's files don't have the CVS history that they should. AlephOne  
both has a SourceForge page and doesn't make use of it. AlephOne has a  
mix of neat things, but there's a good number that don't include  
"Playing Marathon" as a reason to be. Just enough things that I felt a  
certain compulsion to try and start a new project because AlephOne was  
not being the project I would like it to be.

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] GUI: 0.4 planning

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

I really need to draw up a diagram of things just so I can keep things 
straight in my head for organization.


Preferences I was thinking of as a relatively platform ignorant core 
object with access to a file and arbitrary groups of data. This would 
have accessors to read/write the data.

Aside of this we would have some code that would list off appropriate 
preferences, fill in any other data that's needed (For instance a list 
of external map files to select from)

And then we'd need some code to actually display a dialog box.


Unfortunately, I seem to have just lost the ability to compile 
AlephOne-SDL again. Or I'd go check out the setup network game dialog. 
Codewise I'm not quite seeing what you were getting at. I see a lot of 
SDL code for assembling its dialog box.
...
Ah I see. You have to create the dialog box using SDL code. But to 
actually tie the controls to current values you're able to overload an 
existing function... fill_in_game_setup_dialog(...)

A useful refinement of each GUI for themselves. A half step towards 
what I was thinking of for Cross-platform code. (Which would be one 
dialog description and poof, there it is for each platform.)

-Jeremy

Re: [Alephmodular-devel] GUI: 0.4 planning

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

I'd tend to think that the cross-platform (SDL) stuff should be the 
"default", with the Mac OS-specific stuff as one special case, rather 
than vice versa as A1 seems to believe.

(Note that A1/SDL works fine on Mac OS X, but since the Carbon has a 
somewhat nicer UI it's the preferred version.)

Anyway, as far as polish, that's clearly what the platform-specific 
stuff is for, and as for reinventing the wheel, well I think Christian 
Bauer and I already did that with the SDL-based dialog widget stuff for 
A1.

So I think we should have cross-platform (shared) routines that do 
things like "set the values of the controls to values from the 
preferences", "change the enabled states of various controls when other 
controls' values change", "extract the values of controls into the 
preferences", etc.  The platform-specific routines then map primitives 
like "enable control" or "set control value" to the platform-specific UI 
code.  Again I'll refer you to dialogs like Setup Network Game in A1 for 
how this might look in practice.  Naturally ideally it would be even 
cleaner, without those occasional #ifdefs cluttering up the 
cross-platform routines...

Hmm I'm maybe still not quite being clear.  I'm thinking of two separate 
things here:

1.  Splitting UI code into shared "logic" routines and 
UI-widget-library-specific primitives
2.  Providing a set of those UI-widget-library-specific hooks for the 
SDL widget system, as a baseline default UI for all platforms, and 
providing a set for Carbon as a specialized, nicer Mac OS-specific UI 
for Mac users

Likewise, for file handling, the baseline should be some sort of 
single-fork-based scheme, and there can be a Mac OS specialization that 
lets some things live in resources for compatibility with existing files.

As for files again though, right there should be specific objects that 
are responsible for loading data?  So that additional loaders can be 
added later for other file formats.  This can be a layer separate from 
the basic routines that deal with physical data containers 
(single-forked files, Mac OS files, in-memory data, etc.).  There should 
be a nice "data container" abstraction to make all of these look alike 
to the loaders.

As for where the physical containers are located, well that's a 
platform-specific detail.  :)  For example, Windows probably wants user 
data stored somewhere and static (game) data stored somewhere; Linux 
would probably put each one in a different spot, as would Mac OS X, as 
would Mac OS 9.  So, maybe there should be a "Platform" object that is 
able to provide information like "where does user data go?" and "where 
should I look for game data" and "what default user name should I use?" 
and "what UI system should I use?".

You know, so there's an abstract superclass (basically a Java 
"interface" or an Objective-C "protocol") Platform that defines the 
names of the methods for the above etc.  Then the Mac OS version is 
built with a MacOSPlatform subclass that provides the MacOS-specific 
implementations (maybe some of which change their behavior at runtime 
based on whether it's running 9 or 10.1 or 10.2 etc.); the Windows 
version is built with a WindowsPlatform subclass, etc.

I suppose there's not strictly a need to use the class mechanism for 
this sort of thing; you could just have a header file with the interface 
and link in different implementations on different platforms.  But using 
the explicit class mechanism would allow e.g. two implementations to be 
linked in but only one chosen at runtime.

Object creation should be done by some sort of 'factory' mechanism, so 
that e.g. one type of object can substitute for another easily with the 
factory deciding which to use, instead of potentially having to hunt 
through later for all the 'new's or malloc()s and have the "how to 
allocate object" logic spread all around.  So you'd do something like 
'Factory::GetInstance()->CreateProjectile()' instead of 'new Projectile' 
or '(Projectile*)malloc(sizeof(Projectile))'.  So if you're playing 
MyFancyGame, Factory::GetInstance() returns a MyFancyFactory, which 
returns a MyFancyProjectile instead of a boring old M2 Projectile.  (You 
wouldn't do Factory::CreateProjectile() because then you're always 
getting Factory's implementation.)  Of course, the Factory could be one 
part of a bigger object (like a Game object or something), or it could 
be split up into a few smaller objects (a NetworkObjectsFactory, a 
GameObjectsFactory - and maybe those are part of larger objects - etc. 
etc.).  But anyway, making any kind of standard creation mechanism 
(something greppable) now makes later alterations much easier.

Of course, being able to return a MyFancyProjectile* instead of an 
M2Projectile* may not be too handy if they are just plain old structures.

Woody

On Tuesday, December 24, 2002, at 12:38  PM, Br'fin wrote:

> I must say that the concept of having a Cross-platform API around the 
> currently platform specific dialogs (Preferences, Network prep and 
> finishing) does have its merits. Especially if for whatever reason 
> those elements need to be changed. (General addition of features, or a 
> project wanting to add their own preferences)
>
> I find myself either worrying about the polish or worrying about 
> reinventing the wheel.
>
> Hsm, just had an idea.
>
> How reasonable is it to say for now 'each GUI implements their own UI' 
> with a note to have someone later come back and work on an additional 
> GUI which hits the cross-platform points better?
>
> Alternatively, each GUI implements their own UI and then we all swap to 
> SDL when it feels like it has enough polish.
>
>
> Mmm, thoughts on Cross-platform resources? Most notably text strings in 
> marathon2.resource, pop up menu lists, and dialog texts? I suppose in 
> addition this would include 'Just where would SDL resources go?'

[Alephmodular-devel] GUI: 0.4 planning

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

I must say that the concept of having a Cross-platform API around the 
currently platform specific dialogs (Preferences, Network prep and 
finishing) does have its merits. Especially if for whatever reason 
those elements need to be changed. (General addition of features, or a 
project wanting to add their own preferences)

I find myself either worrying about the polish or worrying about 
reinventing the wheel.

Hsm, just had an idea.

How reasonable is it to say for now 'each GUI implements their own UI' 
with a note to have someone later come back and work on an additional 
GUI which hits the cross-platform points better?

Alternatively, each GUI implements their own UI and then we all swap to 
SDL when it feels like it has enough polish.


Mmm, thoughts on Cross-platform resources? Most notably text strings in 
marathon2.resource, pop up menu lists, and dialog texts? I suppose in 
addition this would include 'Just where would SDL resources go?'

-Jeremy Parsons

Re: [Alephmodular-devel] Re: 0.4 Planning and future

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

Hey umm, I was just re-reading the message I just sent, and the tone 
often comes off as a bit unpleasant I find.  Please understand that I 
guess I was just being a bit more blunt than usual, and intend no 
offense to the rest of you folks.  I find most of what's happening here 
to be pretty smart and exciting, so try not to take my comments like 
'poor idea' or 'Bad Idea' as personal attacks etc. :)

Anyway I stand by the content of what I wrote, even if the tone could 
have been improved somewhat.  Sorry.  Looking forward to the continuing 
discussion.

Woody

Re: [Alephmodular-devel] Re: 0.4 Planning and future

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

On Tuesday, December 24, 2002, at 01:56  AM, Chris Bergmann wrote:

> I would tend to split more of the GUI out as platform-independent code 
> if possible. Despite the fact that the underlying GUI model may differ 
> between platforms, I don't see that the entire GUI would need to be 
> rewritten. It would be more maintainable to pick a subset of GUI 
> functions which are present (or can be faked) on each of the target 
> platforms - ie. buttons, dialogs, etc. and make these the 
> platform-specific layer.
>
> This would allow us to keep the code for the preferences / main-menu 
> etc. generic. Admittedly it'd be a little bit more work to set up 
> initially (keeping the GUI framework consistent between platforms) but 
> once it's done changes can be made to the GUI without having to make 
> the same set of changes for each target platform (which would likely 
> lead to some platforms lagging behind the main code base and becoming 
> difficult to maintain.)

Actually, I did a lot of this sort of thing already in Aleph One.  
You'll notice it moreso in the netgame dialogs than in the others, since 
I worked with the netgame dialogs a lot more.

The end result felt pretty messy, but at the same time I managed to 
split out quite a bit of shared code.  The SDL dialog support stuff has 
notions of dialog item ID's (which are set to be the same as the Mac OS 
ID's of course) and there are shared routines that enable/disable an 
item based on ID, get/set the state of items by ID, etc. etc.

So anyway, I agree that there should be a low-level/high-level 
(platform-specific/platform-independent) UI separation.  ;)

> In cases where insufficient built-in GUI support exists (on a console 
> or whatever) the GUI framework could be entirely based on OpenGL or 
> some other graphic layer. This code in itself would be portable to any 
> platform assuming the graphic layer is slightly abstracted (not a 
> difficult task) and would ease the porting of the game to new platforms 
> until such time as the "normal" GUI code is completed.

Note that the SDL dialog system works on any platform with SDL.  So what 
you've suggested here is already available also.

> Also, on the flip-side to all of that, you could move the entire 
> main-menu / preferences GUI into a separate "application" which acts 
> like a launcher for the game "application" (be this through separate 
> executables or whatever.) This separates the GUI development completely 
> from the game development, which is possibly a good thing since it 
> would make the division of labour a lot easier. It may or may not be as 
> friendly for the users, depending on how well it's implemented.

I am not too big on this idea because of the possibility that the user 
experience could easily become unpleasant.

> It's fairly evident that the current networking code is not useful for 
> WAN games  (and not great for larger LANs, probably.)

What's the problem with larger LANs?

I agree that WANs typically exhibit much less favorable latency 
characteristics, so you're right that the current code is not terribly 
WAN-friendly.

>  It's easy enough to replace it with a better model, however marathon 
> is based around the concept that everyone is perfectly in synch, 
> always. Stripping that out may be fairly simple also - it means 
> changing the ownership of individual entities in the gameplay from 
> "each machine does its own thing because we know they'll get the same 
> result" to "each machine does its share of the work and then lets all 
> the other machines know about any state changes. This especially 
> affects things like the AI and map constructs such as Platforms, etc.

No offense, but this strikes me as a Bad Idea.  There are three basic 
models I guess along these lines:

1.  Server is authority for everything (most current networked games)
2.  Each machine is authority for some elements (your proposal)
3.  No machine is an authority (the current Marathon scheme)

(1) is the most secure against hacked clients etc.  (3) is next in line 
because the extent to which a hacked client can do damage is to show the 
player more information than he deserves or to help automate the 
player's actions (aiming etc.) through the existing input mechanism.  
(If it tries to change other stuff, it will fall out of sync.)  (2) is 
least secure because a hacked client could change anything it wanted to 
about the parts of the game it's assigned, and the other clients would 
just have to live with it.

(2) also strikes me as the most complex to manage and as the one 
requiring the most communication between machines, with (1) following 
far behind and (3) the easiest.

So I could see planning ahead for letting someone add 
server-is-authority code at a later date, but I'm not sure I'd invest 
much in supporting the 'everyone's an authority on something' scheme.

BTW while I'm thinking of it, Br'fin wrote:
> 	network
> 		ethernet

I think 'ethernet' is a fairly poor name to use.  'AppleTalk' would be 
appropriate.  If using IP-ring stuff, well then probably 'IPring' would 
be a good name.  You could call it 'IPring-SDL' or have an SDL 
subdirectory or something if you want to emphasize its dependencies.

> Game Loop
>
> Probably the simplest thing to do here is to simply use a timer, eg:
>
> ...
>
> Keyboard input may need to be queued with some timing information taken 
> into account but that's really a separate issue to the physics timing.

It's my impression that what you're describing here is almost exactly 
what Marathon already does.  Hmm, well, almost.  Instead of having a 
real-time timer that determines how many physics-updates to do, it 
counts the number of action_flags it has available from the input 
routine (which is a separately-scheduled, high-priority, periodic task) 
or network subsystem.  Since each action_flag conceptually captures one 
game-tick's actions, the number of action_flags indicate the amount of 
time that's elapsed.

Please point out the differences so we can talk about them if I'm not 
right.  (And, if you look in the engine development documents area on 
source.bungie.org, you can read my analysis of the current input scheme.)

Hmm, I should scare up and post the stuff I wrote to Br'fin about 
networking and prediction and smooth-rendering interpolation etc.  
Soon.  :)  But it's busy here with the holiday.

Woody

Re: [Alephmodular-devel] Re: 0.4 Planning and future

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

On Tuesday, December 24, 2002, at 02:56  AM, Chris Bergmann wrote:

> GUI
>
> I would tend to split more of the GUI out as platform-independent code 
> if possible. Despite the fact that the underlying GUI model may differ 
> between platforms, I don't see that the entire GUI would need to be 
> rewritten. It would be more maintainable to pick a subset of GUI 
> functions which are present (or can be faked) on each of the target 
> platforms - ie. buttons, dialogs, etc. and make these the 
> platform-specific layer.
>
> This would allow us to keep the code for the preferences / main-menu 
> etc. generic. Admittedly it'd be a little bit more work to set up 
> initially (keeping the GUI framework consistent between platforms) but 
> once it's done changes can be made to the GUI without having to make 
> the same set of changes for each target platform (which would likely 
> lead to some platforms lagging behind the main code base and becoming 
> difficult to maintain.)
>
> In cases where insufficient built-in GUI support exists (on a console 
> or whatever) the GUI framework could be entirely based on OpenGL or 
> some other graphic layer. This code in itself would be portable to any 
> platform assuming the graphic layer is slightly abstracted (not a 
> difficult task) and would ease the porting of the game to new 
> platforms until such time as the "normal" GUI code is completed.
>
> Also, on the flip-side to all of that, you could move the entire 
> main-menu / preferences GUI into a separate "application" which acts 
> like a launcher for the game "application" (be this through separate 
> executables or whatever.) This separates the GUI development 
> completely from the game development, which is possibly a good thing 
> since it would make the division of labour a lot easier. It may or may 
> not be as friendly for the users, depending on how well it's 
> implemented.

I found myself thinking of there being one preferences file used by the 
application with conceptually the preferences GUI being handled as 
almost a separate application within it.

I'm also not very familiar with cross-platform GUI support. My 
ignorance here could be a factor. So my choices are between something I 
don't know how to plan for very well, and trying to leave room for 
someone to polish their GUI as long as I can really polish mine. I 
don't think it's a bad concept as it might allow a specific project to 
build more quickly on another platform with modified features.


> Networking
>
> It's fairly evident that the current networking code is not useful for 
> WAN games  (and not great for larger LANs, probably.) It's easy enough 
> to replace it with a better model, however marathon is based around 
> the concept that everyone is perfectly in synch, always. Stripping 
> that out may be fairly simple also - it means changing the ownership 
> of individual entities in the gameplay from "each machine does its own 
> thing because we know they'll get the same result" to "each machine 
> does its share of the work and then lets all the other machines know 
> about any state changes. This especially affects things like the AI 
> and map constructs such as Platforms, etc.

I was thinking a little more along the lines of one machine serving as 
dedicated server and handling each game tick. Woody himself has had 
some very good ideas with regards to networking. I'm not sure how I 
feel about trying to figure what each machine itself should be doing.

> Animation / Rendering
>
> This is one that's a little tricky. In the spirit of modularity, we'd 
> want to be able to take out the Good Olde 2.5D graphics and 
> pre-rendered animation code and swap in a sweet 3D system. 
> Unfortunately if things are replaced on a frame-by-frame basis, we 
> aren't going to get any great results. New (3D) animations will 
> require different timings and may react differently to the game 
> environment (ie. imagine someone wanted to do a death 
> animation/physics system similar to that in HALO. Not only is the time 
> taken for the animation going to change, it's going to change based on 
> the cause of death, the nearby obstacles, other explosions/bodies, 
> etc. The character is moved around rather than staying stationary, 
> etc. A simple example but you get the point.)

Well, even for Marathon 2, the shapes/animation define some of what 
occurs. Keyframes, for instance, which denote when in an animation to 
actually fire a projectile. My thinking was that the physics model will 
need access to the shapes to note the timing of when to fire. (5 ticks 
after beginning 'attack' fire the projectile) So all movement is done 
in the game engine. If you had the ability to make a dying body dance 
with gun fire until it slumped back against a wall, then that would be 
all handled within the physics model as well.

I'm viewing animation as details that the Physics engine doesn't need 
to worry about. With an eye towards performing animation faster than 
the 30 frames per second of the game ticks. With information going one 
way from the physics model and driving the animation. A game server 
could conceptually run as an entirely separate process, accepting user 
input and returning information to update game state. (Whether this 
means broad casting the actions of all entities on the map or merely 
confirming player inputs for the local game state to reinterpret is an 
exercise for later) Locally the GUI would be accepting input, animation 
would be receiving updated game state animation. Then performing 
animation up until the next game update. Animation itself would be 
driving the rendering.

 From the game engine point of view, it's only worrying about the 
object's current behavior. Be it 'running', 'attacking', 'exploding', 
or 'dying in flames while falling' If we want to get a really detailed 
animation system with bodies that turn into rag dolls before tumbling 
off a ledge, then we should probably skip the animation system and 
instead focus on changing the way Marathon's tick counter and input 
handling queue works.

Revamping the Marathon engine to be kick-ass 3D is low on my 
priorities. I can understand updating the engine to do its rendering 
using OpenGL. But I don't see the draw in replacing everything with 
highly detailed models. Or why, if you really want kick ass 3D and 
highly detailed models, you're looking at Marathon to provide it.

I'd rather say "Yes we have a dated 2.5D engine, gosh darn it, but 
we're going to try and make it the best it can be" and provide 
opportunities for people to make all sorts of games that use it. Not 
necessarily FPS.

-Jeremy Parsons

[Alephmodular-devel] Re: 0.4 Planning and future

[Chris B. <zzk...@uq...>]

Below are some of my thoughts on techniques that could be used for AM 
and problems we might encounter. Go ahead and rip it to shreds, you 
know you want to ;-)

chris



GUI

I would tend to split more of the GUI out as platform-independent code 
if possible. Despite the fact that the underlying GUI model may differ 
between platforms, I don't see that the entire GUI would need to be 
rewritten. It would be more maintainable to pick a subset of GUI 
functions which are present (or can be faked) on each of the target 
platforms - ie. buttons, dialogs, etc. and make these the 
platform-specific layer.

This would allow us to keep the code for the preferences / main-menu 
etc. generic. Admittedly it'd be a little bit more work to set up 
initially (keeping the GUI framework consistent between platforms) but 
once it's done changes can be made to the GUI without having to make 
the same set of changes for each target platform (which would likely 
lead to some platforms lagging behind the main code base and becoming 
difficult to maintain.)

In cases where insufficient built-in GUI support exists (on a console 
or whatever) the GUI framework could be entirely based on OpenGL or 
some other graphic layer. This code in itself would be portable to any 
platform assuming the graphic layer is slightly abstracted (not a 
difficult task) and would ease the porting of the game to new platforms 
until such time as the "normal" GUI code is completed.

Also, on the flip-side to all of that, you could move the entire 
main-menu / preferences GUI into a separate "application" which acts 
like a launcher for the game "application" (be this through separate 
executables or whatever.) This separates the GUI development completely 
from the game development, which is possibly a good thing since it 
would make the division of labour a lot easier. It may or may not be as 
friendly for the users, depending on how well it's implemented.


Networking

It's fairly evident that the current networking code is not useful for 
WAN games  (and not great for larger LANs, probably.) It's easy enough 
to replace it with a better model, however marathon is based around the 
concept that everyone is perfectly in synch, always. Stripping that out 
may be fairly simple also - it means changing the ownership of 
individual entities in the gameplay from "each machine does its own 
thing because we know they'll get the same result" to "each machine 
does its share of the work and then lets all the other machines know 
about any state changes. This especially affects things like the AI and 
map constructs such as Platforms, etc.


Animation / Rendering

This is one that's a little tricky. In the spirit of modularity, we'd 
want to be able to take out the Good Olde 2.5D graphics and 
pre-rendered animation code and swap in a sweet 3D system. 
Unfortunately if things are replaced on a frame-by-frame basis, we 
aren't going to get any great results. New (3D) animations will require 
different timings and may react differently to the game environment 
(ie. imagine someone wanted to do a death animation/physics system 
similar to that in HALO. Not only is the time taken for the animation 
going to change, it's going to change based on the cause of death, the 
nearby obstacles, other explosions/bodies, etc. The character is moved 
around rather than staying stationary, etc. A simple example but you 
get the point.)

What we need is for some useful ways for the animations to communicate 
with the physics/game code (bidirectional - to determine what animation 
to play based on what is happening, and to affect timing, motion etc 
based on the animation (speed, length of stride, etc.) and also with 
the networking code (to tell other machines about what animations are 
happening on this machine.)

It's a fairly simple concept, but i think it may run into trouble when 
we try to match up this kind of system with the original game/physics. 
How to stay true to the original while allowing flexibility is probably 
one of the biggest issues that needs to be tackled.


Game Loop

Probably the simplest thing to do here is to simply use a timer, eg:

prevTime = GetTime();
physicsTime = prevTime;

while (playing)
{
	RenderFrame();
	
	newTime = GetTime();
	deltaTime = newTime - prevTime;
	prevTime = newTime;
	
	numPhysicsFrames = (int)(deltaTime / timeslicePerPhysicsFrame);
	
	if (numPhysicsFrames > 0)
	{
		physicsTime += numPhysicsFrames * timeslicePerPhysicsFrame;
	
		// if we for some reason pause for a long time, it's better to "lose" 
that much time rather than
		// spend ages trying to catch up or run ultra-fast for a number of 
frames to catch up.
		// this generally wont happen in normal gameplay, it's just a 
failsafe clause.
		numPhysicsFrames = MIN(numPhysicsFrames, maxPhysicsFramesPerCycle);
	
		UpdatePhysics(numPhysicsFrames);
	}
	
	UpdateAnimations(deltaTime);
	...
}

Keyboard input may need to be queued with some timing information taken 
into account but that's really a separate issue to the physics timing.

[Alephmodular-devel] 0.4 Planning and future

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

I've been making slow progress in converting all the shorts and longs  
to be a more platform neutral int16 and int32 as part of 0.3 (And  
trying to remember what other things I might like for developers in  
basic mass edits at the moment)

Anyhow, I believe my initial concept had been to settle platform issues  
for 0.4 and then settle modular issues for 0.5. And recently I realized  
that this is probably backwards. We might want to have a plan for  
platform specific issues currently, however if we do anything now, then  
we'll just be tripping over those same changes for 0.5

If we settle modular issues for 0.4, then platform specific issues  
should fall under the realm of adding new files, not rearranging  
existing ones.

Anyhow, I was musing over specific modules. And I was also musing over  
the scope of certain modules.

The main divide is between the game elements and the GUI elements. With  
most of the GUI elements being platform specific.

GUI
	Preferences application
	Main menu
	Load/Save dialogs
	Display lib
	Input handling
	Sound handling

Game specific
	Game Core
	Animation
	Rendering
	Files
	Networking

This isn't to say that Files and Networking are platform generic in and  
of themselves. But they are separate from the GUI. For instance, a game  
server would have need for files and networking, but have no use at all  
for a gui, rendering, or animation.

I do believe that these things can be implemented roughly one or two at  
a time as well.

A rough order might be
	Modularizing basic file capabilities
	Modularizing basic display capabilities
	Modularizing sound handling
	Modularizing preferences
	Modularizing gui
	Modularizing game elements
	Modularizing networking

A rough layout of the source directory might look like

source
	gui
		shared/base gui defines
		macosx
			preferences
			shell
			interface
			etc
	support
		astream
		cross platform files
			(Ifdefs within for different platforms)
	game
		monsters
		physics
	network
		ethernet
	rendering
		software

Some things to note

The CSeries code has a strong possibility of being pulled apart. Some  
parts, like macros and types should go into support. Other parts, like  
dialogs and alerts are better put into either shared gui definitions or  
left platform specific.

Animation is separated from game core. The main goal of this would be  
to let the two have separate tick counters. So a game_tick always  
happens 30 times a second. But animation could either be dropping  
frames or drawing excess frames over and above 30 frames a second and  
smoothing by interpolation. (Monster was at point X, is moving towards  
point Y, we're drawing a frame eery 1/3rd of a game tick, so we'll  
first draw it at 1/3rd the way from X to Y) From speaking with Woody  
this separation also seems like it could aid in clearer networking. Or  
at the very least would be similar to the way Doom appears to operate.  
A game server that you connect to, even if running the game locally.
This might introduce a off by one game tick delay, though this doesn't  
seem like a major problem.

I'm not sure how to separate the way the main game loop operates with  
how it might be best to implement for different platforms. I do know  
that handling input in a vbl thread has proved problematic for MacOSX.  
Specifically for Mouse input handling. But cropping up in a couple  
other ways as well in the interaction between mouse and GUI.

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] OSX: Temporarily lost keyboard input

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

Most annoying occurence. I was working on AlephModular. Changing all  
the shorts and longs in one header file to int16 and int32 and then  
suddely I ran AlephModular and wham, no keyboard input, even after back  
tracking a little.

Logging out then back in and *poof* everything works fine.

Must have gotten some bad state within the Carbon library with regards  
to getkeys or something. Definitely annoying and worrisome to encounter  
though.

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] Web site

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

On Saturday, December 21, 2002, at 07:31  AM, Matt Lee wrote:

> I did just that, and found that they are flexible enough to do pretty  
> much anything I want. For now, though, I just put together a simple  
> html/css page. You can view it here:
>
>    http://alephmodular.sourceforge.net/new/
>
> It uses XHTML 1.1 and CSS 2, which naturally means it's not  
> pixel-perfect across platforms. It works everywhere I've looked so  
> far, but is slightly odd looking in IE 5.2.x for OS X. (Looks best in  
> Gecko-based browsers like Chimera.)
>
> Let me know if you like it, or if you think it needs tweaking, or  
> especially if you think it's simply horrible. I still need to test it  
> in IE5.x/Win, since it's notorious for messing up CSS layouts.
>
> Oh, and most of the links work, but a few don't, like the FAQ, the  
> roadmap, or the "how to check out AM from CVS" stuff. I plan to work  
> on that stuff later, once the main page is done.
>
> -Zebe

I must say that it's a pretty decent looking first draft. At the very  
least it looks like something which can't really be said for the  
original placeholder I tossed up :)

-Jeremy

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] Web site

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

I wrote:
>I'll investigate what's possible on the SourceForge server and 
>decide that way.

I did just that, and found that they are flexible enough to do pretty 
much anything I want. For now, though, I just put together a simple 
html/css page. You can view it here:

    http://alephmodular.sourceforge.net/new/

It uses XHTML 1.1 and CSS 2, which naturally means it's not 
pixel-perfect across platforms. It works everywhere I've looked so 
far, but is slightly odd looking in IE 5.2.x for OS X. (Looks best in 
Gecko-based browsers like Chimera.)

Let me know if you like it, or if you think it needs tweaking, or 
especially if you think it's simply horrible. I still need to test it 
in IE5.x/Win, since it's notorious for messing up CSS layouts.

Oh, and most of the links work, but a few don't, like the FAQ, the 
roadmap, or the "how to check out AM from CVS" stuff. I plan to work 
on that stuff later, once the main page is done.

-Zebe

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

Re: [Alephmodular-devel] Web site

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

>I was getting errors on SourceForge when I tried. I open
>a support letter, no response on it yet.

I just reloaded the page and it lists my name now, so I guess it is 
all set. Thanks.

>*Laugh* Don't know how much we need to put on the site. I've not
>really had any sort of clear picture of it. Have you thought about
>what you want the site to emphasize or organize? Basic news 
>elements, for instance, can be put on the Sourceforge summary page.

Yeah, at first glance, a dynamic page does seem like overkill. But I 
do think AM has a big future, at least, I'm currently more hopeful 
for it to be the Marathon I want than I am for A1, long term. :)

I'll investigate what's possible on the SourceForge server and decide that way.

-Zebe

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

Re: [Alephmodular-devel] Some questions about the current code.

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

On Friday, December 20, 2002, at 03:37  AM, Matt Lee wrote:

> Br'fin wrote:
>> So I registered a creator code with Apple.
>> AMdl  (Hex) 414D646C
>
> For the heck of it, I grabbed the new branding stuff from CVS and  
> rebuilt 0.2+. It Still Works(tm).

Oh good. It doesn't get everything, mostly the icons and the creator  
type. There's still text resources that refer to Marathon for instance  
that I haven't touched.

> I wasn't around when Aleph One was first being developed from Marathon  
> 2, so the early stages of improvement are new to me. Two things I've  
> noticed about the current code: One, pressing Escape doesn't seem to  
> exit to the main menu, as in Moo and A1. If there's a way to do this  
> without quitting and relaunching the app, I've missed it. Can this be  
> scheduled for 0.3?

Yeah, you already picked up on it, Command-W to exit back to the main  
menu. I expect all of the basic UI polishing to be late in the work of  
0.5. AlephModular plays alright now and that's the main thing. 0.5 or  
so is where all the heavy lifting of breaking things apart is. And  
that's when we should both define 'How does the platform specific GUI  
module tie into the game' and actually implement it for at least MacOS  
X.

I didn't think it was that important to polish things yet, not when we  
were planning on ripping them all aprt and rebuilding them better,  
faster and stronger.

> Two, when I ask AM to report its frame rate, it shows me a constant  
> speed in the upper 20's to a perfect 30. (I'm running on a G4/400).  
> This is regardless of the settings I use, which is to be expected  
> given the generation of hardware I'm using. However, the perceived  
> performance is much lower than 30, it's more like 10 to 15.
>
> Is this due to OS X weirdness? If so, how does A1 get around it?  
> Setting the resolution to Low appears to have the greatest improvement  
> (perceived speed ~30 fps, with 100% screen size, Millions depth, all  
> sound options on). I recognize that this may be the type of thing  
> that's pushed out several releases... I'm more curious than anything.

Most likely it's due to the OSX double buffering of the gui window. (OS  
X Weirdness) And because Marathon was internally buffering the view  
window, then now we're dealing with an accidental triple buffering.

And no, A1 doesn't actually get around this. Not in software mode.  
OpenGL itself probably hooks to operate around the double buffering.  
And since most machines that can run OSX can generally run the OpenGL  
as used by Marathon... there's the A1 gets around it.

I want some better abstraction around the screen buffers that Marathon  
uses. Something that can deal with 'draw a 640x480 screen in the middle  
of this 1024 x768 buffer' or 'draw a 640 x 480 screen in this buffer of  
the same size' and then it's the display library that is either sending  
that output to a window's immediate buffer or is sending it to a  
DisplaySocket full screen connection or what have you.

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] Web site

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

On Friday, December 20, 2002, at 03:30  AM, Matt Lee wrote:

>> Well, I tried to sign you up as a developer. I'm still waiting for  
>> Sourceforge to tell me it failed or succeeded, so I'm not sure what's  
>> up with that.
>
> It seems like maybe it failed? I am new to SF, but I just logged in  
> again today and it says I have no active projects.

I was getting errors on SourceForge when I tried. I open a support  
letter, no response on it yet.

>> I think for the first take we could put everything in a sub directory  
>> so you can look at it while you work on it. And once a first draft is  
>> ready we can see about getting it into CVS and then put up as the  
>> front page.
>
> That sounds like a good plan. But how it is integrated into CVS  
> depends on what type of site gets implemented.
>
> Should we have a blog on the front page that people can post to with  
> status updates (similar to source.bungie.org, I guess, except it'd  
> allow posting by any developer rather than just Jesse), or a simple  
> static HTML page that we update manually?
>
> The former is more flexible, but also more complicated. I'm working  
> with Movable Type (a blog package) on another Web site right now.  
> Perhaps, if we were to use that, we could simply check in the HTML and  
> CSS templates used within MT.
>
> Opinions welcome. I can do either. A Movable Type installation  
> (assuming it's possible on sourceforge) is a little more painful  
> initially, but very elegant once done. A static HTML page I can throw  
> up in a night, but it's a nearly equivalent amount of work each time  
> it gets updated.

*Laugh* Don't know how much we need to put on the site. I've not really  
had any sort of clear picture of it. Have you thought about what you  
want the site to emphasize or organize? Basic news elements, for  
instance, can be put on the Sourceforge summary page.

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

Re: [Alephmodular-devel] Some questions about the current code.

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

I blathered on about:
>pressing Escape doesn't seem to exit to the main menu, as in Moo and 
>A1. If there's a way to do this without quitting and relaunching the 
>app, I've missed it. Can this be scheduled for 0.3?

Nevermind, I found the relevant post on the A1 list about pressing 
Cmd-W to exit the current game. Consider me RTFM'ed on that point.

-Zebe

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

[Alephmodular-devel] Some questions about the current code.

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

Br'fin wrote:
>So I registered a creator code with Apple.
>AMdl  (Hex) 414D646C

For the heck of it, I grabbed the new branding stuff from CVS and 
rebuilt 0.2+. It Still Works(tm).

I wasn't around when Aleph One was first being developed from 
Marathon 2, so the early stages of improvement are new to me. Two 
things I've noticed about the current code: One, pressing Escape 
doesn't seem to exit to the main menu, as in Moo and A1. If there's a 
way to do this without quitting and relaunching the app, I've missed 
it. Can this be scheduled for 0.3?

Two, when I ask AM to report its frame rate, it shows me a constant 
speed in the upper 20's to a perfect 30. (I'm running on a G4/400). 
This is regardless of the settings I use, which is to be expected 
given the generation of hardware I'm using. However, the perceived 
performance is much lower than 30, it's more like 10 to 15.

Is this due to OS X weirdness? If so, how does A1 get around it? 
Setting the resolution to Low appears to have the greatest 
improvement (perceived speed ~30 fps, with 100% screen size, Millions 
depth, all sound options on). I recognize that this may be the type 
of thing that's pushed out several releases... I'm more curious than 
anything.

Still having fun playing M2 again.
-Zebe

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

Re: [Alephmodular-devel] Web site

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

>Well, I tried to sign you up as a developer. I'm still waiting for 
>Sourceforge to tell me it failed or succeeded, so I'm not sure 
>what's up with that.

It seems like maybe it failed? I am new to SF, but I just logged in 
again today and it says I have no active projects.

>I think for the first take we could put everything in a sub 
>directory so you can look at it while you work on it. And once a 
>first draft is ready we can see about getting it into CVS and then 
>put up as the front page.

That sounds like a good plan. But how it is integrated into CVS 
depends on what type of site gets implemented.

Should we have a blog on the front page that people can post to with 
status updates (similar to source.bungie.org, I guess, except it'd 
allow posting by any developer rather than just Jesse), or a simple 
static HTML page that we update manually?

The former is more flexible, but also more complicated. I'm working 
with Movable Type (a blog package) on another Web site right now. 
Perhaps, if we were to use that, we could simply check in the HTML 
and CSS templates used within MT.

Opinions welcome. I can do either. A Movable Type installation 
(assuming it's possible on sourceforge) is a little more painful 
initially, but very elegant once done. A static HTML page I can throw 
up in a night, but it's a nearly equivalent amount of work each time 
it gets updated.

-Zebe

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

[Alephmodular-devel] We have a creator code.

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

As part of 0.3 I thought it might be appropriate to brand what we  
distribute. For 0.2 AM is essentially Marathon 2 except that while it  
uses Marathon's creator code on files, it doesn't really write the same  
format for preferences and save games.

So I registered a creator code with Apple.

Application Signatures:
AMdl  (Hex) 414D646C

Nothing terribly cute or interesting.

-Jeremy Parsons
--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] Current application directory... OSX

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

I was just futzing with things for another project and found a  
different way to get 'the directory the application is in.' Instead of  
working from GetProcessInformation it starts with GetMainBundle and  
asks for the URL of that. (Then takes the directory of that since that  
would point to application.app)

Now, I was wondering, does anyone know what the recommended way of  
finding the application's current directory is?

-Jeremy Parsons
--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] Web site

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

Hi again,

I signed up for a sourceforge users account ("zebe"). If you want, I 
could throw together a Web site for AM. I'm a little busy this week 
but I should have some time. Let me know.

-Zebe

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

[Alephmodular-devel] Grrf on types in preferences.cpp

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

trying to cleanup the conversion warnings in preferences.cpp and found  
this most annoying case:

...
	/* If we didn't open, we initialized.. */
	graphics_preferences= get_graphics_pref_data();
	player_preferences= get_player_pref_data();
	input_preferences= get_input_pref_data();
	sound_preferences= get_sound_pref_data();
	serial_preferences= w_get_data_from_preferences(prefSERIAL_TAG,
		sizeof(struct serial_number_data), default_serial_number_preferences,
		validate_serial_number_preferences);
	network_preferences= w_get_data_from_preferences(prefNETWORK_TAG,
		sizeof(struct network_preferences_data), default_network_preferences,
		validate_network_preferences);
	environment_preferences= get_environment_pref_data();
}

struct preferences_dialog_data prefs_data[]={
	{ strPREFERENCES_GROUPS, graphicsGroup, ditlGRAPHICS,  
get_graphics_pref_data, setup_graphics_dialog, hit_graphics_item,  
teardown_graphics_dialog },
	{ strPREFERENCES_GROUPS, playerGroup, ditlPLAYER,  
get_player_pref_data, setup_player_dialog, hit_player_item,  
teardown_player_dialog },
	{ strPREFERENCES_GROUPS, soundGroup, ditlSOUND, get_sound_pref_data,  
setup_sound_dialog, hit_sound_item, teardown_sound_dialog },
	{ strPREFERENCES_GROUPS, inputGroup, ditlINPUT, get_input_pref_data,  
setup_input_dialog, hit_input_item, teardown_input_dialog },
#ifndef DEMO
	{ strPREFERENCES_GROUPS, environmentGroup, ditlENVIRONMENT,  
get_environment_pref_data, setup_environment_dialog,  
hit_environment_item, teardown_environment_dialog }
#endif
};
#define NUMBER_OF_PREFS_PANELS (sizeof(prefs_data)/sizeof(struct  
preferences_dialog_data))
...

The first batch of complains currently because get_*_pref_data returns  
a void* (And all the variables are typed pointers) And the second batch  
of code, the prefs_data is expecting argument functions of the form  
void*(*func)() (the functions as they currently are and as they return  
void pointers)

I could just put static_cast<appropriate*>(get_*_prefs_data()) in the  
first batch. It solves the warning problems, but certainly doesn't feel  
like the 'right' solution to this.

-Jeremy Parsons
--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] URL on typecasting safer in C++

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

I was looking into dealing away with some of the compiler warnings and  
also trying to tighten up some of the typecasting done in the code.

I came upon this URL.

Casting in C++: Bringing Safety and Smartness to Your Programs
http://www.cs.rpi.edu/~wiseb/xrds/ovp3-1.html

This probably means I will be doing static_casts in code where I can't  
get around the lack of a typecast.

I had some problems with typecasts during the Carbonization process.  
It's no longer safe to typecast WindowPtrs to GrafPortPtrs and the  
existing code had been doing *just that*
So I'm a leetle bit paranoid. :)

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] Grrrf. RazzinFragin *_definitions...

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

Well, i thought it might be nice to enable the command line tools that  
the marathon2 source came with. Not that they do much with our existing  
M2 editors for shapes and physics.

But I hit a major snarl between needing to serialize things, the way  
things were protected from other realms before. And the need for  
different access to these things.

In order to build export_definitions (Dumps the default hard coded  
physics to a file) I found myself trying to pull in more and more of  
the code. (It worked before simply because all it needed was the length  
of the info and it could just dump the bytes)

As such I'm punting on the tools as targets for now and will simply try  
and use this information to help educate where we draw the lines  
between things in order to keep programs smaller and simpler but not  
needing to include things they don't need.

-Jeremy Parsons
--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------