Re: [AD] future.html on the website

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


On Tue, 23 Oct 2007 13:12:16 +0300, Evert Glebbeek <eglebbk@xxxxxxxxxx> 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.

Evert


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.




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