Re: [AD] Renamed API second draft

[Michael Bukin <M.A.Bukin@xxxxxxxxxx>]

Michael Bukin <M.A.Bukin@xxxxxxxxxx> thinks harder and adds more
random thoughts on the sprite vs. bitmap idea:

If bitmaps and sprites will be merged, then the only vtable entries
for sprites will be destroy, blit_to_system, blit_to_memory,
blit_to_video, masked_blit and maybe draw_ functions too, if drawing
modes will be supported for sprites (*).  Destination bitmap does not
know how to handle all different types of sprites, so drawing
operations should be in sprite vtable.

What should be done with other vtable entries for sprites?  Drawing
operations may do nothing, but what to do with bmp_read_line?  Should
it return pointer to some allocated memory?  For example, convert line
data from sprite format to bitmap format and return pointer to it,
then in bmp_unwrite_line convert from bitmap to sprite, making it
possible to slowly draw to sprite.  Or should it abort the program?

Sprites don't have information about transparent pixels, so blit
operation is not very sensible for sprites.  It can be emulated by
calling rectfill and then drawing sprite.

Separating sprite API from bitmap API will make both of them cleaner,
but it will be necessary to make some changes in program to replace
bitmaps with sprites.

(*) If sprites will support drawing modes, then drawing modes can not
be implemented by substituting vtable in destination bitmap, or
sprites will have to draw themselves by calling functions in bitmap
vtable.

-- 
Michael Bukin