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

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

Bob wrote:
> I've composed a small list of things that we can discuss when moving
> the new API for Allegro 5 or 6.

A good idea!

Here are my opinions about what I know something about. You can insert
`IMHO' before each sentence if you like, so I don't need to instantiate
humbleness everywhere :-).

I may seem a bit conservative, but I think it is important to keep
backwards compatibility on all places that aren't totally broken. It
will be hard enough anyway to port old programs to Allegro 5.

First, I'd like to add a point that has irritated me for a long time
now:

 - `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 *'? It scares
me a bit because there's no reason to think that
sizeof(long)==sizeof(void*) on all platforms, plus there's apparently no
reason to store a pointer in a long.

We also discussed replacing `text_mode()' by an extra parameter to
`textout()'; this might be worth adding to the list.

> Graphics:
>  - 8 bit palette components

Absolutely!

>  - Possible merge of AllegroGL (as an OpenGL driver only, to keep it 

Why can't it be in AllegroGL?

>  - merge blit and sprite API

What do you mean? This sounds like "remove `draw_sprite()' and add an
extra parameter to `blit()' indicating whether transparent pixels should
be masked out", but we earlier discussed "make the order of source/dest
parameters to `draw_sprite()' be the same as the order of source/dest
parameters to `blit()'".

>  - is_*_bitmap collapsed to a single function - get_bitmap_type()

Why? I think the bit field that such a function would have to return
would be a bit complicated, and some of those functions are very
different from each other.

>  - What to do with floodfill (can't be accelerated via GL or D3D)

Why should we want to do anything with it? Just let it be the way it is.

>  - Dump draw_character

Why? It needs to be in the library because we need to draw text, so it
doesn't hurt to have it in the API, right?

>  - Unified rotate_flip_pivot_stretch routine

There is already one: `_pivot_scaled_sprite_flip()' in aintern.h

>  - hsv_to_rgb and rgb_to_hsv in a separate lib
>  - Remove not-so-useful blenders (dissolve, dodge, hue, invert,
> luminance, multiply, saturation, screen)

Why? They are all small and can't hurt much?

>  - Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
> int32_t instead?

Why? I think this would break too much code, both in Allegro and in
user's code. Btw, 32bpp == long, not int.

>  - true color fade in/out (Nathan)

Yes, this is probably such a frequent faq that it is worth implementing.

> Text Drawing:
>  - textout should not use -1 for colored fonts.

Why? What else?

> Packfiles:
>  - Allow registering of new compression and encryption libs.

Good idea, but nothing we need to wait for if nobody writes it.

>  - save_datafile() and save_datafile_object() (Nathan Smith)

I think these already exist in libaldat.a.

> Network:
>  - Can we get one? Please? :) 

Why can't it stay in libnet?

> Core:
>  - prefixing of the API

Absolutely!

>  - Move as much as possible to VTables

Any specific ideas on which functions this should include?

>  - Drop DOS.

No, please! There are so many people who use djgpp, and there are no
problems with that port. There was a reason to drop rsx because it
didn't work, nobody used it, and the platform is dead, but nothing of
this applies to djgpp.

> Documentation:
>  - Generated from source via Doxygen or Javadoc

Why? _tx files work perfectly, can generate more file formats than
anything else, and are self-contained, i.e. no need for user to download
another package with the help compiler. And some add-ons actually use
makedoc.

> 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.

>  - Fixed point math

Many people, including Allegro itself, uses it everywhere, so I strongly
disagree.

>  - Compiled sprites and RLE

Maybe compiled sprites, but please not RLE, they are useful to save
memory.

You didn't mention the gui, which I think is good. IMHO it is
fundamentally broken by design (because it wasn't meant for anything
else than internal purposes), and should remain so because a proper gui
can grow unboundedly and is better done as an add-on. And also because
redesigning it would break tons of user code.

Sven