> > Getting this into an API that anyone is going to want to use is a worthy
> > program design challenge :-)
> seriously, this is precisely why I'm against exposing these 'features' to
> the API user. The API should be abstract, always having the potential use
> cases in mind. It's then the task of the programmer to map that to whatever
> is available in h/w, i.e. there could be different polymorphic implementations
> available which care about that.
Right. This is why BSE takes a color array and a transparency array.
This is generic and can be analyzed by the "compiler" stage that stores the
sprite data in a format that can be blitted quickly if it is an emulated
sprite. If it turns out that the alpha channel only contains 0 and 255 it
will optimize for that. Same for hardware sprites. If the sprite has few
enough colors and they are within the other hardware restraints (note that
many hardware sprites have their own color registers, so no need to share a
palette with the main visual, but there are others as well), it will get
used. If not you will get an error returned and you can either retry with a
simpler cursor or allocate an emulated cursor, which can do anything the
target supports.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
