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

[Bob <ohannessian@xxxxxxxxxx>]

Angelo Mottola wrote:

> Ok, I've been out to my university all day and when I've returned, I
> found 33 AD messages most of which about this subject, so even if a lot
> has already been said, let me tell you my thoughts.


I have a feeling there will be a lot more comming :)


> > - Switch to completely disable the Allegro mixer, and send
> audiobuffers to the sound card directly. (TRAC)
>
> Hum, I'm not a sound programming expert, but removing our software mixer
> wouldn't mean to loose a lot of functionalities?


I'm not talking about removing them, I'm talking about providing an option 
for the user to disable them. They use computational resources, and aren't 
even good at what they do. If the user can do it better, then why not let him?


[snip]

> > - Possible merge of AllegroGL (as an OpenGL driver only, to keep it
> light)
>
> I'm all for it! By "as an OpenGL driver only" do you mean to implement
> only the current AGL "direct" mode? If so I agree again as I don't see
> any reasons on including the others.


Yes. But we'll be cutting out some of the functions, like AGLF and possibly 
the texture uploading code.


> > - merge blit and sprite API
>
> I agree, but how to recognize when to draw a transparent bitmap (sprite)
> or a solid one? What about using al_set(AL_BLIT, AL_BLIT_TRANS) or
> al_set(AL_BLIT, AL_BLIT_SOLID)?


Or make a trans_blit() function?


> > - window resizing support
>
> Is this really needed? I think it'd require so much overhead it isn't
> worth it at all. Who really needs window resizing in games? Ok, Allegro
> is also for general multimedia apps, but again I'm not convinced on
> adding support for this...


Yes, I was thinking more for application. If it's too hard to implement in 
DDraw, then perhaps it can put in the backburner for a while. Having that 
option platforms/drivers which support it (like OpenGL) would be really nice 
though.


[snip]

> > - What to do with floodfill (can't be accelerated via GL or D3D)
>
> Some programs may need it, so I don't think removing it is a good idea.
> GL and D3D could just have a slow unrecommended implementation (stated
> in the docs) or not have it at all (but this would mean making floodfill
> part of the gfx vtable, which isn't a bad idea at all)


Agreed.


> > - Drop DOS.
>
> Psss! A hint: don't propose this once again, or someday you'll find
> hordes of angry people knocking at your door!


Too late :)
They can upgrade to a better OS (like Linux!) :)



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