Re: [AD] split_modex_screen

[Chris <chris.kcat@xxxxxxxxxx>]

Evert Glebbeek wrote:
> 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?

I think they're loaded at load-time with the main lib, instead of at 
run-time with dlopen. AFAIK, the only modules that get loaded are the 
ones explicitly linked in via `allegro-config --libs`, which is created 
when the library is compiled.

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

Sounds sensible. But AFAIK, configure will disable those specific 
extensions when they're not detected, but it'll still build it as 
"Unix". Myabe I'm wrong though.. there are the linux/, x/, and unix/, 
sub-directories. Just don't forget that Linux/BSD console drivers are 
available in X and X11 drivers are available in XFree86/X.org as well. :)

> Well, a binary distribution of the library should have all drivers linked 
> in.

Of the library itself, yes. But just like with DLLs, the user can use 
their own library instead, as long as it's compatible.

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

The library itself doesn't really have code for much. If the modules 
become truely modular (ie. using dlsym to get and use int 
get_driver_type() and int fill_driver(void *drv) global symbols for each 
module/driver, with the rest of the module being all static) then the 
library wouldn't have any code for the drivers.. only code for 
interfacing them.

> However, the library being compiled with the driver 
> enabled doesn't guarentee that it'll work at run time.

And I think the reverse is, or should be made to be (like with a true 
modular design), true as well. Just because the program is compiled 
without support, doesn't mean it might not be available at run-time.

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

That's a DLL limitation (and as has been mentioned, you can't easilly 
disable drivers in WIndows). Unix .so libs will still work as long as 
the accessed symbos are still present, the symbol types (return 
value/parameters/variables) remain the same, and that structures don't 
change (too drasticly).

> Personally, I get really tired of seeing code that uses GFX_DIRECTX when 
> AUTODETECT would work fine...

Agreed.. but there are uses where using them directly can be 
beneficial.. like with a dialog supplying a list of available drivers 
that the user/player can select directly (ala select_gfx_mode). FakeNES 
has a menu that lists the different drivers for the different platforms 
(using the OS defines to pick which menus were available).

> Ultimately, I don't feel very strongly about this either. I think it'd be 
> nicer to rename it API-wise.

If you do it, don't forget to add a depricated wrapper and to comb the 
code for any instances of it. It might just be simpler to leave the name 
alone, though. It would be cleaner to make a gfx_driver hook for it, 
however.