From: Brian S. Julin <bri@tull.umassp.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 5 Jun 1999 01:04:09 -0400 (EDT)

Re: GGI Cursor API proposal.

On Fri, 4 Jun 1999, Samuel A. Falvo II wrote:

> The problems addressed with a "cursor" (more accurately known as a pointer;
> 'cursor' is really only used in the Windows camp to the best of my
> knowledge) are precisely the same problems addressed by sprites.  Sprite
> engines, usually to accomodate games, have the single additional facility
> for detecting "collisions."  Otherwise, they've identical feature-sets.

If we're talking software emulation, it is a bit complicated, as the
emulated sprite/cursor must be "undone" before primitives are drawn
and redrawn afterwards.  Perhaps the easiest way to do this is assume all 
sprite/cursors are like this, and advise app developers to call a "hide/unhide"
function which for hardware sprites/cursors will do nothing.

A generic feature/sprite API proposal of mine is out to Marcus and Andy for
comments, when we get details banged out to where it looks good to them
for the GGI core and/or an extension I'm willing to start coding on it again
(my first attempt "ggiAuxBuf" was a bit of a dead end so I abandoned that 
angle).

--
Brian