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