| Re: [AD] Renamed API second draft |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote:
Bob wrote:
It's a simple matter of making RLE/compiled sprites be BITMAPs instead
of RLE_SPRITE and COMPILED_SPRITE. Of course, not every operation on
those bitmaps will be supported, but it would allow us to add support
for them later on.
But there is no such thing as a compiled or rle sprite which you can
write to or rotate! A compiled sprite is naturally only good for being
drawn as it is and you cannot rotate it. Similarly, an RLE sprite can't
be rotated because you can't read from a random position in it (in
constant time).
No, there's no such thing as a compiled or rle sprite which you can
write to or rotate *now* - this doesn't exclude the fact that these
operations can be done. This doesn't mean that we should rush out and code
every operation that takes BITMAPs to also support the other sprite types.
It just means that, at some later time, we will be able to do so. We're
trying to break the API only once here.
Moreover, rle sprites and compiled sprites are mutually fundamentally
different: you can draw an rle sprite with clipping and translucency and
perhaps stretch it, but you can't do any of these with a compiled
sprite. A compiled sprite only supports one drawing operation, and it is
the one that it was compiled to do: draw_sprite().
Compiled sprites can be changed to allow clipping, but that will make them
use more memory.
So I think rle sprites, compiled sprites, and bitmaps are (and must be)
too different to be useful to have in the same struct. If you want a
transparent API, why not just do the trivial:
Yep, so why can't this be done in Allegro? Allegro already has the
facilities to do that (vtables), so we'd just need extra flags for RLE and
compiled sprites. That's all really.
[snip]
So does the mini-api given above, which can easily be extended to an
add-on.
blit() can also be placed in a add-on if you really want to. After all, you
only need bmp_read/write_line and bmp_read/write* no? :P
The point is that with a merged API, we reduce the number of functions (good
for DLL), we allow users to easily switch in between bitmap types (for
free), we allow support of various different types of bitmaps which may not
even be invented yet, we keep a consistent API, and it requires minimal
effort on our part. There'll be more to add in the documentation than in the
code.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/