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

[Stepan Roh <stepan@xxxxxxxxxx>]

On Wed, 28 Nov 2001, Bob wrote:

> Stepan Roh wrote:
>
> >
> > On Tue, 27 Nov 2001, Bob wrote:
> >
> >
> >>http://pages.infinit.net/voidstar/newalleg.txt
> >>
> >
> > Splitting packfiles handling to compression/encryption layers is good, but
> > removing default implementation is bad, bad, bad :-) Why?
>
>
> I just thought about lightening the lib. There's no reason really, and I'm
> not advocating it. I just thought I'd bring it up incase someone else would
> argument for it :)

Sorry, noone here :-)

> > Adding networking is not good thing, I think. Too much new code without
> > any connection to current Allegro.
>
>
> The current Allegro has nearly no connection to Allegro 3.0 appart from most
> of the external API. Why is networking any different?

Input, graphics and sound are core of Allegro. Unicode functions are there
as a support for text output. GUI is there for utilities and grabber.
Datafiles are there for simplify data loading. Unaccelerated 3D is there
for unknown reason :-) Network should be there for what? You want to drop
small blenders and want to include huge networking layer.

> > Generated API docs is very good idea, but forget Javadoc. It's too
> > Java-centric and too slow.
>
>
> Doxygen? They use the same syntax (AFAIK), so we could just document the
> code like this:
>
> /** Draws a bitmap. (insert blit() docs)
>   *
>   *  \param source The source bitmap
>   *  \param dest   The destination bitmap
>   *    (and so on)
>   *
>   *  \sa draw_sprite masked_blit stretch_blit
>   */
> void blit(...) {
> }

If this is Doxygen's syntax (I don't know it), then it's not Javadoc :-)
But in-source documentation is good thing.

Have a nice day.

Stepan Roh