Hi,
trying the same on a SPARC (not 64) QEMU shows something somewhat
interesting. First of all QEMU only supports 8bpp colours. Secondly,
when starting OpenTTD via either Allegro or SDL in 8bpp mode makes the
colours of the rest of the interface go totally haywire whereas the
colours in-game are correct. Thirdly, using 32bpp the colours are
definitely wrong, however changing the order from ARGB to ABGR makes the
colours look better but they are still wrong. I have no idea what is
going on there though. In any case, x86 uses BGRA (i.e. ARGB reversed),
PPC uses ARGB and now it seems SPARC uses ABGR. So it's not an Endian
problem, but some strange SPARC implementation detail issue.
The only caveat of changing ARGB -> ABGR is that the screenshots will
then be incorrectly coloured, so somewhere during writing data to the
screen the bits need to be reordered. The main question is, however, how
can we detect that we need to reorder bits? As when we don't need it, we
shouldn't waste CPU on doing basically a no-op, and we would like to
know whether there are more peculiar targets.
In any case, I have no idea whether this also happens on SPARC64. For
example, I don't even know whether you used 32bpp or 8bpp OpenTTD. If it
is 8bpp OpenTTD, which I assume to be the case as that's default and you
didn't mention switching to the 32bpp blitter, then this issue isn't
your issue and I'd rather argue that it is a bug in SDL given we set the
right values in the SDL_Color structure.
Regards,
Rubidium
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
