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

[Bob <ohannessian@xxxxxxxxxx>]

Laurence Withers wrote:
[snip]
> Then, if some people are so inclined :-), they can implement
> AllegroZilla, which would:

I personally think that Allegro 5.0 should have a new API (yes, it will be 
incompatible with Allegro 4.0). I don't have any specific ideas on this yet, 
but if the transition from 3.1 to 4.0 is of any indication, we will get 3 or 
4 years to build a robust, extendible, portable API :)

I would think that after 4.0 (or 4.1?), Allegro should be forked, and the 
only thing going in the Allegro 4 series would be bug fixes or speed 
optimizations (kinda like when 3.12 was released in the middle of the 3.9.x 
series).

Elias's idea of being able to download modules individually is good. Perhaps 
the web site could also generate a makefile that would compile everything?

>  - use the Allegro library, but on compilation, all symbols would be
>    renamed via preprocessor defines, to implement prefixes.

Then we're still stuck with the old (broken in some places) API.

>  - have lots of new stuff (GUI skins, etc).

What about the GUI stuff on the GUI list? Could be interesting.


>  - merge in AllegroGL

Wasn't that the plan all along? :)  AllegroGL will never fully replace the 
DDraw driver though since there are things that OpenGL can't do, or can't do 
fast. Unless we drop things like video bitmaps sharing the same memory as 
the visible screen, etc.

Matthew Smith wrote:

> And some things I would like to see in some bigger versions (just a short
> list OTTOMH)

> -48/64/96/128 bpp bitmaps

I could see a use for floats as color component, but having 128 bit integers 
just doesn't seem right. Perhaps an 8.8 fixed point format for the 
components? This would allow better precision for when doing lots of 
blendings of the same batch of pixels.


> -64 bit API

I don't see what that would get us. What I would like though is that Allegro 
5 uses specific size types (int32_t, int64_t, etc). Support for 64 bit 
pointers (I32LP64) would also be nice.


> -Allegro specific IDE

Dev-C++ with a few enhancements? We could make a few templates for linking, 
and possibly add name completion of Allegro functions. Having a debugger in 
there would also be nice.


> -Allegro BASIC (go ahead and laugh) and scripting

I don't think it's a priority. Perhaps it could be started off as a seperate 
project, then later on merged?


> -Dynamic module loading (a.k.a. applets)

Sounds good. DOS will be a pain though :/


> -Real time event dispatch engine to enable multitasking between Allegro
> programs on O/Ses like DOS

Is DOS support really required? As much as I'd like for DOS to stick around, 
it prolly won't exist after WinXP...
Supporting DOS should be a low priority IMHO.

I would like to add:
- Networking support (libnet merge-in?)
- OS GUI, something like Qt or GTK maybe?
- D3D driver (to complement the GL driver)

The API will have to kept as simple as possible. I wouldn't want to see 
Allegro turned into DirectX 3...



--- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/