Update (or... Cursors! Foiled again!)

SDL Development
1

Okay, the good:
I fixed some subtle bugs in the RRT2 code. Scott, I think the bugs you
saw Friday are gone.

Now the ugly:
I spent most of the afternoon working on the cursor support in SDL. I
removed color cursor support, since this should really be done in the
application code, and have been working on black-and-white cursors in
full-screen mode.
The code is mostly working.
Here’s the problem:
… if the cursor is erased before screen updates, and drawn afterwards,
you get cursor flicker.
… if the offscreen image has the cursor blitted to it before the screen
update is performed, you get flickerless cursors, but when you try to
move the cursor, the image behind it isn’t updated with the new
offscreen cursor contents.
… if you update the area behind the cursor using the offscreen surface,
when moving the cursor, you can get garbage as the application might be
in the middle of compositing the offscreen surface from different
sources.
… if you save the offscreen image as it is updated, before mixing in
the cursor image, the real screen may be of a different format,
involving costly pixel conversion.

Does anybody have any suggestions?
The fact that the mouse motion update could be happening in a separate
thread just adds more complication to the code. :slight_smile:

I’m probably going to implement the last solution, adding pixel
conversion to the mouse image code, but if anybody has any ideas at all,
I’d love to hear them.–
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

2

I have been away from the list for a while, so I don’t know if this
has already been suggested. As long as you have access to the onscreen
buffer, this is what I would recommend:

 In addition to your cursor bitmap one can keep back buffer bitmap

for the cursor. It would be the same size as the cursor and also in
the screens format. Whenever one renders the cursor, one first copies
the area where the cursor is to be rendered. If the cursor is moved, the
cursor’s backbuffer is blitted to the screen first and then the cursor’s
backbuffer gets a copy of the new location and then the cursor is rendered.
When the screens backbuffer is rendered on screen, one skips the step
of rendering the cursor’s back buffer and simply copies into the cursor’s
back buffer and renders the cursor. You will also need a semaphore/mutex
to keep the screen backbuffer copying and cursor movement from happening
simultaneously.

-Mark

3

Cursors work really well now. :slight_smile:

I need to clean up the Win32 code, but other than that it’s done!

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec