On Tue, 23 Oct 2007 13:12:16 +0300, Evert Glebbeek <eglebbk@...> wrote:
>> It's just a lot of work.
> Well, sure. Never assumed it'd not involve work!
>> Currently, we have a compatibility layer
>> where all A4 calls render to a special memory buffer, and then that
>> buffer updates to the screen - that defeats the purpose though as it
>> is inherently slower than just using A4 directly.
> True, but it doesn't have to be perfect. In my mind, the first
> purpose of the compatibility layer is to compile existing code. It
> doesn't need to take full advantage of the new capabilities in the
> first release.
> There even need not be any guarentee that a function call that
> succeeds in Allegro 4 needs to succeed in vanilla 5.0 (split_screen
> (), scroll_screen() or whatever they're called being prime examples
> of somewhat obsolete functions that could just fail and that probably
> no one will miss anyway).
>> maybe config APIs and not spend time on compatibility. After that, we
>> basically have A5 (Trent already wrote two A5 games, so things do look
>> good) - and I wouldn't want to delay the official A5 release by a year
>> or so just to get the compatibility layer in.
> Well, no, it shouldn't take a year, no. But I do think it would be
> good to have the compatibility layer in the release labelled as
> '5.0'. Even after 'A5' is basically done we'd have to go through a
> sequence of WIP/beta/RC.
Just throwing an idea, but the compatibility layer doesn't *have* to be
the job of the Allegro developers. If there is a real need for one, users
can step up and write an add-on library.
Just make it very clear that A5 won't be compatible with A4 well in
advance of the release, to give A4 users the chance to a) either update
their projects or b) write the compatibility layer. An announcement in
a.cc would be a good idea, as soon as the new API gets semi-stable.