[Scummvm-devel] problems with 16 bit cursors

[Andre Heider]

hi list,

i ran into a problem i'd like to solve. this only affects backends
which utilize hardware textures combined with frontends using 16bit
cursors.

when a frontend sets a 16bit cursor, it can use any pixelformat it
wants. all of our frontends are nice though, and use the same format
as the screen.
but that can result in eg. rgb565, which is good for the game screen,
but not so good for the cursor because of missing alpha bits. backends
have a problem then. they have to convert the pixel buffer in
setMouseCursor() to a format with alpha. even when forcing such a
format, frontends don't set alpha bits. so a backend has to set those
bits based on the keycolor - which is double madness. the fact that
most 16bit cursors are animated only makes it worse.

so this problem only exists on non-CLUT8 modes, with a focus on alpha
bits. a solution is only needed when USE_RGB_COLORS is enabled and the
game uses 16bit cursors.

what would be nice is a similar mechanism to what we do with the screen formats:
frontend and backend provide a list of supported modes, and common
code picks one based on those two lists.

i whipped up some patches with a proposal to solve this, see:
https://github.com/dhewg/scummvm/commits/16bit (the last 6 patches)

i hope that throwing a few patches in here is enough to illustrate
what i'm trying to solve, the diffs are not that big.

docs are missing or insufficient, some additional notes:
- there is a default implementation of the new
OSystem::getSupportedCursorFormats(). When not overwriting, it should
behave like its without the patches
- the new getCursorPixelFormat() is only supposed to be called after
setting up a non-CLUT8 mode
- the patches in engines/scumm are by no means final and not supposed
to merged as-is. some parts are using the wrong colors, the changes in
there are to provide an example of how it could look like for a
frontend (and a way for me to test the changes)
- support for more than one alpha bit is possible (groovie providing 4
bits came up on this list recently)
- the android patches show how nice and easy it would be for affected backends
- the wii backend will have less overhead and intermediate buffers
too. it also allows a ARGB3444 cursor without degrading the screen
format from RGB565 to ARGB3444
- at least the opengl will gain too, probably others too

engines using 16bit cursors:
- gob
- groovie
- mohawk
- scumm

this is not a major problem, but it doesn't allow me to implement the
16bit support on the android backend as efficiently as i'd like :)

any comments on this proposal are appreciated ;)
andre