<div dir="ltr">Thanks Johannes, this really got me started.<div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I mentioned in my previous mail, you could try to use a 8bpp RGB mode like RGB332 or similar and then simply setup the palette to match RGB332. Then adapting the GUI might be simply a matter of adding a "uint8" case to createRenderer in graphics/VectorRendererSpec.<u></u>cpp 341-367 (and assuring that the 1Bpp mode the overlay is set to is not a indexed one). This is probably the least amount of work.<br></blockquote><div>It took me some time to understand all that global variables (_videoMode seems to contain a lot of redundant information which could be obtained from the _*screen structures) but actually, the least amount of work is this: define _hwscreen as 8-bit and instead of using scalers just SDL_BlitSurface() dirty rectangles directly into _hwscreen. SDL_BlitSurface takes care about format conversion (it doesn't matter whether _overlayScreen -> _hwScreen is inefficient, gameplay is what counts). Of course, palette is sh*t for the overlay but at least it works for now.</div><div><br></div><div>If I wanted to support scalers (what I'd like to because our platform also offers a window manager in high resolutions), I'd need to rewrite at least the Normal1x and Normal2x to be 8bpp aware and perhaps code it in assembly.</div><div><br></div><div>Once again thank  you for your hints, now I can play with ScummVM a little :)</div><div><br></div><div>Miro</div></div>
</div></div></div>