[Scummvm-devel] Fwd: PS2 backend - up & running (almost)

[Johannes Schickel]

On Thursday 30 October 2008 17:52:31 Max Horn wrote:
> > It wouldn't quite work with a new function to the OSystem API, because
> > the bit format must be known at compile time. Maybe it could be set
> > with a define flag. This should be discussed.
>
> Actually, on the long run, it would be desirable to not have to
> specify a fixed bitformat during compile time. Already now, on OS X,
> we actually need to support both 555 and 565 mode in a single binary
> (currently, colors are wrong in fullscreen mode on OSX due to this;
> start ScummVM in fullscreen mode, use the modern theme, open a dialog:
> the background is 'dimmed' incorrectly).

For now I added a simply define 'VECTOR_RENDERER_FORMAT' which is defined on 
compile time when 'DISABLE_FANCY_THEMES' is specified, which should be for 
most (all?) devices, where code size matters.

> While we probably can support multiple color modes right now by
> compiling in multiple specializations of the templates, and switching
> between them via some runtime checks, this bloats the binary. Not a
> major deal for desktop ports, but if we have any small device that
> requires this, we'd have a problem... also, does your code work
> correctly in 4444 mode, in 888 or 8888 mode, and in "wrong endian
> 555/565" mode (i.e. 555/565 mode where the bytes are swapped --
> leading to the bits of one color not being "adjacent") ?

Since I extended the code to create renderers for '1555', '4444' and '555' 
also, it should support those modes without any problem. Apart byte swapped 
modes don't work currently, as there is *no* way of detecting them for the 
user, if that would be possible it could be easily added via some new 
ColorMask specialization.

> We really are facing a trade off here: Maximal speed and code size vs.
> maximal genericity. To me, it is not yet clear which one should be the
> winner. Like, is the GUI code fast enough? If yes, would it still be
> fast enough when using PixelFormats like SDL does, instead of
> specializing during compile time on a specific bitformat? If no, what
> about it is too slow? How can we speed it up? Does code specialization
> help at all? Bigger code size also means worse cache usage, which can
> also degrade performance. etc., etc., a complex subject :)

Well one need to run in depth tests for that one ;-).

// Johannes