Karl Robillard wrote:

Fullscreen cursor (ack)
This fullscreen cursor thing is a pain. Essentially what’s happening is
the RRT2 code is drawing into the same surface that the mouse cursor is
drawn into, but without either function knowing where the other is
drawing. Yuck. To make matters worse, in fullscreen mode the mouse is
only updated once per game loop, which isn’t often enough for fluid
mouse motion. We got around this in CivCTP by running the mouse in a
separate thread and by funnelling all graphics updates through a
function which mixed them with the mouse cursor before drawing the
update. sigh XFree86 doesn’t even provide hardware overlay surfaces.
… Ideas anyone?

In MythII the cursor exists entirely outside of the game and the frame buffer.
The pointer update done every frame is drawn during the frame buffer update
(pointer drawn to buffer, buffer copied to video memory, pointer erased
from buffer). The pointer updates caused by the input thread are drawn directly
to video memory. The MythII code doesn’t deal with blitting the pointer so I
guess we don’t have the problem that you are having with RRT2.

Yeah, I’m actually going to remove color cursor support from SDL and
implement the cursor as a bitmap and mask directly to video memory. The
caveat will be that if you write directly to video memory using
SDL_HWSURFACE, you need to disable the mouse cursor. That will solve
all of my nagging problems with the SDL mouse cursor implementation.
The place for sprite cursors is really in application code. The
underlying video implementation has no idea how best to mix the mouse
updates with the user graphics accesses.> On Thu, 08 Jul 1999, you wrote:

-Sam Lantinga, Lead Programmer, Loki Entertainment Software