Re: [AD] A New Allegro Thread starts here....

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-01-08, Karthik Kumar <karthikkumar@xxxxxxxxxx> wrote:
> 
> I had this question, I asked in #allegro:
> 
> What IS Allegro?
> 
> 1. is Allegro an image loading library, like DEVIL? (No)
> 2. is Allegro going to turn into a polygon pushing library, like D3D or
> OpenGL? (no)
> 3. is Allegro a 2D / primitives library? (good response)
> 4. is Allegro an input wrapper for keyboards, pointing devices and
> joysticks? (like DInput) (good response)
> 5. is Allegro a sound library? (good response)
> 6. is Allegro an event scheduling/timer library? (mixed response)
> 7. is Allegro a video playing library? (most answered no)
> 8. is Allegro going to do CD Audio, Networking, and what not? (no)
> 9. is Allegro a font library, when compared to D3DFonts, Freetype (no)

I would have to agree with the answers, but your question is phrased
badly.  Asking "is Allegro a font library" is going to get you nothing
but a big fat NO.  In fact, Allegro IS none of the above.

> I had a few more thoughts on Allegro... If Allegro were low level, it would
> just push data in and out of the CPU/GPU/Whatever .. then there's no calling
> it an API, in the real sense (which is an contradiction to Shawn's own
> thoughts) If it weren't, there ought to be an abstraction API.

Makes no sense.

> End of the day, most of these conflicts simplify to one question: low level
> or abstract?

Those are not even opposites.  e.g. C is an abstraction, but it is also
low level.  You could argue the same of assembly language, or machine
code (or circuits, electrons, ...).

> If it were low level, it wouldn't make any difference than the OS APIs do.
> It it were abstract, it won't be the low level library, would it?

Allegro is low level in the same way that OpenGL is low level.
Allegro is not "abstract" (whatever that means) but it does abstract
away the hardware, the OS, etc.

> I also said in #allegro that the design and specifications aren't available
> yet. There is no document which states how Allegro should behave, what each
> function would do, how and when would each function work/fail.

For some of the new API functions we do have design documents.  They are
admittedly out of date and help would be appreciated bringing them into
the mainstream, i.e. updated and either integrated into the current
manual or starting a new one.

For functions that don't exist yet, we _do_ (or did) try and document
how it should work before writing too much code.  This requires:

- understanding the limitations of the current API
- understanding what we want the new API to do
- feasibility and possible implementation of a new design over
  multiple platforms

The last point at least requires some experimentation with code, or at
least looking at some existing APIs which operate similarly.

We already did some of this; maybe you weren't aware of that.
Of course, there is plently more to be done.

> Allegro should be objective driven. Not feature driven. Before writing any
> code, we need an objective driven design of Allegro, on what it should be
> and what it should do. Then, the implementations on each platform will
> follow the rules we set.

In what way are we "feature driven"?  How do we even decide the
"objectives"?  I think you're trying to make a point with this message,
but I only see mumbo jumbo.

Peter