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