On Wed, Apr 28, 2010 at 4:51 PM, Pavel Sountsov
<slabode@xxxxxxxxxxxxxxx> wrote:
>
> And there's no need to move anything into the core... just move image
drawing into the primitives addon which is more where it belongs. No
reason to have al_draw_image() "in the core" when not even
al_draw_line() is. I put it in quotation since I think there isn't much
of a problem if those two aren't cleanly separated where it would make
things harder to implement.
I'm not sure what you mean here. What is cleanly separated?
Cleanly separated to me would mean no _al_* symbols are required across the DLL border - something which isn't important at all for our "addons", so we can move code around more or less as we want.
In terms of
sticking the bitmap drawing into the primitives addon... well, it's
possibly in principle, subject to the performance penalties above. Also
there's the issue (not sure how important it is) that you wouldn't be
able to do "anything" with Allegro core without at least one addon, a
concern for some people.
You would be able to do a lot. My idea would be like this:
Core Allegro means I get my display and can use OpenGL (or Direct3D) to draw into it. Allegro still would allow me to create new bitmaps and use those as target bitmaps and also as input textures to OpenGL (Direct3D).
But if I want to use Allegro's platform-independent graphics primitives (which implement things like drawing a bitmap in a very specific way which I might not be able to use in my game for various reasons) only then I would use the primitives addon.
Just thinking *really* outside the box here... it might be neat to have
a pluginable graphics system too... just like we have for bitmap
loading. This might be way out there though :P
Not really sure what you mean with pluginable. Loading the DLLs on demand?