<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 1, 2015 at 1:16 AM, Miro Kropáček <span dir="ltr"><<a href="mailto:miro.kropacek@gmail.com" target="_blank">miro.kropacek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr">> But anyway: that's actually expected. ScummVM asks for a 16bpp output mode with SDL. We always output 16bpp and do any CLUT8 to 16bpp conversion on our own. This is mostly because our overlay (i.e. our GUI) does not render at 8bpp modes but only 16bpp. Thus our whole backend simply uses 16bpp internally.</p>
</span><p dir="ltr">I see. Does that mean that every backend which runs ScummVM must provide a 16bpp output? Has it been always like this?</p></blockquote><div>In practice you need something like a 16bpp output for it to work smoothly, yes.<br><br>Years ago (roughly 9, I think) our GUI could've (theoretically) rendered onto a 8bpp surface by using the game palette. I think the old PalmOS port actually did only output 8bpp. But that is not supported anymore.<br><br>You might be able to adapt the GUI to be able to render onto a RGB332 or similar (i.e. a 8bpp mode). This might require some small adjustments to the GUI code, especially it's renderer: VectorRendererSpec inside graphics/. Currently we only support 16bpp and 32bpp there.<br></div><div>On top of the GUI you would need to either adapt the surface SDL graphics pipeline we have to work with 8bpp too (which is some work and would break all the sophisticated scalers) or write your own graphics output for the backend (probably the better idea).<br><br></div><div>Alternatively, you could just dither the GUI's output (or convert it to RGB332 on the fly) onto a 8bpp paletted output in your custom graphics output. But you would need to write all of that on your own too.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">I could totally live with an overlay which uses incorrect (game palette based) colors so if there's a backend which does exactly that, I'd love to reuse it, too.</p></blockquote><div><br></div><div>Nope, there's no backend doing that. All the backends use (at least) 16bpp.<br><br>I think the NDS port might have some internal switch which makes it output 8bpp when no GUI is shown and 16bpp when the GUI is shown. However, that's all system specific code and still also using 16bpp in certain cases.<br><br></div><div>// Johannes<br></div></div><br></div></div>