Re: [AD] Renamed API second draft

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Bob <ohannessian@xxxxxxxxxx> writes:

> 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. It would also allow us to add new bitmap types, since there's only 
> one set of functions to work with.

IMHO, it would be better to make 'foreign' bitmap type (and call it
AL_SPRITE, for example), because sprites and bitmaps are very
different things.  All functions for drawing into native bitmap would
go to the vtable of AL_SPRITE, as well as function for converting from
AL_BITMAP to AL_SPRITE.  Though, it would be much easier to make
functions for making new AL_SPRITE from AL_BITMAP,
e.g. al_create_rle_sprite, al_create_compiled_sprite, etc, and not
placing these functions to vtable.

I don't know what to do with drawing modes.  If drawing will be done
by sprite vtable functions, without calling to bitmap vtable
functions, then this idea does not fit well with my previous idea
about drawing modes.

struct AL_SPRITE_VTABLE
{
  ...
  void (*draw_to_memory_bitmap) (AL_BITMAP *bmp, int x, int y);
  void (*draw_to_video_bitmap) (AL_BITMAP *bmp, int x, int y);
  ...
};

void al_draw_sprite (AL_BITMAP *bmp, AL_SPRITE *spr, int x, int y);

AL_SPRITE *al_create_rle_sprite (AL_BITMAP *bmp, int x, int y, int w, int h);
void al_destroy_sprite (AL_SPRITE *spr);

Load/save can go to the sprite vtable too, or maybe place some ID into
sprite and make load/save functions find appropriate functions for
loading/saving by sprite ID (i.e. its type).

-- 
Michael Bukin



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/