Re: [AD] Alleg5 - new driver structure idea

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


First of all I want to say I like the proposed interface. It elegantly 
solves compatibility problems.

> > There is also the issue of supporting older interfaces. What if we
> > add a parameter to blit() for example? We can make a "blit2" entry 
> > in
> > the driver, but then we also need to support the old "blit"
> > interface.
> 
> Or supply a default "blit2" entry, only used when the driver doesn't 
> provide it, which wraps around the original "blit" call.

Even better: the proposed AL_DRIVER_VTABLE_ENTRY structure has a 
"version" parameter that could be useful here. Suppose we have Allegro 
5.0 and a gfx driver that has "blit" version 5.0. On startup, Allegro 
would connect the driver hook with the internal AL_GFX_DRIVER_VTABLE 
version 5.0.
Now suppose in Allegro 5.1 the API changes and blit requires an 
additional parameter. Instead of updating all previous 5.0 gfx drivers, 
we only update the Allegro internals: the AL_GFX_DRIVER_VTABLE would 
change supporting only the new blit (5.1), and on startup the lib would 
look at each driver blit() version. If 5.1, directly connect the 
function hook, if 5.0 connect API blit() to a wrapper function that 
calls the new blit adding a fake new parameter.
The result? Old drivers should always work providing they're not really 
ancient and the API changed *too* much since they were released, and as 
long as we provide legacy code. Or am I missing something?

--
Angelo Mottola
lillo@xxxxxxxxxx



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/