Re: [AD] split_modex_screen

[Chris <chris.kcat@xxxxxxxxxx>]

Evert Glebbeek wrote:
> > Also, there's something else you need to consider, with Allegro 
> > Unix/Linux binaries. If the person compiling the binary doesn't have 
> > GFX_DGA capabilities, then that binary will never work with DGA, even if 
> > the end-user's library can handle it.
>
>
> I know, I mentioned this.

Allegro can be designed to dynamicly load modules via dlopen.. which I 
think might be a worth-while option in it's own right. The main lib 
would have a list of allowable (user-modifyable?) modules that would be 
loaded upon allegro_init.. if the module doesn't exist/fails to load, 
it's simply skipped/disabled. However, this would have to follow the 
idea that the available drivers can't be known at compile time.

> Well, there are probably more UNICES out there that don't have the GFX_DGA 
> extension than there are that do...

If you want to split up the Unix port (or at least it's installation 
methods) into X, Linux Console, and Generic Unix I'd have no problem if 
the seperate systems had different driver sets (ie. if configure builds 
for X both Linux Console and X drivers would be available, or if 
configure builds for Linux Console the X drivers are missing, etc.).. 
since that would kinda qualify as a seperate systems. But if a driver 
can potentially exist on the target platform, the driver defines should 
be there in case the available drivers at run-time are different than at 
compile-time.

> I also have the feeling that this is the normal behavior for a UNIX 
> library, but here I could be way off.

Perhaps for source-only distribution methods.. but if we want to appeal 
to (possibly closed-source) Unix binaries distributing (like commercial 
programs that use SDL), we can't restrict the library like that.

> What bugs me about always having the driver identifier is not that the 
> driver will not work when it is tried, but that it isn't even there!

Well.. that thinking only holds up when you know the compile-time and 
run-time drivers are gauranteed to be the same. Binary distributions 
cannot gaurantee that in any way shape or form (as long as it's dynamic 
linking, anyway), and it also forces all Allegro programs to be 
recompiled if the library gains or loses drivers.

> The 
> next logical step in this line of reasoning would be to always define 
> GFX_DIRECTX too, since the docs aren't too clear on that being undefined 
> either.

GFX_DIRECTX is clearly labelled Windows-only, though. GFX_DGA is 
labelled Unix-only, not Unix-only-and-only-if-support-is-compiled-in.

> Anyway, I have a feeling that neither of us is going to convince the 
> other... ;)

Mmm.. maybe. But this really has me thinking. What do we need checking 
driver defines for?

Well for one, and is the original problem that spawned the thread, to 
test if a certain API function is available. Having global API functions 
disappearing based on driver availability is something that should not 
really occur anyway. If it was a system/OS-dependant function, that'd be 
a little different (as long as it's clearly marked as such).. but it's 
not, it's a library function. So this should be fixed regardless of what 
happens with the defines.

A second use would be for using the driver id's. As stated before, this 
only works as long as the compile-time and run-time drivers are the 
same. If they can be different, you'll want the id's available by 
default since you won't know if it'll work until run-time. Obviously one 
could state "Well, you won't know if GFX_DIRECTX will be available at 
run-time or not either." and in actuality, you'd be correct (Winelib, 
anyone?). However, the drivers are clearly marked for which OS they 
belong to, so leaving them seperated there is not a problem. If the user 
adds a driver to the hypothetical list "loadable modules", they'd be 
responsible for keeping track of its (unique!) id.

The only other reasons for checking I can think of can be done just as 
well with a run-time check.. like a:
int driver_is_available(int id);
function. It'd search a table of loaded driver id's, returning true if 
the driver was loaded successfully by allegro_init.

> In that case, I think we should rename it to split_screen(), as it's 
> effectively a driver neutral function in that case.

Well, it does only affect Mode-X so renaming it may cause some 
unnecessary confusion. But I can't say I have a strong opinion either way.