alephmodular-devel — AlephModular Developers Mailing List

Re: [Alephmodular-devel] Developer Rant #1 :)

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

On Tuesday, January 14, 2003, at 12:30  PM, Woody Zenfell, III wrote:

> If you only care about your machine, I don't see where you're going to 
> get help (assuming you want it at some point).

The idea is that *everyone* wants to keep it running nicely on *their* 
machine and then gather all the tweaks in one package :)

>>  I've now carbonized Marathon twice and I want something that runs 
>> really nice and well.
>
> And now it sounds like you're expecting others to re-IPify, 
> re-OpenGLify, re-SDLify, etc. your code, when these tasks (well maybe 
> not IPification - not sure) are bigger tasks than Carbonification.

I thought that was the original idea behind AM: Convert Marathon to a 
stable app based on modern design and architectural ideas (from the 
mess of undocumented C it is right now) to pave the way for new 
functionality, then add the new functionality later when it can be done 
cleanly and easily.

> Hope you can find people to do that.  From my point of view, it's not 
> worth it to try to replicate all that work if we're just going to end 
> up in the same place as A1 (which we are, if the cross-platform code 
> (standard libraries and SDL) is not tapped as the preferred branch).

There should be no "preferred" branch. There is high-level game code 
which should be 100% platform agnostic and low-level platform code 
which is necessarily restricted to 1 platform.

> (Of course this is essentially the same argument as for using standard 
> library calls and SDL instead of Mac OS calls whenever possible, 
> though they are different issues.  Shared code, not separate branches. 
>  Shared code, not separate branches!!)

Of course, the flip side of that is, what if we *do* want to take 
advantage of features only available on 1 platform? There was an 
enormous argument on the A1 list over whether plain XML or Apple's 
property list format should be used for the preferences file, the 
primary arguments being the former was cross-platform and the latter 
was much easier on a Mac. If the preferences code was properly modular, 
it would have been possible to write a MacOS-specific plist loader and 
an XML loader for everything else. And what if we want to use something 
like Quicktime, which is probably far more powerful than SDL's media 
handlers? Or Direct3D on Windows?

As for the specific example, I think the cut would be in the 
implementation of *get*_control_value. In fact, there would be no 
get_control_value call at all; there would be an (e.g.) get_screen_size 
call exposed from the preferences module which corresponds to some 
other call inside the module that obtains the value from the GUI or the 
preferences database. There wouldn't be a set_control_value call 
either, there would be a set_screen_size called by (e.g.) pressing F1 
that would update the platform-specific elements.

> I don't suppose you've considered sharing your findings with the A1 
> project so that it can also benefit...?  Or are you only talking about 
> that close-monsters-disappearing thing?

Sharing suggestions is fine, but it's inevitable that A1 and AM diverge 
sufficiently (if all goes well) that sharing code would be useless.

> I still wonder whether AM is necessary, or whether restructuring A1 
> would be as effective at achieving the AM goals while maintaining all 
> the nice features of A1.  I don't know that answer, and it's moot 
> anyway since we have someone working on AM and nobody doing the 
> corresponding work for A1.  :)

The problem is that A1 has pretty much painted itself into a corner and 
the effort of adding all these nice features would be more than that 
expended to bring AM up to A1's level and then adding the features :)

--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] Developer Rant #1 :)

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

Yes, I'm skipping all the point by points. I'm willing to discuss them, 
but trying to argue them right here right now seemed liked leaning 
towards too much potential for a flamewar. Woody is right in terms of 
me needing other developers. so while I may have to be a project 
manager and draw some lines, I can't afford to run all the potential 
developers away. :)

I must say that I am honestly baffled by the reaction to my treatment 
of SDL as another platform. I'm not advocating rewriting the core of 
Marathon using cocoa after all. I think I'm advocating a platform 
neutral core. Will this be recreating the wheel in some ways? Perhaps. 
But not to a degree I find unacceptable.

>> This doesn't mean that I'm ignoring all bugs, just the ones relating 
>> to the GUI in its current state. Crashing bugs or other glitches 
>> within the game core are definitely a priority. I find it interesting 
>> that in recent days I've patched several bugs in AM that either are 
>> still noticeable in AO if you know where to look or have been 
>> addressed only relatively recently. Make of my focus what you will.
>
> I don't suppose you've considered sharing your findings with the A1 
> project so that it can also benefit...?  Or are you only talking about 
> that close-monsters-disappearing thing?
>
I think the set I have in mind includes the close-monsters-disappearing 
thing. Then a couple software rendering interaction issues: The 
low-res+millions of colors resulting in every other column being drawn. 
And having your attempt to save a game assert if you're using software 
rendering+low-res+small view window.

Almost non-issues considering AlephOne seems to be in the process of 
phasing the software renderer out.

Maybe I'm just feeling jaded too. In AM this morning I fixed the old 
preferences problem.
	../../marathon2/wad.cpp:1326: Assertion failed:
	 entry.length==calculate_raw_wad_length(header, buffer)

The final problem wasn't that big, and the error is actually in the 
assertion's use of calculate_raw_wad_length if entry.length is 
legitimately 0. But AO had that bug for ages and no one looked into it. 
I presume the problem is gone now since AO's preferences are now 
XML-based.

> Or anything anyone can think of, because the idea is that AM will be 
> an easier and more rewarding environment to work in than A1.  Right?  
> I don't think there have been any suggestions contrary to these goals.
>
> Anyway the bottom line is, I think you have good intentions and are 
> doing good work, even if I disagree with a few of the paths you seem 
> to be wanting to take.  (I think I agree with you on many others.)  
> It's your project, and in truth I'll probably be going into Aleph* 
> hibernation again in another week or so, so my opinions don't really 
> matter a whole lot.  As I see it, my job is to make sure you consider 
> as many relevant options as possible; the decisions are yours.
>
> I still wonder whether AM is necessary, or whether restructuring A1 
> would be as effective at achieving the AM goals while maintaining all 
> the nice features of A1.  I don't know that answer, and it's moot 
> anyway since we have someone working on AM and nobody doing the 
> corresponding work for A1.  :)
>
> Woody

I thank you for the feedback too, really I do.

Unknown on the AM versus restructuring A1 issue. At least part of where 
I felt AO had failed was in its CVS management. Plus I could no longer 
be sure whether a behavior was AO amended or original. At which point, 
it just seemed easier to start fresh with Bungie's code. This would 
guarantee that for AM I had a complete history from Bungie's code to 
present.

There were other issues too, relating to cruft. Since shifting to MacOS 
X 10.2.x and PB 2.0.x, I've been unable to figure out how to run AO 
within the debugger. Talk about annoying.

My overall assumption is that if AM can be steered right, then it 
should be possible to adapt things like AO's OpenGL code. And it 
wouldn't be the first time I had shoe-horned things together :)

-Jeremu

Re: [Alephmodular-devel] Developer Rant #1 :)

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

(Sorry if the first few responses seem snippy, try to take them as 
merely "concise" instead.  :) )

On Tuesday, January 14, 2003, at 10:53  AM, Br'fin wrote:

> Since I haven't really gotten myself organized, I'm going to give the 
> list a little bit of an earful.

You're not the first ;)

> I have to admit that the #1 priority on the top of my list is to 
> continue to keep Marathon running nice and happily on my machine.

If you only care about your machine, I don't see where you're going to 
get help (assuming you want it at some point).

>  I've now carbonized Marathon twice and I want something that runs 
> really nice and well.

And now it sounds like you're expecting others to re-IPify, 
re-OpenGLify, re-SDLify, etc. your code, when these tasks (well maybe 
not IPification - not sure) are bigger tasks than Carbonification.

>  And I want updated networking. which I suppose could be odd seeing as 
> I've rarely had chances to play Marathon on a LAN :)

What are you looking for from AM that A1 doesn't have, networking-wise?  
NAT-friendliness?  Ring-to-star?  Text chat before, during, and after 
the game?  Cooperative saved-games?  Latency-hiding?  I think many of us 
want these things, and I think they'll gradually appear.  I'm not sure 
how AM could be a better platform for them than A1 is (except maybe for 
latency-hiding, where low-level support along the lines I recently 
discussed could make things much easier... but adding that low-level 
support might be nearly as painful in AM as in A1).

> Second of all, I want to open up the code in way that it isn't just one 
> monolithic beast. While it may or not ever materialize, I would like to 
> use this code to support other development efforts. This includes tools 
> for itself (map making and such) and game changes beyond scenario and 
> physics making.

Makes sense.

> Then around third is being cross-platform. Yes, I admit it, 
> cross-platform is less important to me than having a kick-ass game of 
> Marathon. However, I do agree that it is important and I will support 
> it. Calls for standardizing on this or that, while good arguments, do 
> not necessarily mesh well with my first two goals. Accept that your 
> platform of choice will be treated as a separate platform, take 
> ownership of it and make sure it remains kick ass too.

Hope you can find people to do that.  From my point of view, it's not 
worth it to try to replicate all that work if we're just going to end up 
in the same place as A1 (which we are, if the cross-platform code 
(standard libraries and SDL) is not tapped as the preferred branch).

But I'd encourage somebody else to do it so I can enjoy the benefits.  ;)

Every line of Mac OS-specific code written or debugged serves only to 
close up AM further and make it less useful to a general audience.  OTOH 
every line of open code (SDL, standard libraries, OpenGL, etc.) serves 
to make AM accessible and useful to a wider audience, to bring it into a 
more modern age, and to ensure its longevity and relevance.  But place 
your priorities where you will.

> With respect to staying in sync API-wise, we should be discussing 
> issues like that to begin with. And include appropriate tracking or 
> document matters on Sourceforge. If something UI-wise gets implemented 
> on one platform and applies to the others, they should get stubbed 
> interfaces if necessary to compile and someone should be responsible 
> for filling out the specific platform.

What I think I'm hearing here is that new additions to the code will be 
more rigorously evaluated and integrated, which is probably a good thing 
as long as it doesn't put a serious clamp on innovation/experimentation.

OTOH I hear a lot of "someone will be expected to" or "someone will be 
responsible for" or "someone will be required to", and I don't know how 
well that will fly in a volunteer effort.  Sure it could work for 
something like gcc that's vitally important to millions of people, but 
for a game with a current worldwide audience of perhaps 50 occasional 
users?  When there's already another project that seems further along in 
most regards?  Well, I guess time will tell.

> Does this mean we should be making wrappers around set control/read 
> control/hit control? Or should we just be doing 
> PLATFORM_GUI->do_preferences(PrefObject)? I admit I both haven't 
> decided and haven't yet had a chance to research this. I'd love a 
> decent run down of the pros and cons of each.

All I'm saying is, it makes sense to me to have the largest amount of 
code possible be shared, so that new development is more likely to work 
on all platforms, so that a given portion of the code base is used by 
more folks and is thus more rigorously tested, and so that things 
generally stay clean and consistent rather than messy and fragmented.

So my opinion (as I think has been clearly stated here) is that the 
split between platforms should come in the implementation of 
set_control_value(), enable_control(), etc. and not higher up.  If you 
want proof that it's viable and useful, "the proof is out there".  Go 
read A1's network_dialogs.cpp.  There are some #ifdefs in there still, 
yes, which is somewhat unpleasant, but that's because the different 
platforms still have different features and mechanisms that need 
slightly different UI configurations (though I hope an upcoming 
"cleaning" review of the network subsystem will remove most of those).  
You'll find that the vast majority of code is shared.

If one dialog box (or part of one box) is radically different on 
different platforms or something, then that one segment can be split 
higher up the tree.  But when almost all the logic for managing the 
dialog is identical, doesn't it make sense to share the code?

(Of course this is essentially the same argument as for using standard 
library calls and SDL instead of Mac OS calls whenever possible, though 
they are different issues.  Shared code, not separate branches.  Shared 
code, not separate branches!!)

> I should point out that addressing the platform issues directly is why 
> I haven't polished the interface of the OSX builds yet. Yes, the lists 
> of all the gui glitches in fading in and out and menu buttons are good. 
> I'm just not trying to polish that aspect of the game yet. Not until 
> the framework underneath has been revamped. Likewise for the mouse. 
> Right now I can use AlephModular to play Marathon 2. It confirms that 
> the game core and such are all still working. For this stage in the 
> project I find this to be an acceptable 'almost shippable' state.

Agreed and well-understood.  I think AM is progressing nicely and is an 
exciting project, else I wouldn't waste^H^H^H^H^Hspend so much time 
blathering^H^H^H^H^H^H^H^H^H^Hoffering suggestions here.  ;)

> This doesn't mean that I'm ignoring all bugs, just the ones relating to 
> the GUI in its current state. Crashing bugs or other glitches within 
> the game core are definitely a priority. I find it interesting that in 
> recent days I've patched several bugs in AM that either are still 
> noticeable in AO if you know where to look or have been addressed only 
> relatively recently. Make of my focus what you will.

I don't suppose you've considered sharing your findings with the A1 
project so that it can also benefit...?  Or are you only talking about 
that close-monsters-disappearing thing?

> I should remind folks that once we have cross-platform support, I am 
> going to want and need folks to do the release builds for other 
> platforms. We aren't going to have a random mac release here and a 
> random linux release over there which happens to be using code from a 
> different date. I want that Sourceforge release page to have the 
> AlephModular release and below that the current version release and 
> below that the builds packaged for different platforms.

If AM becomes a compelling alternative to A1, I think you'll get 
builders.  And I don't think that asking for timely releases for 
supported platforms is out of line (subject to the 'volunteer project' 
stuff outlined above)... *especially if most code is shared so all 
platforms get features/fixes at the same time*.  ;)  (broken record...)

> I admit I've been having some visions of things I'd like to see. 
> Whether as proof of concept or samples of what we can do when we get 
> there, I don't know.

> For instance, how about a Replay to Quicktime converter? It ditches the 
> UI and renders the whole game out to a full 30 fps Quicktime.mov. 
> Possibly several movies if the replay had multiple players. then people 
> can watch your vidmaster epics even if on a slow computer or without 
> needing AM, the map, the sounds and so forth.

This could be cool; you could use iMovie to edit your replays down to 
highlights and lay down a pulsing soundtrack.  :)

> Or multi-part monsters. Like a unified squad of Pfhor, or a long 
> segmented worm.

Or anything anyone can think of, because the idea is that AM will be an 
easier and more rewarding environment to work in than A1.  Right?  I 
don't think there have been any suggestions contrary to these goals.

Anyway the bottom line is, I think you have good intentions and are 
doing good work, even if I disagree with a few of the paths you seem to 
be wanting to take.  (I think I agree with you on many others.)  It's 
your project, and in truth I'll probably be going into Aleph* 
hibernation again in another week or so, so my opinions don't really 
matter a whole lot.  As I see it, my job is to make sure you consider as 
many relevant options as possible; the decisions are yours.

I still wonder whether AM is necessary, or whether restructuring A1 
would be as effective at achieving the AM goals while maintaining all 
the nice features of A1.  I don't know that answer, and it's moot anyway 
since we have someone working on AM and nobody doing the corresponding 
work for A1.  :)

Woody

[Alephmodular-devel] Developer Rant #1 :)

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

Since I haven't really gotten myself organized, I'm going to give the 
list a little bit of an earful. Though Matt might want to find 
someplace on the website he's building for this. :)


I have to admit that the #1 priority on the top of my list is to 
continue to keep Marathon running nice and happily on my machine. I've 
now carbonized Marathon twice and I want something that runs really 
nice and well. And I want updated networking. which I suppose could be 
odd seeing as I've rarely had chances to play Marathon on a LAN :)

Second of all, I want to open up the code in way that it isn't just one 
monolithic beast. While it may or not ever materialize, I would like to 
use this code to support other development efforts. This includes tools 
for itself (map making and such) and game changes beyond scenario and 
physics making.

Then around third is being cross-platform. Yes, I admit it, 
cross-platform is less important to me than having a kick-ass game of 
Marathon. However, I do agree that it is important and I will support 
it. Calls for standardizing on this or that, while good arguments, do 
not necessarily mesh well with my first two goals. Accept that your 
platform of choice will be treated as a separate platform, take 
ownership of it and make sure it remains kick ass too.

With respect to staying in sync API-wise, we should be discussing 
issues like that to begin with. And include appropriate tracking or 
document matters on Sourceforge. If something UI-wise gets implemented 
on one platform and applies to the others, they should get stubbed 
interfaces if necessary to compile and someone should be responsible 
for filling out the specific platform.

Does this mean we should be making wrappers around set control/read 
control/hit control? Or should we just be doing 
PLATFORM_GUI->do_preferences(PrefObject)? I admit I both haven't 
decided and haven't yet had a chance to research this. I'd love a 
decent run down of the pros and cons of each.


I should point out that addressing the platform issues directly is why 
I haven't polished the interface of the OSX builds yet. Yes, the lists 
of all the gui glitches in fading in and out and menu buttons are good. 
I'm just not trying to polish that aspect of the game yet. Not until 
the framework underneath has been revamped. Likewise for the mouse. 
Right now I can use AlephModular to play Marathon 2. It confirms that 
the game core and such are all still working. For this stage in the 
project I find this to be an acceptable 'almost shippable' state.

This doesn't mean that I'm ignoring all bugs, just the ones relating to 
the GUI in its current state. Crashing bugs or other glitches within 
the game core are definitely a priority. I find it interesting that in 
recent days I've patched several bugs in AM that either are still 
noticeable in AO if you know where to look or have been addressed only 
relatively recently. Make of my focus what you will.


I should remind folks that once we have cross-platform support, I am 
going to want and need folks to do the release builds for other 
platforms. We aren't going to have a random mac release here and a 
random linux release over there which happens to be using code from a 
different date. I want that Sourceforge release page to have the 
AlephModular release and below that the current version release and 
below that the builds packaged for different platforms.

I admit I've been having some visions of things I'd like to see. 
Whether as proof of concept or samples of what we can do when we get 
there, I don't know.

For instance, how about a Replay to Quicktime converter? It ditches the 
UI and renders the whole game out to a full 30 fps Quicktime.mov. 
Possibly several movies if the replay had multiple players. then people 
can watch your vidmaster epics even if on a slow computer or without 
needing AM, the map, the sounds and so forth.

Or multi-part monsters. Like a unified squad of Pfhor, or a long 
segmented worm.

-Jeremy Parsons

Re: [Alephmodular-devel] Targetting SDL (was: MacOS X 10.1 users?)

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

On Monday, January 13, 2003, at 11:00  PM, Woody Zenfell, III wrote:

>
> On Monday, January 13, 2003, at 09:13  PM, Br'fin wrote:
>
>> lo-res doesn't bypass it. But by being less strain on the processer 
>> (render postage stamp, then custom blit to window buffer) instead of 
>> (render 640x480, then copy to window buffer) the window server just 
>> might get more chances. By tear, if you mean white bite occasionally 
>> between polygons, I see some of that even in high rez, might just be 
>> more noticable in low res since the resolution is so much less and 
>> white spots become more noticable.
>
> By 'tear', I mean that some parts of the window are updated to a new 
> frame during one display refresh, and others are updated during the 
> next refresh, so what are effectively vertical lines that appear in 
> different places in consecutive frames end up looking like disjointed 
> segments.  I guess if there's no bypass, it must just be that the 
> tearing is more noticeable at the higher frame rate.

Ah, gotcha. Certainly a possibility. No one's making any attempt to 
sync rendering and updates to when OSX actually gets around to updating 
the visible window from it's buffer :)

>> On the other hand, treating SDL as a separate platform helps keep the 
>> display module's interface cleaner with fewer includes across 
>> everything.(ADisplayModule.h doesn't #include SDL, but the file that 
>> implements the SDL functionality for ADisplayModule.h can include 
>> whatever SDL headers it wants)
>
> I have no problem with hiding SDL details from the game's interface to 
> its facilities.  But I hope that AM will take a different course from 
> A1, and will write its implementations in SDL rather than Mac OS, 
> sparing the Mac OS-specific code for when it's absolutely needed.  
> This way we have much more common code.

Hard to say. Then again my own impression involves pushing both MacOS 
AND SDL code out to where and when they are absolutely needed. We're 
already using our own definitions for int32 for instance.

> I assume when you're referring to SDL as a "UI element" that you mean 
> the custom UI widgets library that Christian Bauer wrote for A1 and 
> that I extended to have some additional capabilities.  Agreed, Aqua is 
> better.  :)  But I think we (I should primarily credit Christian) did 
> at least adequately for a "baseline", works-everywhere system.

Actually, I was referring to the prior argument on UIs and widgets. Not 
to "SDL as a UI Element"

My overall feeling is.

	SDL vs MacOSX for displays: Situation hazy
	MacOSX & platform specific vs Cross-platform GUI: Prove the 
Cross-platform GUI

> I mean I guess you could retain the non-SDL Mac stuff for a while as a 
> sort of "reference implementation", since that code's also already 
> written in most cases, but the real movement should be toward 
> SDL-based, Mac-polished code instead, letting the non-SDL Mac stuff 
> rot (and slicing it away when it does, leaving a cleaner, simpler 
> product that's easier to maintain and friendlier for new > developments).

A good argument and more compelling than the cross-platform UI.

I admit I'm hesitant with some of the issues of outright including SDL 
as the baseline. Part of it is that I'm unfamiliar with it as a 
library. Part of it is displeasure with some of how it meshed with 
things in A1 and some of how it meshes with another project I worked on.

For Bochs there's a way to compile with both Carbon and SDL support. 
And then the GUIs can be treated as plugins with a preference in a 
config file letting you specify one or the other. However, just by 
compiling SDL in, it's init code supercedes the normal main. And 
whenever I use the carbon UI, portions of my application menu is 
lobotomized (Pretty much missing almost all contents that should be 
there, like the hide this or other app menu items)

This isn't so bad within the game proper. But could be awkward for 
someone trying to mesh a smaller piece into an editor.

My impression of SDL in a nut shell? A good idea, but it doesn't seem 
to play well with others. I certainly support it as a desirable 
platform for AM. I don't know if I want to support it as THE Platform 
for AM. I also don't consider MacOS X The Platform for AM either. It's 
just a platform that I really don't want to break things on :)

-Jeremy Parsons

[Alephmodular-devel] Copy-on-write in practice

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

I'd like to take one idea from my monstrous idea dump, copy-on-write 
(COW) game objects, and talk a little more about it.

Remember, the goal is to be able to split off into a fake (predicted) 
game-state for one or more ticks, then later return to the original 
(real) game-state, with the game-update logic being essentially the same 
for predictive updates and real updates (and as similar to the current 
code as possible, for practical reasons).

(Sounds could be sticky, but I'll put that problem off till later.)

I see (at least) three basic options.

OPTION 1.  Put all the COW functionality into the lookup routines

An object a refers to another object b by its index (and, implicitly, 
its type) like it does currently.

When a wants to read b's data structure fields, it calls 
get_btype_by_index(bindex); and reads the returned structure.

When a wants to write b's data structure fields, it calls 
get_writable_btype_by_index(bindex); and may read or write the returned 
structure.

The lookup routines go something like:

btype*
get_writable_btype_by_index(bindex) {
     if(game_state_mode == predictive_mode) {
         if(predictive_btypes[bindex] == NULL)
             predictive_btypes[bindex] = 
shallow_copy_btype(real_btypes[bindex]);
         return predictive_btypes[bindex];
     }
     else
         return real_btypes[bindex];
}


const btype*
get_btype_by_index(bindex) {
     if(game_state_mode == predictive_mode && 
predictive_btypes[bindex] != NULL)
         return predictive_btypes[bindex];
     else
         return real_btypes[bindex];
}



void
discard_predictive_btypes() {
     for(int i = 0; i < predictive_btype_count; i++) {
         if(predictive_btypes[i] != NULL) {
             dispose_btype(predictive_btypes[i]);
             predictive_btypes[i] = NULL;
         }
     }
     predictive_btype_count = real_btype_count;
}



This only does the testing and lookup when asking for another object, so 
there's not a terribly great performance hit probably.  OTOH there's a 
great potential for disaster, e.g. if we're in predictive mode, and one 
routine acquires a pointer via get_foo_by_index(k), calls {another 
routine which acquires a pointer via get_writable_foo_by_index(k) and 
makes some changes}, and then reads fields of its foo with its old 
pointer, it's working with stale data.



OPTION 2.  Put COW functionality in objects and field accessors

template <typename tEmulatedType>
class COWObject {
public:
     void discardPredictiveVersion() { delete predictive_self;  
predictive_self = NULL; }
protected:
     const tEmulatedType* self() { return (game_state_mode == 
predictive_mode && predictive_self != NULL) ? predictive_self : 
real_self; }
     tEmulatedType* writable_self();
     tEmulatedType* real_self;
     tEmulatedType* predictive_self;
};

template <typename tEmulatedType> tEmulatedType*
COWObject::writable_self() {
     if(game_state_mode == real_mode)
         return real_self;
     else {
         if(predictive_self == NULL) {
             predictive_self = real_self->shallow_copy();
             CentralAuthority()->registerPredictiveObject(this);
         }
         return predictive_self;
     }
}


class Player : public COWObject<PlayerState> {
public:
     int getValue() { return self()->value; }
     void setValue(int inValue) { writable_self()->value = inValue; }
};



(The CentralAuthority holds a list of all the objects with predictive 
state, and tells them all to discard_predictive_version() when the game 
logic asks it to.)

This way code that uses game objects essentially just uses them, reading 
or writing individual fields in a natural way (that also allows for 
additional 'hooking').  Each such use incurs some overhead for locating 
the appropriate object, but there's little to no chance for 
inconsistency as in the example above.



OPTION 3.  Arrange game-state structures explicitly in memory and 
bulk-copy

In this scheme, all the game-state code is grouped together in a fairly 
tightly-packed, well-defined region of memory.  All access to game-state 
objects is indexed off a base address.

On EnterPredictiveMode(), all the game-state code is copied in bulk 
(with memcpy, some kind of hardware blitter, operating-system 
virtual-memory-system mark-page-as-COW support, etc.) to another chunk 
of memory.  The base address for game-state-object indexing (see above) 
is changed to point at this new block.  Bulk copying *should* be 
(significantly?) quicker than the too-slow copy-the-whole-game-state 
approach I took, which effectively produced a saved-game (without 
packing the fields, but essentially using the same code paths 
nonetheless).  Since the state-change won't happen in the middle of a 
game-state update, there's no chance for inconsistency.  All the 
overhead is taken up in the bulk copy; actual use of the objects is 
essentially identical to the current scheme, so there's no additional 
overhead in reading/writing fields or asking for objects.

On ExitPredictiveMode(), of course, the copy is simply deallocated and 
the base pointer set back to the "real_mode" chunk of memory.  Cheap 
cheap, fun fun.


Note that in general I think netgames would change mode upwards (from 
real to predictive) once per rendered frame probably, whereas 
single-player games and films would not need to.  OTOH the same 
mechanism (basically) would probably be used for between-frame 
interpolation (for smoothing out the animation, enabling frame-rates 
higher than 30fps), which would need a mode-change upwards once per 
rendered frame (potentially in addition to the predictive mode change in 
a netgame) in all circumstances (unless the machine is not even keeping 
up with 30fps, in which case it's nearly pointless to interpolate 
between the 30 ticks per second we're already computing).

I think this summarizes the characteristics of these alternatives:

Approach - Runtime overhead (time) - Runtime overhead (memory) - Changes 
required to existing code - Chances for (insidious) bugs
(1) - Low - Low - Low - High
(2) - Medium - Low - High - Low
(3) - High (potentially) - Medium - Low - Low

Thoughts?  Maybe I'll try to estimate the game-state size, and measure 
how long it would take to bulk-copy it on my machines, to get *some* 
idea of the feasibility.

Woody

Re: [Alephmodular-devel] Targetting SDL (was: MacOS X 10.1 users?)

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

On Monday, January 13, 2003, at 09:13  PM, Br'fin wrote:

> lo-res doesn't bypass it. But by being less strain on the processer 
> (render postage stamp, then custom blit to window buffer) instead of 
> (render 640x480, then copy to window buffer) the window server just 
> might get more chances. By tear, if you mean white bite occasionally 
> between polygons, I see some of that even in high rez, might just be 
> more noticable in low res since the resolution is so much less and 
> white spots become more noticable.

By 'tear', I mean that some parts of the window are updated to a new 
frame during one display refresh, and others are updated during the next 
refresh, so what are effectively vertical lines that appear in different 
places in consecutive frames end up looking like disjointed segments.  I 
guess if there's no bypass, it must just be that the tearing is more 
noticeable at the higher frame rate.

>> Ah but surely you mean (by telling SDL to SetVideoMode to a 
>> full-screen mode with page-flipping), or something like that.  ;)
>
> That is certainly the SDL implementation of the display module.
>
> I honestly can't be as harsh on SDL as a generic display library as 
> opposed to a generalrized UI element. I don't know Windows' API here, 
> or SDL's, or even OSX's.
>
> On the other hand, treating SDL as a separate platform helps keep the 
> display module's interface cleaner with fewer includes across 
> everything.(ADisplayModule.h doesn't #include SDL, but the file that 
> implements the SDL functionality for ADisplayModule.h can include 
> whatever SDL headers it wants)

I have no problem with hiding SDL details from the game's interface to 
its facilities.  But I hope that AM will take a different course from 
A1, and will write its implementations in SDL rather than Mac OS, 
sparing the Mac OS-specific code for when it's absolutely needed.  This 
way we have much more common code.

I assume when you're referring to SDL as a "UI element" that you mean 
the custom UI widgets library that Christian Bauer wrote for A1 and that 
I extended to have some additional capabilities.  Agreed, Aqua is 
better.  :)  But I think we (I should primarily credit Christian) did at 
least adequately for a "baseline", works-everywhere system.

Anyway basically I'm saying, don't think of Mac as one platform and SDL 
as another platform.  SDL is the generic baseline target, and works on 
all platforms, including Mac OS X and Mac OS 9 as well as Solaris, 
Linux, Windows, Dreamcast, etc.  There are Mac OS-specific routines to 
present the UI with Aqua (or Platinum Appearance, under 9) rather than 
our little widgets, just as there may eventually be Win32-specific 
routines to present a Windows UI rather than the little widgets.  
(Though code to get/set control values, enable/disable controls, respond 
to control clicks, etc. is shared, at a higher level than this UI 
presentation layer - a lot of this work is already done in A1 as well, 
at least in the netgame dialogs.)  But sound playback is handled on all 
platforms by SDL (or SDL_mixer atop SDL).  So you don't have Sound 
Manager code in there.  (Though you might eventually have, say, 
DirectSound3D code as an alternative to the SDL base, so that Windows 
users get 3D positional audio.)

Please think about it.  A lot of the work is already done (in the A1 
project).  We can finally end this "I write/debug everything twice!" 
business, and things like network audio playback will work the same way 
on all platforms (unlike the current situation).

I mean I guess you could retain the non-SDL Mac stuff for a while as a 
sort of "reference implementation", since that code's also already 
written in most cases, but the real movement should be toward SDL-based, 
Mac-polished code instead, letting the non-SDL Mac stuff rot (and 
slicing it away when it does, leaving a cleaner, simpler product that's 
easier to maintain and friendlier for new developments).

Woody

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

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

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

> On Monday, January 13, 2003, at 06:29  PM, Br'fin wrote:
>
>> It's all part of the same problem. AM doesn't yet have any code to 
>> tell OSX 'Update the screen NOW' So AM changes the window buffer and 
>> OSX updates the window at some point where system events are being 
>> processed.
>
> 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?)

lo-res doesn't bypass it. But by being less strain on the processer 
(render postage stamp, then custom blit to window buffer) instead of 
(render 640x480, then copy to window buffer) the window server just 
might get more chances. By tear, if you mean white bite occasionally 
between polygons, I see some of that even in high rez, might just be 
more noticable in low res since the resolution is so much less and 
white spots become more noticable.

>> I haven't addressed the issue because one of the areas I really want 
>> to redo things involves the management of the buffers AM draws into. 
>> A display module if you will, that on the platform specific side 
>> could do things like 'use this window's back buffer' or 'Go full 
>> screen (and use the DisplaySprocket unbuffered buffers)'
>
> Ah but surely you mean (by telling SDL to SetVideoMode to a 
> full-screen mode with page-flipping), or something like that.  ;)

That is certainly the SDL implementation of the display module.

I honestly can't be as harsh on SDL as a generic display library as 
opposed to a generalrized UI element. I don't know Windows' API here, 
or SDL's, or even OSX's.

On the other hand, treating SDL as a separate platform helps keep the 
display module's interface cleaner with fewer includes across 
everything.(ADisplayModule.h doesn't #include SDL, but the file that 
implements the SDL functionality for ADisplayModule.h can include 
whatever SDL headers it wants)

-Jeremy Parsons

[Alephmodular-devel] Referencing, Accessors, and Object-Orientation

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

These messages seem to fit together, so I'm sending them both together 
despite the resulting e-mail taking half a year to read.  :)

----- Original Message -----
From: "Woody Zenfell" <woo...@ho...>
To: "Br'fin" <br...@ma...>
Sent: Wednesday, December 11, 2002 12:29 AM
Subject: Re: Fw: [M-dev]comments


> Random thought: the Marathon data structures should always have their 
> values
> set (if not both set and read) by accessors.  Probably easier to start 
> this
> early on than to stick it in later.  Of course, accessors in most cases 
> can
> collapse into inline code for hitting the data directly, at least for 
> now.
> But the 'hooks' will be established.
>
> I think the data structures refer to each other indirectly already 
> right?
> Basically one structure stores like the index of another structure, and 
> asks
> for the other structure by calling a function.  That is, a structure 
> does
> not ever store a direct pointer to another structure.  This is good.
>
> With hooks at data-structure writes and at "dereference object 
> reference"
> points, it should be reasonably straightforward to make these data
> structures effectively copy-on-write, for network prediction and
> between-tick interpolation.  (I tried copying and restoring all the data
> structures every game-tick, but there was far too much data.  If we can 
> copy
> and restore only the objects that change, I suspect it's a MUCH smaller
> amount.)
>
> Finding the access points should be straightforward in most cases, but
> aliasing of course makes things awfully sticky.
>
> Of course, locating dependencies on game-tick duration would be 
> necessary
> for between-tick interpolation.
>
> Sorry, know these things are a lot of grunt-work.  Not trying to dump 
> them
> off on you.  Just wanted to have them in your head as you consider the 
> grand
> reworking scheme, in case they inform some decisions.  :)
>
> Woody


----- Original Message -----
From: "Woody Zenfell" <woo...@ho...>
To: "Br'fin" <br...@ma...>
Sent: Wednesday, December 11, 2002 11:36 AM
Subject: Re: Fw: [M-dev]comments

>> I'm unsure about the copy on write stuff.
>
> Well, my ideas work as follows:
>
>
> Network prediction
>
> At any given time, you have a "real" game state, which is the state of 
> the
> game at the most recent game-tick for which you have complete 
> information.
> Additionally, you have a "predicted" game state, which is computed 
> based on
> partial information and represents the best guess at what the game state
> looks like for the game-tick whose input was just recorded.
>
> So, when a game-tick elapses on the local machine, the predicted game 
> state
> advances a notch.  When new data comes in from the network to give us
> complete data about the tick after the real game-state's tick, the real
> game-state advances a notch.  Note that the predicted state should then 
> be
> recomputed also (perhaps going through several game-ticks' updates, if 
> we're
> predicting ahead a little while) when the real state changes.  So the 
> old
> predicted state will be discarded.
>
> With a little cleverness/trickery it should be possible to use the same
> update routines to compute both real and predicted game-state 
> updates.  (I
> have already planned in A1 a scheme with multiple sets of action_queues 
> to
> handle real input vs. predicted input streams - will try to hunt that up
> somewhere.)  With copy-on-write objects, it should be possible to let 
> the
> two separate game states share most of the same objects.  Only objects 
> that
> get changed by a predictive update need to have a separate copy made.
>
> Initially I'd figured that the copied object would be the one then 
> written
> to.  But it would probably make coding more straightforward for the 
> copied
> object to be the one left unchanged.  Note that since deferencing object
> references is done explicitly (currently via functions like
> get_player_with_index() etc.), that routine can correctly return the
> real-state object (the copy, if there are two objects) or the
> predicted-state object as appropriate in context.  (There would 
> probably be
> some kind of widely-visible flag set that would be set during predictive
> updates and clear for real updates.)
>
> Hmm though, actually, copying the object, messing with the original, and
> discarding the original shifts things around in memory a lot more than 
> would
> copying the object, messing with the copy, and discarding the copy.  So
> maybe it still would be best for predictive writes to affect the copy.
>
> Note that this prediction scheme does not provide for interpolation 
> (e.g.
> lerping) between the old predicted state and the new, more accurate
> predicted state.  Players whose input is taking a long time to reach us
> would sort of teleport in little hops.  But at least the local player 
> would
> be seeing the best guess at any given moment - interpolation would 
> probably
> muddy things up in that regard.
>
> This scheme assumes that rendering is 'stateless' - i.e. you can render 
> any
> game-state regardless of the last game-state rendered.  (Obviously 
> texture
> caching etc. make the renderer not truly stateless, but at least the
> renderer will still produce correct results if that's the only state it
> maintains.)  Also, it does not take into consideration sound playback 
> or any
> other side-effects of updating.  And finally, it's still essentially a
> peer-to-peer symmetric-execution sort of scheme.  A cheating client 
> could
> show all players on map, or warn the player when somebody's pointing a
> weapon at him, etc.  It could also exploit this prediction mechanism: it
> could watch everyone else's up-to-date action, but delay sending its own
> moves a bit to give itself an advantage.  Rockets could seem to appear 
> near
> your head (or worse, feet) if they were fired a while ago but you didn't
> learn about them until just now.  Modern games seem to avoid this sort 
> of
> thing by making the server sort of "certify" actions, and things like
> shooting aren't allowed to happen until the server receives the "shoot
> command" from the shooter - which could of course be some time after the
> shooter pressed his mouse button.
>
>
> Between-tick interpolation
>
> Between-game-tick interpolation would work somewhat similarly.  In 
> addition
> to the above game-states, you'd have an interpolated state.  You would 
> need
> new update-the-world routines that can update things less than a 
> game-tick.
> But they don't need to be all that clever - maybe just move things that 
> are
> moving.  The real action still happens at game-tick updates.
>
> So you'd have, say, a real game-state for tick 450, and a predicted
> game-state for tick 453.  We could produce an interpolated game-state 
> for
> tick 453.4.  When it's time for tick 453.8, we throw out the 453.4
> game-state and make a new interpolated state from 453 to avoid 
> accumulating
> errors.  The quality of these interpolated updates doesn't need to be 
> all
> that great - just something to smooth out the action.  It's probable 
> that
> the interpolated states would be the only ones ever rendered (unless
> interpolation is disabled altogether, perhaps by a Preference).
>
> Does that make sense?  You'd still use the copy-on-write and the
> demultiplexing-object-reference-dereferencing mechanisms like above to
> maintain (and discard) these in-between states.  But you don't have to 
> worry
> about messing with input queues, and since you have new update 
> routines, you
> don't play any sounds, so that's not an issue, etc. etc.
>
> Actually, there may be a problem with this.  The game-tick updaters 
> probably
> assume that, say, an action_flag describes what a player's been doing 
> with
> the most recent game-tick of his life.  So if the player was moving 
> forward
> in his last action_flag, but now is moving left in the current 
> action_flag,
> the game-tick updater will (I suspect) produce a game-state that 
> reflects
> the player, moving left for the past game-tick.  But since the 
> interpolated
> updater didn't know that the player was going to be moving left (since 
> we
> don't collect the action_flag until game_tick time), it kept moving the
> player forward a little bit.  So in effect the interpolated updater is 
> going
> to be predicting ahead some 0 < amount < 1 game-tick, and it will be 
> wrong
> whenever the user changes what he's doing.
>
> I suspect given the small amounts by which the interpolator would be 
> off,
> this is probably only really going to be unpleasant as we mispredict the
> local player.  I mean, I doubt minute jitters in other objects' and 
> players'
> locations are going to be off-putting... but jittering the viewpoint 
> around
> could be rather unpleasant.
>
> Hmm so a few options are:
>
> 1.  Let it be wrong a little bit and hope it's not too disconcerting.
>
> 2.  Try to peek at the local user's input before game-tick time to 
> make a
> better prediction.
>
> 3.  Delay everything by a game-tick so we can see what the players 
> really
> did, instead of guessing.  But of course this introduces a little bit of
> latency, which could be less pleasant than the results of the above.  
> OTOH
> 1/30th of a second latency might be a small price to pay for smooth, 
> solid
> interpolation vs. the results of the above.  I really don't know!
>
>> As for interpolation, I've been wondering if there's a way to split
>> physics/AI from animations. I know animations currently have spaces
>> that both denote keyframe and sound to play. I'm not quite sure where
>> the sound information should go. But what if at shape load time the
>> monster physics noted how many ticks into the animation a keyframe
>> occurs. And then the animations were put elsewhere.
>>
>> Something like, a physics tick says a monster should move from point X
>> to Y using walking animation. (It no longer cares what frame you're on,
>> so as long as it keeps specifying walking animation, the walking
>> animation is used) The animation system would then have a record saying
>> 'move X to Y using walking animation by the time of next physics tick'
>> So if your renderer can pump out screens faster than your next physics
>> tick your animations are smoother.
>>
>> I suspect myself guilty of some kind of off by one error here.
>> (Normally it would be immediately move X to Y then render the new
>> screen...) I wonder if that's noticeable 30 times a second...
>
> I probably should have read this more carefully before writing my 
> text.  I
> think we're identifying the same problem ("off by one error") as we're
> thinking about the same scheme (rendering between the ticks).  But, in 
> my
> case, I could argue that _I_ had just gotten up when I first read it.  
> Heh
> heh.
>
> Anyway I don't think I know enough detail currently about the 
> frame-based
> animation in Marathon to comment intelligently on that.  Note that in my
> proposed scheme, you'd only care about keyframes in the game-tick update
> code.  You could have additional frames in between (whether provided
> statically or generated dynamically e.g. with the 3d model stuff) that 
> the
> interpolator and renderer would use merely for rendering.  You'd have to
> keep track of (only in the game-tick updater) "did I pass the 
> keyframe?",
> and you'd have to latch that value so you could detect the transition, 
> so
> you know which tick should perform the action.  Alternatively, yes you 
> could
> figure out ahead of time which integral game-tick after the start of
> animation should trigger the action, use an "equals"-style comparison, 
> and
> skip the latching and "greater-than-or-equal"-style comparison I just
> suggested.  It could analyze the animation's frames and timing to 
> calculate
> the "key time" for animations with "key frames", or (at some point) some
> alternative format could specify the "key time" (either on a game-tick
> boundary or rounded to one by the engine at load-time, of course) for 
> any
> given animation sequence, independent of the frames and frame-rate.  
> Yeah OK
> I think that's probably what you're getting at.  Sounds good to me!  :)
>
> Or heck, ask the animation or animation system about whether this is the
> keytick.  Let it decide whether it should round and == or latch and >=, 
> etc.
> Hmm that way animations could even have (if they can't already) multiple
> keyticks, playing different sounds and causing different actions.
>
> Ok ok ok let the above stand as some kind of insight into my reasoning.
> Here's what I'm now thinking:
>
> Animation knows its keytick, sound, effect, etc.  Game-tick updater 
> gives
> animation the opportunity to perform actions at game-tick time.  
> Animation
> is responsible for analyzing its frame-rate and keyframes etc. to come 
> up
> with a keytick.  Animation can choose whether it wants to play a sound, 
> tell
> monster to launch its projectile, spawn an effect, etc. etc.  In this 
> way an
> animation becomes more than just a sequence of frames, it's more like a
> little script for the monster (or whatever's animating) to execute.
> Renderer asks animation for best frame to show for the (non-integral)
> game-time it's rendering.
>
> Hmm then the animation needs sort of a "runtime context".  At the 
> least, a
> given instance of the animation needs to know when it was started; it 
> might
> want to keep track of more state too.  So I guess there should be a
> distinction between an "animation process" (the runtime context) and an
> "animation program" (the static supporting data with the various frames,
> keytime, etc.).  Multiple processes could refer to the same program.
>
> The monster or effect or whatever would have a reference to its
> currently-executing animation process (if there is one).  This 
> reference,
> like all others, would of course be "hooked" - i.e. somewhat indirect - 
> so
> copy-on-write could apply to animation processes etc. letting them be
> predicted and rolled back.
>
> Hmm, reference hooking in general could use the current
> "index-and-lookup-function" scheme, or could involve small "object 
> locator"
> objects that effectively encapsulate the reference and the dereferencing
> operation.  But some thought would be needed in the latter case with 
> regard
> to copy-on-write and how the locators would dynamically find the new 
> copy
> etc.  The locator could use index-and-lookup internally of course.  Or 
> maybe
> there's one or more maps of "real" object pointers (as keys) to 
> "alternate"
> object pointers (as values).  If we're operating in "real mode", we can 
> just
> return the stored real pointer.  If we're operating in an alternate 
> mode, we
> do the lookup.  Or maybe objects themselves (probably through 
> inheritance)
> have support for multiple versions of themselves, and overload * and -> 
> to
> work with the proper variant, letting you store direct pointers to the
> "base" versions of objects but still get "hooked" dereferencing.  (Does 
> that
> work?  Aha so then this->method() could potentially do something 
> different
> from just method()??)
>
> There would be centralized objects that vend (hooked) references to 
> other
> objects.  You know, locate other objects by name or by some other 
> (stable,
> unlikely-to-conflict) identifier, to encourage modularity.  It could 
> have
> standard names for the objects that are reanimated from existing data 
> files.
> New data files could add new objects, not merely replace existing ones
> (though I suppose that should be an option too).  Multiple new data 
> files
> could be loaded together without conflicts (assuming people chose 
> reasonably
> distinct names).  So these little reference objects, or these tricky
> reference-aware objects, could initially refer to other objects by type
> (well type-code of some sort I guess since C++ classes, sadly, aren't
> objects) and by name.  At the first dereference (or as part of some
> post-loading phase) these would be replaced by more-specific (faster)
> references to actual instances in memory.
>
> Hmm am I getting a bit carried away...?  Nah I don't think so.  I think 
> it's
> high time that the stored data break free from this index-based stuff 
> and
> move to something more flexible.
>
> And hey yeah, a file is just an archive of various objects.  There's no
> "map" and "shapes" and "sounds" files etc., there are just "level" and
> "bitmap" and "terminal" objects etc. and they're located in whatever 
> files
> they damn well please.  The loading code would be able to read the 
> existing
> file formats of course, but would present the objects found therein to 
> the
> rest of the code in a way that's consistent with the more-general 
> scheme.
> And maybe the engine supplies some pull-them-all-together objects, like 
> one
> named "m2trooper".  Then when it loads a map file that's detected as an 
> M2
> map, it converts references to monster index 15 (or whatever) into
> references to "m2trooper".  So you could then drop in a new-style file 
> that
> replaces the standard m2trooper object, and old M2 maps use the new 
> trooper.
> Of course m2trooper is distinct from minftrooper and m1trooper, so when 
> you
> load an M1 map you don't get an Moo trooper.  etc.  There should be some
> thought on "reference scope" I guess - the specifics of the
> locate-the-desired-object-by-name behavior - and also hmm there should 
> be
> ways to reroute references, so that e.g. an M2 Map file that's part of 
> some
> custom scenario produces (upon loading) references to 
> myScenarioTrooper, and
> there's a myScenarioTrooper object created by the engine that loads
> myScenarioTrooperAnimations etc.  This way merely adding some kind of
> "scenario description file" lets the existing files stay intact as 
> standard
> M2-format files or whatever, but the names of the objects provided and
> referred to change.  Then, a new-style map file could refer to a
> myScenarioTrooper AND an m2trooper, and it would work.
>
> Well there's a big dump of raw ideas, much refinement needed.
>
> Woody

Note: the m2trooper object created by the engine (the one that ties 
together the various bits and pieces) is effectively "Bio" information, 
if I'm reading this right.

Note also: Marathon frequently divides objects into "static" (shared) 
and "dynamic" (per-instance) parts.  (In some sense, this is like 
classes and objects.)  In any event, I'd support some effort that 
explicitly classifies the various structures/classes as one or the 
other, if it's not already obvious from naming conventions etc.

And finally, here's a message I was working on as a new message to send 
here, that puts the 'generalized reference' stuff another way (probably 
duplicates some of the above, but goes into more detail I think):

>> [Br'fin]
>> Well, the hardest part of saying 'no code' on the Bios is in the areas 
>> where current code links definitions to external resources. The second 
>> hardest part involves 'How do we set up one copy of AlephModular to 
>> handle M2 files versus Minf files versus M1 files?' Each one is a 
>> mildly different Bios. So even if the specific map loader isn't coded 
>> right into the Bios file, there still needs to be a way to specify 
>> which Map Loading object to apply. Similar details surround terminal 
>> rendering.
>
> [Woody]
> On all this, my instinct is to have these "Bios" (for want of a better 
> term) be real objects, with data _and code_.  Now, there could (and 
> probably should) be a movement of the various data values out into a 
> file, but that's sort of a detail of the Bio class (or a 
> Marathon-specific subclass).
>
> A while ago I sent a couple notes directly to Br'fin - the list was 
> just getting set up at that point.  In at least one of them I lobbied 
> for a very dynamic, object-oriented system.  In particular, classes and 
> objects would have general identifiers that the engine would use to 
> connect things up.  For example, there might be a class M2Trooper 
> (which perhaps inherits from MarathonTrooper, which inherits from 
> MarathonMonster, or whatever).  Conceptually, a Map file would include 
> a directive like "Create an M2Trooper here".  In practice of course we 
> want to maintain compatibility with the existing M2 Map format though, 
> so instead the M2MapLoader will rewrite existing references to "monster 
> index 19" (or whatever) to "M2Trooper".  The actual object would be 
> created with a phrase along the lines of 
> CreateObjectOfClassNamed(objectClass);.  The latter would look up the 
> class by name and call its Create() method, or somesuch.
>
> This seems awfully roundabout I'm sure, but remember that modularity is 
> at least as much about loosening the connections between modules as it 
> is about consolidating related stuff into modules.
>
> So a scheme like this buys you things like:
>
> + M1, M2, and Moo (and various other existing scenarios?) maps always 
> get you the corresponding type of Trooper.  (And they always get you a 
> Trooper, even if the monster index is different between them.)  None of 
> this "Environment" nonsense where the user has to get all the settings 
> right for things to make sense.
> + New scenarios can add new monster types (like "MyTrooper") but still 
> reference existing types (like "M2Trooper").  (This assuming there's 
> eventually a map file format that supports the generalized referencing.)
> + Scenarios can replace monster types, effectively providing a 
> "MyTrooper" whenever an "M2Trooper" is referenced.
>
> And I think you'll see how deep the rabbit-hole goes if you think about 
> M2Troopers referencing (indirectly, of course) "M2TrooperGrenade"s for 
> their projectiles, "M2TrooperMonsterAnimation"s for their animation 
> scripts (which reference "M2TrooperShape"s for their bitmaps), etc. etc.
>
> Hmm right so anyway I guess in this scheme the Bio and the MapLoader 
> are intimately related (maybe they're even the same, effectively, or 
> maybe the MapLoader implements the Bio by virtue of the names of the 
> things it references).  Of course naturally the code that loads M2 
> Shapes files provides the M2TrooperShapes and the 
> M2TrooperMonsterAnimations, and the code that loads/provides the M2 
> Physics helps the M2Troopers know they should use M2TrooperGrenades.  
> In this case, knowing that an M2Trooper *uses* M2TrooperShapes and 
> M2TrooperMonsterAnimations is part of the "M2 Bio".  So perhaps you 
> stick this information into a Bio object, and end up doing something 
> like:
>
> M2Trooper::foo() {
> this->GetBio()->GetMonsterAnimationForClassNamed(this->GetClass()->GetName(
> ));
> }

But OTOH if it's not really meaningful to have M2 Troopers operating 
with the M1 "Bio", then we can return to viewing the "Bio" information 
as living in the game-specific monster classes, projectile classes, 
etc. - it would not be explicitly split out into a different "Bio" 
object.

Note that "classes" here may or may not correspond directly to C++ 
classes.  For example, an object of the "m2trooper" class might really 
be an object of a C++ class called M2Monster.  The AM class-name might 
(in this case) only be useful for locating (via the Bio) the related 
resources (physics info, graphics, etc.).  At some point though the code 
needs to be able to create a C++ object for the AM object of course.  So 
perhaps the "m2trooper" object itself (regardless of its implementation 
in C++) serves as a factory for C++ objects of AM class "m2trooper".

Note that a lot of this referencing stuff would be useful for a 
potential eventual scripting system as well.

Now hmm, C++ is not that pleasant a platform to use for 
object-orientation... so maybe AM should get together with the "Cocoa 
porting" guy, and produce a modular Marathon that's written in 
Objective-C, but uses just Foundation Kit stuff so that it can be taken 
to a variety of platforms via GNUstep-base or libFoundation, and uses 
SDL for graphics, sound, input, etc. (as much as possible), again for 
cross-platformability.  Then the files with map info and physics model 
info and shapes and sounds and so forth really could be archives of 
objects.  :)  (Unless the Cocoa porting guy is missing the point and is 
only using Cocoa for the UI and other high-level OS services, or 
something.)

Well I think that's plenty to chew on for now.  Sorry for the length and 
general disorganization.  Hope an ensuing discussion provides some 
illumination.  It may seem that most of these ideas are currently 
outside the scope of this project.  Guess it depends on the intended 
extent of the "modular" in "AlephModular".  :)  I guess many of the 
ideas (like the multiple-game-state stuff) are presented as rationale 
for the proposed inclusion of certain low-level mechanisms.  Obviously 
higher-level things like between-tick interpolation or run-time 
replacement of Marathon 2 Troopers with some kind of custom objects are 
pretty far down the road.  (Though not as far as they would be without 
the supporting mechanisms ;) ).

Woody

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

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

On Monday, January 13, 2003, at 06:29  PM, Br'fin wrote:

> It's all part of the same problem. AM doesn't yet have any code to tell 
> OSX 'Update the screen NOW' So AM changes the window buffer and OSX 
> updates the window at some point where system events are being 
> processed.

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

> I haven't addressed the issue because one of the areas I really want to 
> redo things involves the management of the buffers AM draws into. A 
> display module if you will, that on the platform specific side could do 
> things like 'use this window's back buffer' or 'Go full screen (and use 
> the DisplaySprocket unbuffered buffers)'

Ah but surely you mean (by telling SDL to SetVideoMode to a full-screen 
mode with page-flipping), or something like that.  ;)

> In other words, I didn't want to sprinkle random OSX-only polishing 
> QDFlushBuffer calls throughout the code when what I really want is to 
> abstract buffer management and kill the abysmal and unreasonable 
> framerates we're getting. Especially since the game really is rendering 
> more frames per second than is showing up on the screen.

Makes sense.

Woody

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

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

On Monday, January 13, 2003, at 06:50  PM, Timothy Collett wrote:

>> Oy, happen to have a crash log for that failure? Or has it repeat?
>>
>
> Umm...yeah, I do.  Here it is.
> <AlephModular.crash.log>
> And yes, it did repeat; I tried opening AM twice before throwing out  
> the preferences.
>
Well, I've opened a bug on SF for this:
http://sourceforge.net/tracker/ 
index.php?func=detail&aid=667491&group_id=69003&atid=523091

So if anyone else has a crash and gets a log entry that looks like:

Thread 0 Crashed:
  #0   0x00087ed8 in _Z32match_modification_date_callbackP6FSSpecPv
  #1   0x00022cc4 in _Z15enumerate_filesP12find_file_pbl
  #2   0x000228e4 in _Z10find_filesP12find_file_pb
...

Do feel free to post anything you find to that bug, and if you can't  
post files to the bug, then send them to me directly. This includes not  
just the log, but the Prefs file you were about to trash anyways.

-Jeremy Parsons

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

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

It's all part of the same problem. AM doesn't yet have any code to tell 
OSX 'Update the screen NOW' So AM changes the window buffer and OSX 
updates the window at some point where system events are being 
processed.

I haven't addressed the issue because one of the areas I really want to 
redo things involves the management of the buffers AM draws into. A 
display module if you will, that on the platform specific side could do 
things like 'use this window's back buffer' or 'Go full screen (and use 
the DisplaySprocket unbuffered buffers)'

In other words, I didn't want to sprinkle random OSX-only polishing 
QDFlushBuffer calls throughout the code when what I really want is to 
abstract buffer management and kill the abysmal and unreasonable 
framerates we're getting. Especially since the game really is rendering 
more frames per second than is showing up on the screen.

-Jeremy Parsons

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

> Actually it's almost exactly the opposite - a screen (like the main 
> menu) fades out when you click something, then fades back in while it 
> plays the "thunder"y sound for the chapter screen, say.  Then as soon 
> as the fade reaches 100% brightness, it suddenly "pops" to show the 
> chapter screen.  IIRC the chapter screen may pop back again at 100% 
> brightness after it fades out but before the game proper starts.
>
> Something similar happens when you click "replay saved film".
>
> iceBook 500MHz, 384MB RAM, Mac OS X 10.1.5 here.
>
> Woody
>
> On Monday, January 13, 2003, at 06:02  PM, Matt Lee wrote:
>
>>> Oh, and I noticed that same fading problem that Woody mentioned, 
>>> when fading either to or from the menu.
>>
>> Is that the one in which it "cuts" over to the new image immediately, 
>> then fades up from black? I have that too, on all the chapter screens 
>> and such.
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>

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

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

Actually it's almost exactly the opposite - a screen (like the main 
menu) fades out when you click something, then fades back in while it 
plays the "thunder"y sound for the chapter screen, say.  Then as soon as 
the fade reaches 100% brightness, it suddenly "pops" to show the chapter 
screen.  IIRC the chapter screen may pop back again at 100% brightness 
after it fades out but before the game proper starts.

Something similar happens when you click "replay saved film".

iceBook 500MHz, 384MB RAM, Mac OS X 10.1.5 here.

Woody

On Monday, January 13, 2003, at 06:02  PM, Matt Lee wrote:

>> Oh, and I noticed that same fading problem that Woody mentioned, when 
>> fading either to or from the menu.
>
> Is that the one in which it "cuts" over to the new image immediately, 
> then fades up from black? I have that too, on all the chapter screens 
> and such.

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

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

[resend because I sent it directly to Tim, heh]

Timothy Collett wrote:
>And yes, it did repeat; I tried opening AM twice before throwing out 
>the preferences.

It sounds a lot like the crash I had with the prefs recently as well.

>Oh, and I noticed that same fading problem that Woody mentioned, 
>when fading either to or from the menu.

Is that the one in which it "cuts" over to the new image immediately, 
then fades up from black? I have that too, on all the chapter screens 
and such.

I'm running 10.2.3 on a G4/400.

-Zebe

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

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

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

> Oy, happen to have a crash log for that failure? Or has it repeat?
>

Umm...yeah, I do.  Here it is.

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

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

On Monday, January 13, 2003, at 06:11  PM, Timothy Collett wrote:

>> ough perhaps. I myself just used the preferences mostly to get 50%, 
>> can't remember if the F4 key was working for me. Simple case. My own 
>> testing isn't really all that thorough as what you guys have been 
>> running it through. :)
>>
>> The vertical lines should show up in millions of colors+low 
>> resolution.
>>
>
> Okay, that they do.  I was on Thousands because of a problem I forgot 
> (heh!) to mention:  when I started it up, it changed the screen to 
> black, then quit, with just the generic "AlephModular has unexpectedly 
> quit" message, not the failed assert on wad file message; I deleted 
> the prefs and it ran fine.

Oy, happen to have a crash log for that failure? Or has it repeat?

> But on my machine, when I had it in lo-res, at 50% size, it still ran 
> fine, in Thousands and Millions.  Oh, how are we supposed to stop a 
> game without quitting?  Cmd-Q just quits, and Esc doesn't appear to do 
> anything, currently.
>
> Timothy Collett
>
Command-W (Close Window) to quit a game or replay in progress and jump 
back to the main menu.

-Jeremy

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

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

> ough perhaps. I myself just used the preferences mostly to get 50%, 
> can't remember if the F4 key was working for me. Simple case. My own 
> testing isn't really all that thorough as what you guys have been 
> running it through. :)
>
> The vertical lines should show up in millions of colors+low resolution.
>

Okay, that they do.  I was on Thousands because of a problem I forgot 
(heh!) to mention:  when I started it up, it changed the screen to 
black, then quit, with just the generic "AlephModular has unexpectedly 
quit" message, not the failed assert on wad file message; I deleted the 
prefs and it ran fine.

But on my machine, when I had it in lo-res, at 50% size, it still ran 
fine, in Thousands and Millions.  Oh, how are we supposed to stop a game 
without quitting?  Cmd-Q just quits, and Esc doesn't appear to do 
anything, currently.

Timothy Collett

How do you know the chosen ones? No greater love hath a man than he lay 
down his life for his friend. Not for millions, not for glory, not for 
fame... for one person. In the dark. Where no one will ever know or see.
--Sebastian, aka Jack, "Comes the Inquisitor"

[Alephmodular-devel] Changelog status

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

Here's the updated changelog I have going on. And while I'm ditzing on 
whether or not to try and replace some macros with inline functions, 
I'm also thinking of releasing a 0.3 build as well and just doing 
inlines in the future instead of macros in much the same way I'm 
dealing with C++ style casts (new casts are C++ style, but I'm not 
overly hunting down existing casts)

 From Timothy's testing, it looks like what I compile on MacOS X 10.2 
can and does run on his 10.1 box. Which is good to hear for me. Fewer 
caveats when I post a release.

Comments and criticisms welcome.

-Jeremy Parsons

AlephModular Changelog

0.3		Cleanup and Preparation
	Shorts and Longs converted to int16 and int32 to guaruntee bit size of 
values
	Quashed many many compilation warnings
	Removed much in the way of obsolete code
	Added autoconf support to make sure all elements of AlephModular agree 
on the current version
	Added icons and other branding elements to AlephModular (such as 
referring to AlephModular instead of Marathon in preference dialogs)
	Mark Levin's patch to get_my_fsspec for improved 10.1 compatibility
	Fixed a crashing bug when trying to use ambient sounds and jumping 
under water
	Fixed a bug when dying so your screen should cant around more
	Fixed a bug where really close enemies disappeared from view
	Fixed an MacOS X issue where AM would complain 'AM requires a 640 x 
480 screen and 256 colors' inappropriately
	Serialized loading of sound files

0.2		Getting Marathon to run
	Added serializing support (AStream.h/.cpp)
	Serialized loading of all files except preferences and saves
	Serialized saving of replays
	Partly serialized save games, depending on what was responsible for
		loading the data into memory.
		
0.1		Getting Marathon to compile
	Created ProjectBuilder file for MacOS X
	Merged in CSeries (Almost in sync with AlephOne)
	Converted all source files to C++
	random() changed to global_random()
	boolean changed to bool
	new changed to more appropriate declarations
	networking commented out
	carbonizing of code
	AlephModular boots, displays menus, thinks the maps are corrupted.
	
0.0		Initial Check-in to CVS
	All resource only files were shunted to the datafork
	All text files converted to unix style line feeds
	All MPW tools were removed
		(Should be able to rebuild them for the command line)
	The engimatic interface_editor (It looks like an application from the
		resources but has the file type of TEXT) was encoded in
		macbinary III

Re: [Alephmodular-devel] Re: AM: Obsolete code and render.cpp/scottish_textures.cpp

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

--- Alexander Strange <ast...@it...> wrote:
> 
> On Sunday, January 12, 2003, at 01:36 PM, Br'fin
> wrote:
> 
> > I just went into these files and removed the code
> blocks actively 
> > marked obsolete. Let me know if there are less
> obvious bits.
> >
> > -Jeremy Parsons
> 
> There are some function prototypes for spherical
> rendering at the 
> bottom of scottish_textures.h. THAT qualifies for an
> obsolete gem :)
> 

Cool! But I have to ask what type of spherical
rendering could that be?  Rendering like a fish-eye
lens?

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


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

[Alephmodular-devel] Re: AM: Obsolete code and render.cpp/scottish_textures.cpp

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

On Sunday, January 12, 2003, at 01:36 PM, Br'fin wrote:

> I just went into these files and removed the code blocks actively 
> marked obsolete. Let me know if there are less obvious bits.
>
> -Jeremy Parsons

There are some function prototypes for spherical rendering at the 
bottom of scottish_textures.h. THAT qualifies for an obsolete gem :)

[Alephmodular-devel] Random dabblings: Macros vs inlines...

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

I was randomly dabbling with trying to use the STL std::min/max inline 
templates in place of the cseries macros.

That was interesting. Finding myself having to cast one of the 
arguments whenever one was a literal, or an equation, or mildly 
different integer type was curious.

-Jeremy Parsons

Re: [Alephmodular-devel] (no subject)

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

On Thursday, January 9, 2003, at 10:52  PM, paul gronemeyer wrote:

>> If you applied
>> your conversion to one of the resulting projects (Like our 
>> AlephModular
>> or to the better features AlephOne) then you could give that whole
>> package of app and conversion away.
>
> Seems to be a good way. I guess Bungie has given away some kind of 
> lisence
> for it (?) As said, i tested Aleph One with mixed feelings.
> I did a lot of hacking with the original infinity app, but it remains 
> stable.
> Another thing is that there are still some images from the original 
> game
> (most characters) I guess, if i ever get this finished, it must be the 
> hard
> way of changing all
> Bobs and Phors to other species :)

Generally I'm afraid so. I'm not really up on all the licensing issues.

>> That sounds like Aleph One since we here at AlephModular don't have 
>> any
>> open GL support. Try asking over on 
>> mar...@li...
>
> Is AlephModular to be seen somewere ?
>
> Paul Gronemeyer
>
AlephModular can be seen at 
http://sourceforge.net/projects/alephmodular/

There's a 0.2 preview release. It's very early though. It only runs 
under 10.2 and even then has some known problems. (Do not turn on 
ambient sounds and dive under water for one :) )

We're working on it, but it's far from polished currently.

-Jeremy Parsons

Re: [Alephmodular-devel] (no subject)

[paul g. <pg...@gm...>]

oops

>From: paul gronemeyer <pg...@gm...>
>Subject: Re: [Alephmodular-devel] (no subject)
>Cc:
>Bcc:
>X-Attachments:
>
>>Yes it is, Welcome to the AlephModular developer list. :)
>>
>Ahh, great  :)
>
>> If you applied
>>your conversion to one of the resulting projects (Like our AlephModular
>>or to the better features AlephOne) then you could give that whole
>>package of app and conversion away.
>
>Seems to be a good way. I guess Bungie has given away some kind of lisence
>for it (?) As said, i tested Aleph One with mixed feelings.
>I did a lot of hacking with the original infinity app, but it remains stable.
>Another thing is that there are still some images from the original game
>(most characters) I guess, if i ever get this finished, it must be the
>hard way of changing all
>Bobs and Phors to other species :)
>
>>That sounds like Aleph One since we here at AlephModular don't have any
>>open GL support. Try asking over on mar...@li...
>
>Is AlephModular to be seen somewere ?
>
>Paul Gronemeyer
>
>

Re: [Alephmodular-devel] (no subject)

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

On Thursday, January 9, 2003, at 08:51  PM, paul gronemeyer wrote:

> Hi
>
> is this list active ?
>

Yes it is, Welcome to the AlephModular developer list. :)

> I have several questions regarding Marathon.
> As it seems, the app has become open source.
> So is it posible for me now to give away
> a conversion ?
> I did a lot of work in the past (as there was time)
> to bind my various maps together to a single game
> and would like to make this public somewere.

You couldn't do that with Marathon 2 proper (or its kin.) What Bungie 
sold in boxes is still their own work and product. What they released 
was source code with some libraries they used removed. If you applied 
your conversion to one of the resulting projects (Like our AlephModular 
or to the better features AlephOne) then you could give that whole 
package of app and conversion away.

> I tested it with aleph and it runs ok without  openGL
> With openGL it crashes, so what do i have to do ?
> What are the advantages of the openGL renderer ?
> (I already read somewere about semitransparent textures)
>
That sounds like Aleph One since we here at AlephModular don't have any 
open GL support. Try asking over on mar...@li...

You can subscribe to that list here:
http://lists.sourceforge.net/lists/listinfo/marathon-devel

-Jeremy Parsons

[Alephmodular-devel] (no subject)

[paul g. <pg...@gm...>]

Hi

is this list active ?

I have several questions regarding Marathon.
As it seems, the app has become open source.
So is it posible for me now to give away
a conversion ?
I did a lot of work in the past (as there was time)
to bind my various maps together to a single game
and would like to make this public somewere.

I tested it with aleph and it runs ok without  openGL
With openGL it crashes, so what do i have to do ?
What are the advantages of the openGL renderer ?
(I already read somewere about semitransparent textures)

TIA, Paul Gronemeyer