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

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


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/



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