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

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


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

Sven Sandberg writes:
>  - `bmp_read8()' & co currently use longs instead of pointers. I think
> this is an old djgpp-ism, because `_farnspokew()' take longs as
> arguments. If someone knows a good reason why it must be this way,
> please say it. Otherwise, can we please replace `unsigned long' by
> `unsigned char *', `unsigned short *', and `unsigned long *'?

The thinking behind using longs is that this makes the pointers
opaque, ie. can't be dereferenced directly by the user, so
people are forced to always access them with the bmp_read*()
macros. If they were pointers, it would be easy to accidentally
write *ptr, which would work on some platforms but fail on
others.

Ideally these should be a "vidmemptr" type, but given the lack
of such a thing in C (cue suggestions to do it in C++ :-) an
integer type does a reasonable job of supporting copy, comparison,
addition, etc, but not dereferencing.

> >  - save_datafile() and save_datafile_object() (Nathan Smith)
>
> I think these already exist in libaldat.a.

They do, but not in a very useful form as they call grabber plugin
functions to do the work of actually saving out the various chunk
types. I think it would be a shame to lose that plugin architecture
just so those functions could be included in core Allegro, but if
anyone wanted this, maybe they could do some work to make the
datafile lib a bit more generic and easily linkable into other
programs? (although even at present, it is pretty easy to use
as long as you don't mind reading headers/source to figure out the
API).

> > Stuff to remove (can be placed in add-ons)
> [snip]
> >  - Software 3D code
> >  - 3D Math
>
> I think these are too widely used to be removed.

Probably true. It is a shame because vector/matrix math is one
area where C++ classes can make life so much nicer than a C API,
so I'd hate to be stuck ever actually writing real code with
something like the Allegro routines, but they certainly are used
a lot, and Allegro is probably the wrong place to put a nice C++
math package in any case (plus, such things don't need to be that
tightly integrated so there are unlikely to be problems using
whatever C++ math package alongside other graphics libs).


        Shawn.



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