Re: [AD] Rewritting set_gfx_mode (was: GFX_WINDOWED)

[George Foot <gfoot@xxxxxxxxxx>]

On Sun, Apr 08, 2001 at 11:37:31AM +1000, Peter Wang wrote:
> As for a plan, well, I'd like some feedback on my aforementioned
> patch.  If everyone agrees it's a good idea, then you could redesign
> `set_gfx_mode' with plugin drivers in mind (right now I had to do a
> bit of a hack).  I think this goes hand in hand with Laurence's
> driver registration idea.

Sorry not to respond sooner about that, I've been distracted
this week. :)

I got totally the wrong idea what you meant. :)  I thought you
were talking about having a library containing wrappers for
SVGAlib calls, which would either be stubs present just for
resolving the symbols, or would chain to the real SVGAlib calls.
I hadn't thought of using Allegro's existing indirect calls to
call into the plugins -- that's good, it pretty much removes any
loss in efficiency.

The hack to fit into the existing system is definitely the worst
part of the code. :)  If the new system supports drivers
registering themselves dynamically, instead of requiring static
entries, it'll simplify this a lot.  This involves looking a bit
at the system drivers too, which are sometimes responsible for
dynamic driver lists, but sometimes just use static lists.
Maybe that won't be necessary any more, if we can centralise it.

To be most useful, this system needs to also cope with other
types of driver.  I'm thinking mostly of X here -- as Peter
said, that could pose problems, though I think it shouldn't be
too hard to disentangle.

Should plugins only be allowed to supply one driver type, or
should they hold (optional) lists of drivers?  e.g. have
symbols: `gfx_driver_list', `sound_driver_list', etc, which (if
they exist) contain NULL-terminated lists of pointers to
supplied drivers of that type.  This allows one plugin to handle
everything which hangs off a particular library.

OTOH it might be better still if we just use the plugin's _init
routine to register its drivers.  That gives plugins the most
flexibility.

A nice thing about the plugins is that they don't only apply to
standard drivers -- addon libraries can produce plugins too.

Real plugins ought to have version numbers (maybe partly stating
the dependency shared library version) in their filenames.

I was thinking that it's probably good to install all plugins
from $libdir/allegro/$version, but I've changed my mind because
the load order might be important.  Instead, we should probably
have a text file or something listing the plugins to install.

Also, the mksvgalib.sh script in the patch tries to build
svgalibs.s with -fPIC -- I think -fPIC only affects the
compiler.  But, since these are dynamic modules, not shared
libraries, it doesn't much matter whether they're PIC or not --
or does it?  If it does matter then we may have some problems
with the assembler code, unless someone actually knows what
makes code PIC or not.  Most of our assembler is pretty simple,
so shouldn't cause problems, but I've never found much
explanation of why gcc needs to generate different code for
shared libraries.  My only guess is that things like global
variables need to be looked up in tables, according to who
called the routine, and in this case I doubt plugins need to be
PIC.

Hmm, sorry for not being very coherent! :)

George

-- 
Random project update:
06/03/2001: AllegroGL 0.0.10 released at http://allegrogl.sourceforge.net/
	Six months' worth of changes, including Mingw32 support!