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