Re: [Alephmodular-devel] Platform-independence structure (was: Developer Rant #1 :) )

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

On Tuesday, January 14, 2003, at 09:35  PM, Woody Zenfell, III wrote:
>
> Well I say the first effort, but I guess I don't really mean that - 
> the first effort _could_ be Mac OS only, as long as that code knows 
> it's doomed, and is, in fact, replaced to the greatest degree possible 
> with more portable code when the latter arrives (which I would hope 
> would be very shortly thereafter).

My desire is to encapsulate the MacOS Specific code into areas that are 
specifically labeled for the MacOS platform. Here's the find file API 
and under MacOS this is implemented with MasOS specific foo. The degree 
to which this happens does have several criteria, including actively or 
passively breaking classic compatibility. (OSX code itself can lean 
much more towards meshing with unix definitions, of course :) )

> From my point of view one of the major problems with A1 currently is 
> that there are often two versions of the same thing "in parallel", 
> when the cross-platform case *could* completely replace the Mac 
> OS-specific version.

A1 has far more things "in parallel" than it should. I don't agree with 
you, Woody, on which things should be shared. But I agree that A1 
proper doesn't share enough. I applaud you and whoever else managed to 
get SDL working with A1. The basic code only has some nods towards 
cross-platform issues.

>> 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 :)
>
> I'm not convinced this is the case - or more accurately, I'm not 
> convinced that modularizing A1, rather than M2, and then adding the 
> new features would be more effort.  But, as noted, it doesn't really 
> matter at this point.

Remember all those "in parallel" elements you mentioned? A1 has both 
Mac VS SDL and software renderer vs openGL. You've a lot more stuff to 
worry about breaking. On top of that, certain areas continue to feel 
mis-implemented. OpenGL HUD flicker still seems to be a lingering 
complaint and problem.

> Ok and as a final parting shot about the SDL stuff, it is completely 
> possible and practical to use, say, SDL_Video to insulate you against 
> the differences between DisplaySprocket and DirectDraw et al., or 
> between wgl and agl et al. (for attaching OpenGL contexts to on-screen 
> windows etc.), etc. without committing to using SDL_main to insulate 
> you from differences in application initialization between platforms, 
> and without committing to using SDL_event as the basis for your event 
> loop.  (Perhaps Br'fin's negative experiences have primarily been with 
> these latter components.)  So you can mix-n-match.  :)
>

I believe Bryce over at Bochs would love to know how to defer/control 
SDL initialization so that it's only incorporated when the SDL UI 
plugin is used instead of it's current behavior of stealing main(). I 
presume that AlephOne carbon has had it's main hijacked (SDL is a 
requirement to including SDL_net) but I wouldn't notice so much there. 
It's menus aren't visible after all.

SDL may or may not be appropriate within AM based tools. Mostly it 
would depend on how nicely it can play with others.

-Jeremy