RE: [AD] Proposed changes for Allegro 5 (6?)

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


Title: RE: [AD] Proposed changes for Allegro 5 (6?)

Hi,

my humble opinion about these:

> merge blit and sprite API
Could you be more specific about what to change ? without losing speed.

> is_*_bitmap collapsed to a single function - get_bitmap_type()
You could have a subbitmap of a video bitmap (I think), so a bitmap
could have more than one type

> What to do with floodfill (can't be accelerated via GL or D3D)
And then ? That is not a reason to remove it I think :)

> Collapse load_* into one function load_bitmap(), smart enough to read
> the file header to determine the format.
There is no such thing: TGA has no header, PCX has a riducully small one,
making it very awkward to detect. However, if we *know* the user can't
ask to load a non TGA-or-PCX-or-LBM-or-BMP file, then it becomes easier,
but I don't think it's feasible (eg user selecting an image file in a
directory pick dialog)

> Speed ups in the asm code
I remember Shawn saying that the lit and trans routines were faster in
C than in asm :)

> Message based (see SDL) (about input)
In addition to the current API, right ?

> Can we get one? Please? :) (about network)
Well, I'd agree with that, even with the argument that libnet exists.

> Configuration via an OpenGL-like al_set(variable, value) system
I'm not too hapy about that. That's... well, odd. You lose type safety.
And the code is a big switch. Not appealing.

> Some of the little used variables converted to strings
Making them more difficult to use ?

> Drop DOS
No comment :)
Ah yes, one: why remove it while it's working fine ????
It could be possible to not implement stuff that it doesn't support
though, like switch in/out callbacks setters (they nop on DOS).
This allows other stuff to be added while keeping DOS compatibility.

> Have a Windows installer built from a script (PIMP?)
Huh ????? :)

> Stuff to remove:

> Fixed point math
That's being used in quite a few of Allegro's routines themselves
(hmm, almost all are variations on rotation, though).

> Compiled sprites and RLE
Heh ????? If you remove RLE sprites, I'll get angry :)
That's one of the features that actually make Allegro useful. Moving it
away in an add-on is pointless, as they're quite core, I think.


On a general way, I'd like to point out the obvious: moving stuff into
addons means that they're far more likely to rot. So moving stuff into
addons should be weighed carefully.
What could be done is to split Allegro into parts which would be like
addons, but still part of Allegro. A new release would not have to
included updated parts of all parts, meaning that, say, packfile
comrpession work needs not delay a release, but Allegro can still
count on packfiles being part of Allegro (and thus use them in the
lib). This would need fairly extensive work to get rid of many
dependencies though.
Anyway, that's a nice list, thanks for taking the time of doing it :)

--
Vincent Penquerc'h



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