Bug#641146: openttd: Swapped colors on sparc64
Hi Joël, Could you test the OpenTTD version in experimental and report if it fixes the problems you were seeing? I will try as soon as possible. I have halted my sparc due to some kernel instabilities (3.2 is not stable on all sun4u I have). Did you get a chance to have another look at this, or do you expect to do so in the near future? If not, I'll go ahead and close this bug for now. Note that the fix in experimental I referred to above has since been migrated to testing (it is in OpenTTD 1.3.0 and above). The stable version doesn't include the fix yet, though. Thanks, Matthijs signature.asc Description: Digital signature
Bug#641146: openttd: Swapped colors on sparc64
Matthijs Kooijman a écrit : Hi Joël, a while ago you reported a color problem with OpenTTD on your sparc64. Some palette-related fixes that made things work on my sparc64 with 8bit video were included in the 1.3.0 OpenTTD release, which was recently uploaded to experimental. Could you test the OpenTTD version in experimental and report if it fixes the problems you were seeing? I will try as soon as possible. I have halted my sparc due to some kernel instabilities (3.2 is not stable on all sun4u I have). Regards, JKB -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641146: openttd: Swapped colors on sparc64
Hi Joël, a while ago you reported a color problem with OpenTTD on your sparc64. Some palette-related fixes that made things work on my sparc64 with 8bit video were included in the 1.3.0 OpenTTD release, which was recently uploaded to experimental. Could you test the OpenTTD version in experimental and report if it fixes the problems you were seeing? Thanks, Matthijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641146: openttd: Swapped colors on sparc64
Hi Bertrand, I did a bit more digging into the palette code of SDL, trying to figure out what is happening and what we could be expecting from this. What follows is a fairly detailed description of what I've learned, which is probably not so interesting for you, but I wanted to write it down for future reference. You might want to skip ahead to the conclusion. at the end, where there's also a few questions for you. Pretty much all of the discussion below is platform-independent and has been tested both on sparc64 (with 32bit userland) and amd64. On sparc64, I've only tested with X running in 8bit mode since my hardware can't do anything else, on amd64 I've run in 32bit and 8bit modes (the latter needed the vesa driver to work, since apparently 8bit mode is broken in the modern intel drivers...). When a screen surface is created using SDL_SetVideoMode, there are a number of different palettes that can be created. - When the X11 visual is PseudoColor, and SDL_HWPALETTE is set, SDL allocates aprivate, changeable colormap (using XCreateColormap with AllocAll passed). This means that SDL has complete control over all the color values in the colormap and they can always be set to whatever value the application likes. The colormap allocated like this, is a virtual colormap. This means that even though we have complete control over our colormap, the colormap might not always be applied (since most hardware can only apply a single pixel - RGB colormap translation over the entire display, so if we control the entire colormap, there are no color cells left for other applications to use). According to [1], the window manager controls what application's colormap is installed at what time. I have found that on my Ultra1, the colormap is installed (that is, the colors become correcnt) when switching to fullscreen. [1]: http://menehune.opt.wfu.edu/Kokua/Irix_6.5.21_doc_cd/usr/share/Insight/library/SGI_bookshelves/SGI_Developer/books/XLib_PG/sgi_html/ch07.html#S1-1002-7-10 Note that this needs to be SDL fullscreen, switching to fullscreen using my window manager (awesome, meta+f) doesn't work. Looking at the SDL code, it seems when switching to fullscreen in X11_EnterFullScreen, it calls XInstallColormap to install the virtual color map, causing it to become active. However, when switching out of full screen, the colormap is _not_ uninstalled, causing the palette to remain correctly (for the SDL app, they are messed up for all other apps) until the SDL app quits or another SDL app starts in fullscreen. This behaviour does seem very window-manager specific. It seems awesome doesn't attempt to manage the installed colormap at all (so it looks broken until you switch to fullscreen, then it remains correct when switch back to windowed mode). xfwm4 seems to handle colormaps more sanely: the colormap of whatever window is focused is installed. This means that when starting OpenTTD under xfwm4, it is displayed correctly out of the box (but everything else, including the window decorations on the OpenTTD window itself, are messed up of course). Note that this virtual colormap thing (probably) does not apply when running an 8-bit window on 24/32 bit X. In this case, the display can actually display all colors, so only a translation from pixel to real rgb values needs to happen when rendering to the screen. I'm not entirely sure how this happens, since this is handled inside X, which I didn't investigate. - For PseudoColor without SDL_HWPALLETE, SDL uses the default X11 colormap. This means that a number of colors are already allocated by other applications, so there is only a limited amount of cells left. When allocating color cells, the application can only request specific colors and X11 will decide which pixel value to allocate to that color (or even an approximation of that color, if a similar color is already available, to save color cells). This means that when setting the pallete, you request a number of colors, but should check the palette after the request to see which colors actually ended up where. This mode is not very useful for OpenTTD, since you don't have complete control over the allocated colors (so no palette animation), there are not as many colors as OpenTTD needs and we would need to build our own OpenTTD pixel value - allocated color pixel value mapping. However, if implemented properly, this mode could be used to make OpenTTD work in windowed mode on 8-bit systems looking at least somewhat like the real deal. However, further code review shows that when you create a 32bit screen surface (e.g., SDL_SetVideoMode with a depth of 32) on an 8 bit X, SDL will create an 8bit screen surface and a 32bit shadow surface, and then do all this complicated mapping stuff when rendering the shadow surface to the screen surface
Bug#641146: openttd: Swapped colors on sparc64
And here are the attachments I promised in the previous mail... attachment: correct.pngattachment: wrong.png
Bug#641146: openttd: Swapped colors on sparc64
Hi Joël, On sparc64, openttd colors are swapped (green is green, but red seems to be replaced by blue and blue by red). I think there is an endianess trouble in openttd. I've managed to reproduce the problem (or at least _a_ problem) on an old Ultra1 I managed to get my hands on for this problem. I'm not quite sure what's wrong yet, it seems the palette OpenTTD is setting is somehow not (completely) used. I'll have to look into this a bit further, but it might be some kind of bug/limitation in libSDL or the hardware... Could you tell me on what hardware you observed this problem? In any case, this bug is not forgotten. Gr. Matthijs signature.asc Description: Digital signature
Bug#641146: openttd: Swapped colors on sparc64
Matthijs Kooijman a écrit : Hi Joël, On sparc64, openttd colors are swapped (green is green, but red seems to be replaced by blue and blue by red). I think there is an endianess trouble in openttd. I've managed to reproduce the problem (or at least _a_ problem) on an old Ultra1 I managed to get my hands on for this problem. I'm not quite sure what's wrong yet, it seems the palette OpenTTD is setting is somehow not (completely) used. I'll have to look into this a bit further, but it might be some kind of bug/limitation in libSDL or the hardware... Could you tell me on what hardware you observed this problem? Of course, Matthijs. I have seen this bug on my Blade2000 with Creator3D (ffb2+) in UPA slot. Regards, JKB -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641146: openttd: Swapped colors on sparc64
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
Bug#641146: openttd: Swapped colors on sparc64
Hi, I've just tried both OpenTTD 1.0.4-3 and 1.1.2-1 on a PowerPC install of Squeeze (in QEMU using the image from aurel32's site). For 1.1.2-1 I installed a newer libstdc++, gcc-4.6-base and multiarchsupport. The installed SDL version is libsdl1.2debian-alsa 1.2.14-6.1. In any case, in both cases OpenTTD colours are not messed up, i.e. they work fine. Given PowerPC is BE like Sparc, I'm assuming that OpenTTD is not having an endianness issue here but rather libsdl. If you are able to compile OpenTTD yourself it might be worth to try OpenTTD compiled with allegro. Then make sure allegro gets chosen by using openttd -v allegro. Alternatively you can see whether openttd -b 32bpp-optimized works around the issue. If that's the case, then I fear libsdl is doing something incorrectly with the palette. Or at least inconsistently over the different platforms. Is there a QEMU image for sparc64, or does QEMU still not support sparc64? I've read something about them not supporting 64 bits well enough when the sparc kernel became 64 bits, but could not find anything about the recent state. Without that I, sadly enough, can't be of much help in figuring out what goes wrong exactly. Regards, Rubidium -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641146: openttd: Swapped colors on sparc64
Package: openttd Version: 1.1.2-1 Severity: normal Dear Maintainer, On sparc64, openttd colors are swapped (green is green, but red seems to be replaced by blue and blue by red). I think there is an endianess trouble in openttd. Regards, JB -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: sparc (sparc64) Kernel: Linux 2.6.36.2 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openttd depends on: ii libc62.13-18 ii libfontconfig1 2.8.0-3 ii libfreetype6 2.4.6-2 ii libgcc1 1:4.6.1-4 ii libicu44 4.4.2-2 ii liblzma2 5.1.1alpha+20110809-2 ii liblzo2-22.05-2 ii libpng12-0 1.2.46-3 ii libsdl1.2debian 1.2.14-6.4 ii libstdc++6 4.6.1-4 ii openttd-data 1.1.2-1 ii zlib1g 1:1.2.3.4.dfsg-3 Versions of packages openttd recommends: ii openttd-opengfx 0.3.5-1 ii openttd-openmsx 0.3.1-1 ii timidity 2.13.2-39+b1 ii x11-utils7.6+3 Versions of packages openttd suggests: pn openttd-opensfx none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
