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

["Angelo Mottola" <a.mottola@xxxxxxxxxx>]

Ok, I've been out to my university all day and when I've returned, I
found 33 AD messages most of which about this subject, so even if a lot
has already been said, let me tell you my thoughts.

> - Switch to completely disable the Allegro mixer, and send
audiobuffers to the sound card directly. (TRAC)

Hum, I'm not a sound programming expert, but removing our software mixer
wouldn't mean to loose a lot of functionalities?

> - remove those unused sound functions (vibratto, etc)

Agreed. I guess those have been there (empty) since something like
3.0...

> - Possible merge of AllegroGL (as an OpenGL driver only, to keep it
light)

I'm all for it! By "as an OpenGL driver only" do you mean to implement
only the current AGL "direct" mode? If so I agree again as I don't see
any reasons on including the others.

> - merge blit and sprite API

I agree, but how to recognize when to draw a transparent bitmap (sprite)
or a solid one? What about using al_set(AL_BLIT, AL_BLIT_TRANS) or
al_set(AL_BLIT, AL_BLIT_SOLID)?

> - window resizing support

Is this really needed? I think it'd require so much overhead it isn't
worth it at all. Who really needs window resizing in games? Ok, Allegro
is also for general multimedia apps, but again I'm not convinced on
adding support for this...

> - is_*_bitmap collapsed to a single function - get_bitmap_type()

Sounds reasonable as it avoids making confusion with all those similar
functions. And makes the API cleaner.

> - What to do with floodfill (can't be accelerated via GL or D3D)

Some programs may need it, so I don't think removing it is a good idea.
GL and D3D could just have a slow unrecommended implementation (stated
in the docs) or not have it at all (but this would mean making floodfill
part of the gfx vtable, which isn't a bad idea at all)

> - Hooks in the polygon routines to add our own span-based sorter.
>   This means that ZBuffer, SBuffer, and P3D can spun out to other
libs.

Ok about the hooks, but leave the other things as people may complain
about them if they're missing from the default lib. IMHO P3D can be
moved away as it's the most recent one and hardly anyone has used it so
far (AFAIK).

> - Make blenders work with spans (see FBlend)

Agreed =)

 - Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
int32_t instead?

In Allegro tradition all types and structures should be uppercase, so I
propose INT16, INT32 and such. Just thought someone had to say this ;)

> - textout should not use -1 for colored fonts.

Again al_set(AL_FONT, AL_FONT_MONO) and al_set(AL_FONT, AL_FONT_COLORED)
come to my mind... Or simply the textout function could recognize the
colored font and use the proper drawing function, discarding the color
value passed to textout.

> Input:
> - Message based (see SDL)

The callbacks suggested by Eric sound also interesting. Could you
elaborate more?

> - Remove compression/encryption. This can be spun off to a new lib.
>   Basic endian-safe pack functions can still be present.
> - Allow registering of new compression and encryption libs.

I'm against removing the compression support, as I find it nice and
useful. But having hooks to define new compression routines seems a
great idea - zlib comes to mind

> Network:
> - Can we get one? Please? :) 

It would be really nice to have libnet integrated into Allegro. But I
can understand many of you will disagree for a lot of good reasons.
Nonetheless I like the idea. And what about adding a generalized
framework of network functions, that could be used to hook on other
packages? Libnet could be just one of the possibilities (and here I'm
talking about the nth vtable to Allegro)

> - Configuration via an OpenGL-like al_set(variable, value) system
> - prefixing of the API

Agreed on both. Al_set() could be a really powerful tool, and it would
also give a nice side-effect: in some cases adding new features will
just mean adding more variables/values, without overbloating (tm) the
API with more dedicated functions.

> - Move as much as possible to Vtables

This seems inevitable to me.

> - Drop DOS.

Psss! A hint: don't propose this once again, or someday you'll find
hordes of angry people knocking at your door!

> Documentation:
> - Generated from source via Doxygen or Javadoc (see AllegroGL for
example)

Here I agree on what Sven said: the _tx format should be kept.


> Stuff to remove (can be placed in add-ons)
> - FLI playback code
> - Software 3D code
> - 3D Math
> - Fixed point math
> - Compiled sprites and RLE
 
Ok for FLI and compiled sprites, but keep the rest. Dunno about the 3d
math, but if kept it should be possibly modified to be compatible with
OpenGL (see matrices).

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com