<div dir="ltr"><br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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></div></div></blockquote><div>Yes, I'm aware of the fact I don't get away without some coding ;)</div><div><br></div><div>By the way, am I right in my assumption that if I wanted to support 4bpp (EGA) or even 2bpp (CGA) modes natively, I'd need to change rendering code for each of the engines to support that? I.e. that even if a game is purely EGA, the engine renderer renders into a 8-bit chunky buffer?</div><div><br></div><div>And yes, DG is right, the platform we're talking about is Atari/FreeMiNT, it has 1/2/4/8 bitplane palette based modes and a 16-bit hicolor chunky mode. Sorry about not mentioning that earlier.</div><div><br></div><div>Miro</div></div>
</div></div>