> Heres the api. In particular, I wonder if one thing I did was acceptable.
> I allow multiple cusors to be loaded into the visual. The user selects
> which one to show with ggiSetCursor.
I'd like it better if one could display multiple cursors at the same time.
If the Cursors are emulated, this is absolutely necessary to do in the lib
itself, as handling that in the application is a real PITA.
For the same reason (emulated sprites) I'd recommend to have a
"Hideifemulated" Function which gets used for hiding emulated cursors while
drawing.
> Is it bad that I require that the cursor handle only be used in
> conjunction with the visual that created it. If you create a cursor
> handle "c" with visual "v", then you had better call ggiSetCursor(v, c);
For performance reasons, I'd recommend to bind cursors to visuals, as an
optimized representation can then be stored to make blitting quicker.
It makes no sense to allocate extra ressources (like HW-Cursors) on all
visuals because someone created a sprite, and it is expensive to
allocate/deallocate them all the time in case someone uses the same cursor
on multiple visuals.
Moreover the extension mechanism works on a per-visual basis ...
> typedef struct {
> guint16 bpp;
> guint8 width;
> guint8 height;
Huh ? 16 Bits for the depth and only 8 for sizes ? Don't limit yourself so
hard. O.K. - cursors will rarely be >256 in size, but why limit oneself.
It's not that we are on 8 bit µPs ... No need to waste space, but no need
to be too niggardly with it ...
> ggi_color* palette;
I wouldn't store a palette here usually. Basically I'd recommend to have the
sprite type to be opaque like all the more complex GGI types and have a
void* in there somewhere that points to a representation that is understood
by the actual driver.
The BSE headers looked like this:
enum bsetype {
BSE_BOB, /* Blitter object. Destructs display memory beneath.
*/
BSE_SPRITE, /* Real sprite. Does not affect display memory. */
BSE_EMUSPRITE, /* Emulated sprite. Saves display memory underneath.
*/
};
int ggiBseInit(void);
int ggiBseExit(void);
int ggiBseAttach(ggi_visual_t vis);
int ggiBseDetach(ggi_visual_t vis);
/* Allocating/Destroying a BSE.
*/
ggibse_t ggiBseAllocate (ggi_visual_t vis, int width, int height, enum bsetype
type);
int ggiBseFree (ggibse_t bob);
/* Populate the sprite
*/
int ggiBseSetImage (ggibse_t bob,ggi_visual_t vis,int x,int y,
unsigned char *alpha);
/* Move the sprite around.
*/
int ggiBseMove (ggibse_t bob,int x,int y);
/* Hiding and showing
*/
int ggiBseHide (ggibse_t bob);
int ggiBseShow (ggibse_t bob);
/* These are for EMU_SPRITEs. You can use these for hiding them for drawing.
*/
int ggiBseSoftHide (ggibse_t bob);
int ggiBseSoftShow (ggibse_t bob);
###### These are just convenience - not really API relevant ... ###########
/* Some helpers for generating alpha arrays on the fly. They malloc the
* resulting array, so be sure to free() it again. The bob argument is used
* to determine the size.
*/
unsigned char *ggiBseMakeAlphaFromPixelkey(ggibse_t bob,
ggi_visual_t vis,int x,int y,ggi_pixel pix) ;
unsigned char *ggiBseMakeAlphaFromColorkey(ggibse_t bob,
ggi_visual_t vis,int x,int y,ggi_color *col) ;
/* Some helpers for _CHANGING_ alpha arrays on the fly. As above, but they
* operate on an existing alpha array. No malloc is performed.
*/
/* Arbitrary transforms :
*/
unsigned char *ggiBseChangeAlphaByFunction(ggibse_t bob,
unsigned char *alpha,
unsigned char (*func)(unsigned char in,void *parms),void *parms);
/* "harden" an alpha-channel. Especially useful for speeding things up.
* A yes/no type alphachannel can be handled much more efficiently.
*/
unsigned char *ggiBseChangeAlphaTreshold(ggibse_t bob,
unsigned char *alpha, unsigned char treshold);
/* Useful if you need the "negative" of an alpha channel.
*/
unsigned char *ggiBseChangeAlphaInvert(ggibse_t bob,
unsigned char *alpha);
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
