Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Monday, October 6, 2003, at 11:06  PM, Alexander Strange wrote:

>
> On Oct 6, 2003, at 10:39 PM, Br'fin wrote:
>
>> I should still update the documentation. But yes, I should be done 
>> with the abstraction for the time being. (More will need to be done 
>> when new graphic features are added.)
>
> I think the next step would be 3D graphics abstraction (including 
> possibly the vis-tree and poly-sorting code; A1 split those into C++ 
> classes).

Since I'm unfamiliar with that code, I do need to ask 'What does 
abstracting the 3D Graphics do for us?' In the case of files, it was to 
abstract us from Mac file conventions and handling. (Resources are the 
main aspect left there.) In the case of the display abstraction is was 
to forcefully drag apart all the Mac-based drawing code from the 
Marathon code that used it. (For instance, the terminal was a really 
nasty piece of entangled code.)

Some of the places in AM that I think are prime targets involve:

	* Resources
	* Input Handling
	* Main Event Loop (May be related to Input Handling)
	* Game Related GUI (File dialogs, ok to quit?, preferences)
	* Preferences

I admit Preferences is less about platform specifics and more for 
overhauling how the game uses preferences internally and how the game 
handles preferences. I've been trying to think of a system that allows 
for future preferences growth, while allowing conversion of older 
preference formats. And which allows growth without necessarily 
requiring a great deal of work between changes either.

I spoke with Woody and another with regard to preferences in general 
and A1 as well. I tried to present a writeup under 
alephModular/documents/technical/CPreferences.h

I still haven't decided on a direction, though have been tempted to try 
and work on the Carbon implementation of the display abstraction. Right 
now I'm just kvetching at sf.net's CVS systems which seem to be 
unavailable.

-Jeremy Parsons