On Fri, 9 Feb 2001, Christoph Egger wrote:
> struct Sprite {
> /* pointer to a directbuffer.
> * Note, that this may be shared with other sprites.
> * So, you do NOT have to use the read and write members
^^^^^^^^^ "should not use"
> * of this db-struct.
> */
> ggi_directbuffer *db;
> /* Pointer to set/get functions. These functions will
> * transfer the contents of a system RAM buffer to/from the
> * sprite.
Hmm.. I would word it "If direct access to the sprite has to be
emulated, these functions"... That makes it clear that the RAM
buffer has to be gotten from LibOVL.
> * If you are writing to VRAM directly, the function
> * will do nothing, unsuccessfully, returning something like
In the docs, the word "unsuccessfully" might make people think an
error message might be generated, so I'd just take it out.
> Is this ok?
Looks good.
> The sprite-structure seems to be rather generic.
> It seems to me that the Vidovl and Ovlwin-structures (see
> above) don't need any special things. Am I right?
I hope so... doubtless someone will find something we missed some
day, and the struct (and so the API) will have to have members
added, but as API changes go, additional members in a struct is
generally not a severe change.
> If yes, then the union-typefield is unnecessary and can be replaced
> by something like this:
>
> struct Overlay {
> enum Overlaytype type;
> struct Image image;
> };
Yeah, not having a union will make the API less intimidating. In fact,
adding the "type" member to the sprite structure itself and doing this:
typedef struct bse_sprite Overlay;
(but I wouldn't name the member "type" for namespace reasons.)
In fact, we might be able to get rid of the whole -E(GGI_DOESNOTHING)
business if we leave a flag in the "type" that says that the sprite is
being cached.
--
Brian
