Re: [AD] Renamed API second draft

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

I'll try to summarize. There are several suggestions:
 (1a) Make rle and compiled sprites (let us call them cmp/rle) be
special types of BITMAPs, remove RLE_SPRITE and COMPILED_SPRITE from
API.
 (1b) Assuming (1a) gets implemented, implement all drawing operations
on cmp/rle.
 (2a) Do neither (1a) nor (1b), but create a new type which can only be
drawn masked, which can be represented either as cmp/rle or as a regular
BITMAP.
 (2b) Like (2a) but put it in an add-on library instead of in Allegro.

I will mostly discuss (1a) and (1b).

Advantages of (1a):
 - More transparent API.
 - With a good implementation it can support new (not yet known) bitmap
types.

Advantages of (1b):
 - Allegro can do more things.

Disadvantages of (1a):
 - You can do lots of operations on BITMAPs that you can't do on
compiled or rle sprites, so it is useful for the API to not be
transparent.

Disadvantages of (1b):
 - Can't be implemented efficiently.
 - More bloated library.
 - Hides slow operations under innocent-looking putpixel() calls.

First assume we do (1a) and not (1b). Not all data types in the world
are the same, so they deserve different APIs. In this case it means that
we have to find out whether a cmp/rle is semantically similar or
different to a BITMAP. But you can't draw to cmp/rle's, they are
read-only. They are also draw-masked-only, i.e., you can only read them
in special ways. For instance, you can't even do such a fundamental
thing as getpixel() on cmp/rle. So I think (2a) and (2b) must in any
case be strictly better than (1a).

Now assume we instead do (1b). This means implementing for instance
getpixel(), putpixel(), and rotate_sprite() even on BITMAPs which are
represented as cmp/rle. So the argument against (1a) is not valid here
because all datatypes are the same. However, I think it is bad for other
reasons:

Most operations (except draw_sprite()) can't be implemented efficiently
on cmp/rle. We are not talking about slow as in e.g. "reading from video
memory", but about slow as in "depending on the width of the bitmap". So
getpixel()/putpixel() can't even be done in constant time on cmp/rle.
This is because of fundamental properties of the representation that
can't be overcome. Therefore, there are two kinds of users who will draw
onto compiled or rle sprites: Users for which it actually makes sense
and clueless users who think it makes sense but in fact it just slows
their program down. I think it is very rare to have a situation where it
is actually useful to draw onto cmp/rle, given that it is so slow.
Meanwhile, in those very rare cases, it is trivial to blit the cmp/rle
to a temporary bitmap, do your operations on it and convert back to
cmp/rle. Doing this conversion also makes it visible to the person
reading the code how slow the operation actually is, rather than hiding
it under an innocent-looking putpixel() call. Not supporting drawing to
cmp/rle does not limit the things you can do with Allegro, it merely
forces you to write out explicitly how slow the operation is. When you
compare the very small advantage (which might not even be an advantage)
of not having to do the conversion back and forth to BITMAP explicitly
in very rare cases, to the huge loss of performance for the second kind
of users and to the code bloat, I think it looks like there is a risk
that it will hurt more than help.

-- 
Sven Sandberg   svsa1977@xxxxxxxxxx   home.student.uu.se/svsa1977