If one wants to use a color cursor, is turning off the SDL cursor and
using Mouse Motion events to blit an image to the location of the mouse
the only way to accomplish this? The only reason I ask is that most
modern hardware supports hw-cursors, right? And I would guess that,
when available, SDL uses hw cursors for SDL_Cursor, right? Do most hw
cursors not support color?
I believe this is correct. I’m pretty positive X11 doesn’t support color
cursors, and I’m kinda sure that Mac doesn’t. Or, does it?
With SDL, we’ve got to be careful not to introduce something that’s too
hardware/OS specific if it can’t be done on all of the other supported OSes.
However, Sam, have you consider supporting color cursor on OS(es) that DO
support it (say, Win32) and for those that don’t support some kind of
color-reduction/dithering to convert the color image to B/W for the OSes that
don’t support color cursors?
Or how about something like:
SDL_Cursor * SDL_CreateColorCursor(Uint32 *color_data, Uint8 *color_mask,
Uint8 *bw_data, Uint8 *bw_mask,
int w, int h, int hot_x, int hot_y);
If the OS supports color, it will, of course, use the color_data and
color_mask information to create a nice, pretty color cursor.
If the OS does NOT support color, it will use the bw_data and bw_mask
information to create a black/white cursor.
However, if the OS doesn’t support color, and bw_data and/or bw_data are
NULL, then the user is asking the function to create a black/white cursor
based on the color_data and color_mask information.
Think it’s doable? (I’d try, but I don’t have Windows or know anything
about using color cursors under it.)
A slightly related question. Why is there no SDL_CreateCursorFromSurface()
When I converted Gem Drop X from Xlib to SDL, I had to replace one simple
Xlib function call that accepted .xbm data with a for-loop that did a bunch
of bit shifting. (I believe it was an LSbit vs MSbit thing…)
Wah! I had to use << and >>! Wah!!