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

[Bob <ohannessian@xxxxxxxxxx>]

Vincent Penquerc'h wrote:

> Hi,
>
> my humble opinion about these:
>
>  > merge blit and sprite API
> Could you be more specific about what to change ? without losing speed.


AFAIK both draw_sprite and masked_blit use the same backend code. 
masked_blit just does some extra clipping, so unless you blit loads of 4x4 
images, they should be of the same speed.
I was also thinking of merding draw_rle_sprite into masked_blit() for 
example, so that users can switch formats at run time depending on platform, 
etc. It also means that if they want to try out RLE bitmaps in their 
programs, they can just insert a convert_to_rle call somewhere, and have 
everything else work automagically.



>  > is_*_bitmap collapsed to a single function - get_bitmap_type()
> You could have a subbitmap of a video bitmap (I think), so a bitmap
> could have more than one type


Subbitmaps and planar bitmaps are probably the only type of bitmaps that can 
have mixed types. Bit flags anyone?


>  > What to do with floodfill (can't be accelerated via GL or D3D)
> And then ? That is not a reason to remove it I think :)


I guess not. As someone else said, it could be documetned as "horribly slow 
when using OpenGL or D3D drivers" or something like that.


>  > Collapse load_* into one function load_bitmap(), smart enough to read
>  > the file header to determine the format.
> There is no such thing: TGA has no header, PCX has a riducully small one,


so TGA is a raw format? doubtful.
A quick search on wotsit revealed that TGAs have their headers at the *end* 
of the file. An analysis of the beginning of the file for consistency) can 
also help in determining the file type. The same type of consistency check 
can be done on PCX files.

[snip]> 
>  > Speed ups in the asm code
> I remember Shawn saying that the lit and trans routines were faster in
> C than in asm :)


FBlend is here to remedy that :D


>  > Message based (see SDL) (about input)
> In addition to the current API, right ?


Haven't formed an opinion on that yet.


[snip]

>  > Configuration via an OpenGL-like al_set(variable, value) system
> I'm not too hapy about that. That's... well, odd. You lose type safety.
> And the code is a big switch. Not appealing.


But most types in Allegro are ints anyway :)
It'll also allow us to add many more attributes without having to break the 
API every time, or resort to adding new functions (like text_mode).



>  > Some of the little used variables converted to string


> Making them more difficult to use ?


They aren't used anyway :)
At least we can make them more flexible, like cpu_*.


>  > Drop DOS
> No comment :)
> Ah yes, one: why remove it while it's working fine ????
> It could be possible to not implement stuff that it doesn't support
> though, like switch in/out callbacks setters (they nop on DOS).
> This allows other stuff to be added while keeping DOS compatibility.


See other posts - we gain extra functionality without having to drag a 
deadweight around. Also, DOS people can still use Allegro 4. They could also 
migrate to Mingw (or Linux) without too much trouble.


>  > Have a Windows installer built from a script (PIMP?)
> Huh ????? :)


The Winamp people have made a nice scriptable install program maker thingie 
availble for free. You write a script, and feed it to Pimp (like makefiles), 
and Pimp builds an executable installer for Windows out of it. If you drop 
by IRC some day, and log a day's conversation, you'll find at least two or 
three people having difficulty installing the Windows version of Allegro. 
Either due to a problem in the binary package, or a compiler 
misconfiguration, or just Windows being a b!tch.

[snip]

> On a general way, I'd like to point out the obvious: moving stuff into
> addons means that they're far more likely to rot. So moving stuff into
> addons should be weighed carefully.


They could be made "official addons" or something, and directly linked from 
alleg.sf.net. Also, since a lot of those things that should be spinned off 
don't use platform specific code, it would make fixing them trivial really.


[snip]

> Anyway, that's a nice list, thanks for taking the time of doing it :)


Hey, no problem :)




--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/