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