Re: [AD] split_modex_screen

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Saturday 22 January 2005 10:14, Chris wrote:
> 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.

Sounds sensible... isn't this partially what some of Allegro's modules 
already do in UNIX?

> > 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.

I thought it was already...?
In principle, I think the devision would be

Linux Console (maybe BSD console too? Not sure...)
X11 (basically, the only reneral UNIX port we have)
XFree86/X.org (DGA extensions and the like)


> 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),

Well, a binary distribution of the library should have all drivers linked 
in. Again, my point is not that the driver won't work at run time, but 
that the library doesn't even have code for it.
Obviously, the DGA driver only exists if the library was compiled with the 
option --enable-dga (in effect). I would expect the same to hold true for 
the GFX_DGA driver ID. However, the library being compiled with the driver 
enabled doesn't guarentee that it'll work at run time. These are seperate 
things.

> and it also forces all Allegro programs to be 
> recompiled if the library gains or loses drivers.

The same is true for Windows, due to changes in the layout of the DLL... I 
think.

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

It's listed as UNIX/X11 (just as Linux console is listed as UNIX/Linux 
console). IMHO, this is a slight misnomer, as it's really UNIX/X11/Free86 
specific. Well, the docs do say that Allegro supports it as a parameter to 
set_gfx_mode(), irrespective of wether it was build in or not. But I still 
think the docs are (were) wrong to say that. ;)

> 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.

True.

> 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.

Personally, I get really tired of seeing code that uses GFX_DIRECTX when 
AUTODETECT would work fine... if it were a viable option, I'd be for 
removing the specific IDs alltogether (but it's not really a viable 
option). I consider platform-specific driver IDs a nescessary evil in this 
sense.

> 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.

Well, my reasoning is that if it's always available, then the modex in its 
name is somewhat misleading. Having a split_screen() function leaves open 
the possibility of implementing similar functionality for a different 
driver. Ok, so we know no one is going to do that (;)), but at least one 
of the possible graphics drivers can do this anyway...
Ultimately, I don't feel very strongly about this either. I think it'd be 
nicer to rename it API-wise.

Evert