OpenTTD

Tasklist

FS#3194 - [OSX] Full Screen glitch

Attached to Project: OpenTTD
Opened by Innes (Innes) - Saturday, 12 September 2009, 09:05 GMT
Last edited by Remko Bijker (Rubidium) - Thursday, 04 February 2010, 14:32 GMT
Type Bug
Category Interface
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Medium
Priority Normal
Reported Version 0.7.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Since upgrading to Snow Leopard (MacOS 10.6), full screen mode sees the graphics strobeing primarily between magenta and a darker purple. Everything is almost impossible to make out
Taking screenshots just produce a black screen
This task depends upon

This task blocks these from closing
 FS#2782 - [OSX] Port hopelessly outdated 
Closed by  Remko Bijker (Rubidium)
Thursday, 04 February 2010, 14:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  Well... worked around crappy OS X lieing in r19003
Comment by Daniel Plaumann (dandan) - Saturday, 12 September 2009, 12:29 GMT
I had the same issue and found that switching to 32bpp solved the problem (add blitter = 32bpp-simple in the [misc] section of openttd.cfg). After that, I also had to increase sprite_cache_size to something like 32 or 64 to get smooth animations again.
Comment by Ingo von Borstel (planetmaker) - Wednesday, 16 September 2009, 20:50 GMT
I cannot reproduce either problem on my machine with the official, downloaded 0.7, neither with TTD base graphics nor OpenGFX base graphics. Can you provide more details on your systems as to get a clue why it doesn't work for you but for me?
Comment by atze (atze) - Sunday, 20 September 2009, 18:07 GMT
Same problem here:
Fullscreen flashes magenta and pinkish.
Windowed works fine.

MacBookPro2,1
Mac OS X 10.6.1

ls -l /Applications/Games/openttd-0.7.2-macosx-universal/data/addons
total 6200
drwxrwxrwx 6 atze atze 204 22 Sep 2007 alpinew
drwxrwxrwx 4 atze atze 136 22 Sep 2007 arcticsetw
drwxrwxrwx 5 atze atze 170 22 Sep 2007 cargosetw
drwxrwxrwx 5 atze atze 170 7 Jan 2007 dbsetxlw
drwxrwxrwx 5 atze atze 170 22 Sep 2007 newcargow
drwxrwxrwx 4 atze atze 136 22 Sep 2007 newshipsw
drwxrwxrwx 5 atze atze 170 7 Jan 2007 newstatsw
-rw-rw-rw- 1 atze atze 1341599 20 Okt 2006 pb_av8w.grf
-rw-rw-rw- 1 atze atze 1559603 28 Okt 2006 pb_ukrs.grf
-rw-rw-rw- 1 atze atze 163169 2 Okt 2006 pb_ukrsi.grf
-rw-rw-rw- 1 atze atze 41795 14 Feb 2006 pb_viaduct.grf
-rw-rw-rw- 1 atze atze 59539 22 Okt 2006 ukrsap1w.grf
Comment by m1ss1ontomars2k4 (m1ss1ontomars2k4) - Saturday, 14 November 2009, 18:45 GMT
Since a lot of us are obviously not having this problem, I think more information on hardware is on order. atze's MBP has an ATI Mobility Radeon X1600, but what about Daniel and Innes?
Comment by Ingo von Borstel (planetmaker) - Wednesday, 16 December 2009, 17:15 GMT
I tried different blitters. I get the issue (only) with blitter = "8bpp-debug" (see attached screenshot). All others work for me (tested r18435)
Comment by Michael Lutz (michi_cc) - Wednesday, 16 December 2009, 18:36 GMT
Isn't this wrong-colour view actually the whole point of 8bpp-debug?
Or am I misremembering that?
Comment by Ingo von Borstel (planetmaker) - Wednesday, 16 December 2009, 19:58 GMT
Subsequent discussion in #openttd taught me that, yes. So... my previous comment is quite mute. Sorry.
Comment by Mathew Maher (mmaher) - Thursday, 07 January 2010, 20:45 GMT
The problem is because the colour palette is being reset every blitter cycle. What you are seeing is the screen being drawn whilst the new colours are being written into the palette. Simple solution is to remove this call and instead just set the palette once when you go into full screen mode. Attached is a diff for the correction.
Comment by Remko Bijker (Rubidium) - Thursday, 07 January 2010, 22:20 GMT
Looks, based on the code change, that you're breaking palette animation of the 8bpp blitter.
Comment by Ingo von Borstel (planetmaker) - Friday, 08 January 2010, 06:31 GMT
Indeed, the palette animation in fullscreen view is gone with that patch (a good test is either the ocean waves or Japanese houses). Tested on OSX 10.6.2 with r18737.

Another noteworthy thing most probably directly related to this: the mouse pointer leaves a permanent glitch on the screen at the place it is located when switching to full screen - mostly in purple and black. I cannot make screenshots of it as those show 100% black for the whole screen as already the original poster stated. EDIT to add: this happens for me with palette 8bpp-optimized and doesn't show with 32bpp-anim.

Interestingly enough, there have been in one test run console error reports (probably related to http://bugs.openttd.org/task/3198 ):
Fri Jan 8 07:07:45 aeolusreloaded openttd[553] <Error>: kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x1030d73f0)
Fri Jan 8 07:07:45 aeolusreloaded openttd[553] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Fri Jan 8 07:07:45 aeolusreloaded openttd[553] <Error>: kCGErrorCannotComplete: CGSSetWindowColorSpace: Cannot create color profile
Fri Jan 8 07:08:32 aeolusreloaded openttd[553] <Error>: kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x101d82c70)
Fri Jan 8 07:08:32 aeolusreloaded openttd[553] <Error>: kCGErrorCannotComplete: CGSSetWindowColorSpace: Cannot create color profile
which I couldn't reproduce in subsequent tests. But it doesn't look like there's any colour space or profile which actually really failed...
Comment by xmirakulix (xmirakulix) - Sunday, 10 January 2010, 09:46 GMT
I can confirm that the animations don't work with the patch applied to the latest svn pull r18742 (on 10.6.2).

The previously mentioned console output occurs (can be reproduced), when I run the latest build without the patch applied and switch to fullscreen mode:
flo-imac:openttd-svn flo$ make run
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
Sun Jan 10 10:27:53 flo-imac openttd[4121] <Error>: kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x100917d10)
Sun Jan 10 10:27:53 flo-imac openttd[4121] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Sun Jan 10 10:27:53 flo-imac openttd[4121] <Error>: kCGErrorCannotComplete: CGSSetWindowColorSpace: Cannot create color profile
Comment by Brad Oliver (hoserama99) - Sunday, 17 January 2010, 17:34 GMT
I can provide some technical details on the issue. Starting midway through 10.5 and continuing in 10.6, most of the video drivers have deprecated (and in some cases removed) support for 8-bit modes.

I'm not fully up on what OpenTTD supports for blitting yet, but aside from up-blitting to 16 and 32-bit, one solution is to, on systems supporting 10.5, use an OpenGL blitter for 8-bit modes. This has the net effect of keeping decent 8-bit blitting on 10.4 and lower (and thus lower-end Macs) where GL card support is spotty.

The blitter would keep the game bitmap in one texture (or texture set) and a palette lookup in another texture, with a simple ARB fragment program doing the palette lookup.

Would this be seen as an acceptable patch?
Comment by Michael Lutz (michi_cc) - Sunday, 17 January 2010, 18:26 GMT
There are currently three video back-ends for OSX. If such a patch would replace some of
them (and not add a fourth creating even more maintenance problems, i.e. work in all cases
one of the old back-ends worked) and is reasonable fast and not too big, it could be an
option.
Actual inclusion is hindered by no OSX maintainer though, seeing that no virtualisation
software supports real OpenGL AFAIK, meaning that no current developer could actually
test such a patch.
Comment by Brad Oliver (hoserama99) - Monday, 18 January 2010, 21:03 GMT
Attached is a patch to fix this. It defaults to the 32bpp blitter by default on 10.5+.
Comment by Mathew Maher (mmaher) - Monday, 18 January 2010, 22:29 GMT
Well that patch works, although you need to fully reference macos.h:

#include "../../os/macosx/macos.h"

New build made with this fix, if anyone wants to double-check it:
http://sites.google.com/site/openttdosx/home/osx
Comment by Brad Oliver (hoserama99) - Saturday, 23 January 2010, 17:44 GMT
I believe this bug should be closed as fixed with my last patch, unless someone has any other complaints?
Comment by Remko Bijker (Rubidium) - Saturday, 23 January 2010, 18:46 GMT
What if someone uses the 8 bits blitter by forcing it in the config file? Which might happen when they copy the config file from a friend or their Windows/Linux computer? What the patch does, as far as I can see at least, is change the default but still allow "known" broken configurations, i.e. it does not fix the bug, it makes it less visible.
Comment by Brad Oliver (hoserama99) - Saturday, 23 January 2010, 22:48 GMT
Yes, I left in the possibility to force 8bpp via the config in case someone wanted to try it on 10.5, but I can remove that if desired.

Loading...