Re: [AD] Shawn's thoughts about new Allegro

[Stepan Roh <stepan@xxxxxxxxxx>]

On Thu, 13 Dec 2001, Grzegorz Adam Hankiewicz wrote:

> Hi.
>
> Since there's plenty to read, the real text is here:
>
>   http://alleg.sourceforge.net/future/shawns_thoughts.txt (52Kb)

I read it through and because I have some free time (30 minutes :-) ), I
will comment on it now and here (may act also as a summary, maybe, but
don't forget to read Shawn's text before commenting).

Shawn, you always wrote interesting documents and this is one of the best.
Almost all I had on my mind is written there, great!

---

Leadership and open discussion:

I agree with Shawn that direct democracy is not the best. Allegro has
maintainers (those having CVS commit rights), but they have no formal
status. I think one or two (or three) of them should be elected ( :-) ) to
be leaders and lead Allegro towards future. Well, after Shawn "retired" I
proposed George Foot to maintain Allegro, but that topic lead nowhere.
George is less active these days as he is busy at work (am I right?), but
Peter Wang, Eric Botcazou and others would be capable of doing design
decisions too.

Breaking compatibility:

I think it is necessary because some parts of API are badly designed
(sorry, Shawn ;-) ) and unfortunately whole API is unprefixed. I once agin
agree with Shawn that if we're going to break it, break everything. I was
proposing (although it was not my idea) steps prefixing, modularising
source and modularising code (binary modules). I like it still, but API
could be cleaned as well as prefixed at once. Then some source code
cleanup (and source modularising) can be done.

I agree with all the points "get it right the first time", "make it easily
extensible", "don't break it anymore", "automate old code upgrades". Think
before commit, that's the right way.

Non-working codebase and different maintained codebases:

I totally agree that codebase which is not working for long periods of
time is bad, but will there be anyone which will take a week off in
process of rewriting API?

Allegro will have different codebases after API will be redesigned. But
will 4.x series need maintanence? I don't think so. There are no major
problems, instead of some reocurring "DOS under Windows", "Linux DGA",
"hardware scrolling" and similar problems which can't be solved without
some major code rewrites, if can be solved at all (that's IMHO, of
course).

Allegro on 3D or 3D in Allegro:

Making Allegro use 3D under the hood is wrong idea (as Shawn said). But on
the other side (AllegroGL people will agree with me), it could simplify
porting Allegro to new platforms. I don't know.

For the second, 3D in Allegro, I have to say, that I never really
understood why there are 3D routins in Allegro: they were slow (they were
terribly slow on my 486 :-) ) and better, specialised, APIs are on the
market. Throwing 3D support away (not necessarily to trash, but to
something like Allegro 3D-lite Add-on) would be nice.

Using floats: Don't change what works, but new code can use them.

Prefixed API, no globals: I'm all for it.

CPU detection: Yes, it's a mess and has no usefulness, except for MMX/SSE
detecting.

Extending config files:

Config files need a redesign. API is hard to understand (push/pop and
override functions...) and config file format is very inflexible (there is
no way how to store string with leading spaces and I'm glad that Shawn is
finally on the right side :-) ). Altough XML (and DOM) can be used
(lightweight XML parsers are very simple) and I like it much, sticking
with current-like format will be better. But I like dot-separated
Java-like variable names more than slash-separated file-like ones. But
don't forget to use "..." quoting for strings. I want leading spaces in
them!

Input and timers:

I totally agree with Shawn that callback based input is not good. I did
callback-based event processing library in the past and it was a pain and
hard to debug. Message queues are too high-level. Polling system is
probably the most reasonable solution.

Timers having their units in PIT hardware clock rate are very rare in
other libs. That could be changed to microseconds (seems to be widely
adopted standard) very easily.

Graphics:

I agree with simplification Shawn proposed (drop hardware scrolling,
unify sprite functions, simplify text output).

Compiled sprites are very limited and hard to maintain (that's IMHO, of
course).

Moving FLIC player to the addon: I'm all for it.

Modular packfile routines (chaining): I'm all for it. Although it's a
little bit tricky in C (I did something like that in the past).

Removing compiled datafiles and dat2s (or dat2c): I'm all for it.

Code layout: Use indent through whole lib.

Extreme modularisation (with modules working only on subset of supported
platforms): I'm all for it (as stated above).

Video memory comments: I can't comment on it. But there seems to be a lot
of people using DOS Allegro under Windows which will got angry in case of
turning on fat-DS selector method. But it is unstable combination anyway.

---

That's all from me, I'll shut up now :-)

Unfortunately I have almost now free time to actually code anything. I
hardly maintain my Allegro Source Browser (my code parser is confused by
Allegro starting few WIPs ago). Damn... :-(

Have a nice day.

Stepan Roh

P.S.: Had we celebrated 6 years of Allegro on November 11? I can't
remember :-)