dandan wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment6639

planetmaker wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment6658

atze wrote:

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

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment6711

m1ss1ontomars2k4 wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment6956

planetmaker wrote:

I tried different blitters. I get the issue (only) with blitter = "8bpp-debug" (see attached screenshot). All others work for me (tested r18435)

Attachments

• Bildschirmfoto 2009-12-16 um 18.10.00.png (199.19 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7061

michi_cc wrote:

Isn't this wrong-colour view actually the whole point of 8bpp-debug?
Or am I misremembering that?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7062

planetmaker wrote:

Subsequent discussion in # openttd taught me that, yes. So... my previous comment is quite mute. Sorry.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7063

mmaher wrote:

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.

Attachments

• fullscreen.diff (1.07 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7293

Rubidium wrote:

Looks, based on the code change, that you're breaking palette animation of the 8bpp blitter.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7294

planetmaker wrote:

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] : kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x1030d73f0)
Fri Jan 8 07:07:45 aeolusreloaded openttd[553] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Fri Jan 8 07:07:45 aeolusreloaded openttd[553] : kCGErrorCannotComplete: CGSSetWindowColorSpace: Cannot create color profile
Fri Jan 8 07:08:32 aeolusreloaded openttd[553] : kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x101d82c70)
Fri Jan 8 07:08:32 aeolusreloaded openttd[553] : 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...

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7295

xmirakulix wrote:

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] : kCGErrorFailure: CGSColorProfileCreateWithColorSpace: Invalid ICC color space(0x100917d10)
Sun Jan 10 10:27:53 flo-imac openttd[4121] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Sun Jan 10 10:27:53 flo-imac openttd[4121] : kCGErrorCannotComplete: CGSSetWindowColorSpace: Cannot create color profile

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7322

hoserama99 wrote:

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?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7378

michi_cc wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7379

hoserama99 wrote:

Attached is a patch to fix this. It defaults to the 32bpp blitter by default on 10.5+.

Attachments

• fullscreen.mm.patch (1.06 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7390

mmaher wrote:

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

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7393

hoserama99 wrote:

I believe this bug should be closed as fixed with my last patch, unless someone has any other complaints?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7434

Rubidium wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7438

hoserama99 wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194#comment7441

Rubidium closed the ticket.

Reason for closing: Fixed

Well... worked around crappy OS X lieing in r19003

This comment was imported from FlySpray: https://bugs.openttd.org/task/3194