| Re: [AD] Renamed API second draft |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote:
Bob wrote:
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.
[snip]
Now say we want to draw to such a bitmap. First
we must find which place to draw at. This means we must do a linear
search from the beginning. If we are lucky, we find the position where
this pixel is, then we can draw to it, so it has expected average time
proportional to w*h.
Note that I'm making all of this up as I'm going along.
We can use the line[] pointers to point at the start of every line.
Now operations are proportional to w instead of w*h.
If we are unlucky, however, the pixel to which we
draw was transparent, so we must insert the new pixel at the appropriate
position. This involves reallocating memory, then moving all the
following pixels to the right, so it is extremely slow.
Well, if each line[y] points to its own memory buffer, then we only need to
perform this on the line, which will drastically speed up the program.
Secondly, there's nothing stopping us from attaching a bitmap to the
compiled sprite, meaning that we write to this bitmap, then convert it back
to a compiled sprite on-the-fly. Even better, you may only need to re-encode
the line that has changed, and not the whole sprite.
This is kinda what we use in AllegroGL to implement video bitmaps. Sure, it
won't be as fast as using BITMAPs, but considering that you draw masked more
than you write into the bitmap, I'd say it's still a win in terms of speed.
It is the same
situation for RLE sprites: because of the encoding, you have to scan
them linearly, then possibly reallocate and move the rest of the sprite.
Same if you work by line.
This can't be done in any other way, and why would you want to do it
anyway?
You don't have to be so close-minded :)
Compiled sprites and rle sprites are good for exactly one thing:
drawing masked.
And I agree. But having flexibility is also nice.
[snip]
For the same reason, there is no point in rotating rle or compiled
sprites because they are bad datatypes to implement rotation on (because
a rotation routine needs to read pixels from random positions in the
image, which is not supported by the datatypes compiled sprite and rle
sprite). Instead you should choose BITMAPs, which is a datatype that
supports rotation much more naturally.
For RLE sprites, it would be a simple matter of mapping hte source to the
destination instead of the destination to the source. Instead of going
line-by-line in the destination and trying to figure out how it maps on the
source bitmap, we can go line by line in the source bitmap and figure out
how it maps on the destination bitmap.
Doing this with compiled sprites is a little tricky-er, and may involve
having to disassemble the code.
Of course, if the tacked-on BITMAP idea is used (as mentioned above), then
we can simply rotate that bitmap instead of the compiled sprite.
[snip]
(If you don't know java, then you can safely ignore the coming paragraph
:-) The situation is like in java if CompiledSprite is the parent class
of RleSprite (which adds the method draw_translucently()), which is the
parent class of Bitmap (which adds all sorts of methods for e.g. drawing
and rotating). You can't cast an instance of CompiledSprite to an
RleSprite or a Bitmap because that would allow you to e.g. draw a circle
onto a CompiledSprite, but there is no such method in the class
CompiledSprite. However, it is still possible to cast an instance of
class Bitmap to a CompiledSprite, because it only hides operations.
Bad example, because we've done it in AllegroGL already :D
This is why I think an API like the one I suggested in my previous email
is better. Whether or not that should be a part of Allegro is a
completely different issue. I would personally think that it's
unnecessary because it's trivial to implement, but it may be worth
discussing. Another possibility could be to make COMPILED_SPRITEs able
to be represented internally as an RLE or a BITMAP (i.e. add the
functions create_bitmap_compiled_sprite(), create_rle_compiled_sprite(),
then make draw_compiled_sprite() be aware of this).
An interesting idea - but that be acheavied with create_bitmap/clear/blit
already, so I don't think it would merit it's own API entry.
[snip]
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/