Re: [AD] Proposal for Allegro's future (namespaces, et al.)

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


> Hi,
>
> This is my proposal for Allegro's future:
>
>  - we don't change the API (ie. no prefixes)
>  - perhaps we do something about clear(), since it stops us using
>    ncurses, which is very unfortunate.
>  - we don't add new stuff (GUI skins, 3D graphics stuff), but we do add 
>    new implementations (new drivers, optimised routines, et al).
>
> Then, if some people are so inclined :-), they can implement
> AllegroZilla, which would:
>
>  - use the Allegro library, but on compilation, all symbols would be
>    renamed via preprocessor defines, to implement prefixes.

I don't like this step, it just feels not right to use other symbols in
the library source than in a user program for me. I.e. "al_create_bitmap"
*always* should be named like that, and not "create_bitmap" at some places
and maybe even something else at others.

>  - have lots of new stuff (GUI skins, etc).
>  - merge in AllegroGL
>  - change broken API stuff (6-bit palettes, maybe others)
>
> And then people can choose between Allegro and AllegroZilla, and
> everyone will be happy.

Yes, besides what I said above, I like this idea :) I would even go a step
further and make AllegroZilla modular. I.e., if I go to the AllegroZilla
download site, I check: [x]sound-support [x]unicode-support, click on
download, and "make" gives me a lib with unicode and sound routines to use,
which i might want to use to handle unicode-strings, and play sound.

Or i check: [x]framebuffer graphics [x]file-routines, if i want to make
a bitmap conversion program.

Or i check: [x]graphics [x]gfx-linux-DGA2 [x]gfx-linux-soft
[x]gfx-beos-accel [x]input [x]sound-support, to make a game which runs
under linux and beos.. if I give the source to someone who wants to use
different gfx drivers, they can just be replaced, e.g. by [x]gfx-directx.
Probably the same would be with sound drivers or everything where there
are different drivers (which already are modular in Allegro).

Probably there would be to think a lot more about the different modules,
and about modules/drivers dependencies, but at least I like the idea of
Allegro(Zilla) being completely modular, not just some of the drivers..

Just some thoughts..

--
Elias Pschernig



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