<div dir="ltr">Hi Eugene,<div><br></div><div>thank you for your input.</div><div><br></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"><div dir="auto"><div><div>Well, what you do in your backend is irrelevant to the engine. However we always assumed that backend supports at least 8bpp. For 4bpp games we do usually set pallette for 16 colours but still feed backend with 8bpp data. Theoretically you can detect that in the backend and use only low bits of the screen data. </div></div></div></blockquote><div>Yeah, this is what I've seen so far -- it must be a 1/2/4 bytes boundary. I wanted to do it in a native way, i.e. use a 4 or 2 bpp buffer + asm optimize such pixel writes to decrease amount of data to be copied from the engine -> backend -> sdl. Atari has a very slow data bus when writing to video ram.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div>As of the GUI, we broke 8bpp awhile ago but changes for bringing it back should be not that big. There is FANCY_THEMES define on the code for letting only classic 4 color themes used. Though I did not try that for ages. </div><div><br></div><div>Thus I think it is still possible to have 8bpp-only backend implemented without tremendous effort. </div></div></div></blockquote><div>Oh, that's definitely good news. In the meantime I've gotten hold of an Amiga port source code, the author had used his own 8bpp backend so it must be possible. He had decided to use an older version to port (1.4.1), however.</div></div><div><br></div><div>Miro</div>
</div></div>