On Sat, 10 Feb 2001, Brian S. Julin wrote:
>
>
> > /* checks, if an object of the given type and properties is available.
> > * If not, then it fails else it allocates it with the given size.
> > */
> > ggiOvl_t ggiOvlAllocate(ggi_visual_t vis, enum OverlayFeaturetype type,
> > void *properties, int width, int height);
>
> Question -- why not make the feature type part of the properties?
hmmm... what do you propose?
> > /* Set the given image (vis) to the ovl-area with grabbing the image
> > * from a visual at pos (x,y)
> > */
> > int ggiOvlSetImage(ggiOvl_t ovl, ggi_visual_t vis,
> > int x, int y, unsigned char *alpha);
>
> I think you are saying that this is a crossblit from a visual into
> an overlay, right? The comment isn't very clear.
Yep. For example, that allows setting a bitmap to a
sprite, pointer-cursor etc...
> /* To control the effects of the overlay, like transparency,
> * setting a hardware source for the image etc.
> */
> int ggiOvlSetOption(ggiOvl_t ovl,enum OverlayOptiontype op,void *arg);
>
>
> > /* moves the ovl-area to (x,y), where (x,y) is the top-left corner
> > * of the ovl-area.
>
> Add: If the overlay must be positioned on a "snap to" grid, then the
> actual coordinates used will be rounded down to nearest coordinates that
> fit on the grid.
Done.
> > */
> > int ggiOvlMove(ggiOvl_t ovl, int x, int y);
>
> > /* shows/hides the ovl-area
> > */
> > int ggiOvlShow(ggiOvl_t ovl);
> > int ggiOvlHide(ggiOvl_t ovl);
> > int ggiOvlIsHidden(ggiOvl_t ovl);
>
> I think we were also going to have a "hide if emulated"/"show if emulated"
> functions and an IsEmulated function, but those can be macros.
> ggiOvlIsHidden can also be a macro probably.
Not in LibOVL. The emulation-part is left to libblit.
> > struct Common {
> > /* pointer to a directbuffer.
> > * Note, that this may be shared with other sprites.
> > * If direct access to the sprite has to be emulated,
> > * these functions do _not_ have to use the read and
> ^^^^^^^^^^^^^^^^^^^ should not use
Fixed.
> > * write members 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. If you are writing to VRAM directly, the function
> > * will do nothing, but returning something like
> > * -E(INFO_DOESNOTHING).
> > */
> > int (*set)(int x, int y, const void *data, int size);
> > int (*get)(int x, int y, void *data, int size);
>
> Hmm... why not just this:
> int (*set)(ggiOvl_t ovl);
> int (*get)(ggiOvl_t ovl);
>
> #define ggiOvlSetData(o) o->Common.set(o);
> #define ggiOvlGetData(o) o->Common.get(o);
Done.
> (... and what are the x and y supposed to do?)
>
> I'm attaching a suggested extension with the above changes
> which I made with ehelper. I put an X target into it, because
> I think that might make a good first target, by treating the
> X cursor as a "hardware pointer" sprite. IIRC X takes care
> of the software emulation if the cursor is not really a
> hardware cursor.
Err... You _did_ the work I've done at last wednesday...
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
