changeset 14446:b1ff74cc5b7d draft

(svn r19003) -Fix [FS#3194]: [OSX] OS X 10.5+ does not (always?) handle 8bpp graphics in a suitable manner. This is actually not a fix but a nasty work around; you can still easily trigger the bug/issue by overriding the 'default' blitter choice (Brad Oliver). I can/have not test(ed) (including compiling) this fix. Bjarni once suggested that 8bpp works for him on 10.5, so apparantly not all 10.5+ does not handle 8bpp graphics. Nevertheless, it seemed that for some systems the already existing 'does this support 8bpp' did not work, i.e. the OS API seemed to suggest that 8bpp worked when it actually did not. So, I don't know what is going on precisely here but it's definitely not nice to suggest that it supports 8bpp when it doesn't. So just ditch 8bpp support for anything that we suspect might not support 8bpp...
author rubidium <rubidium@openttd.org>
date Thu, 04 Feb 2010 14:32:12 +0000
parents 19d94a8ee95c
children cd9b79ff324f
files src/video/cocoa/fullscreen.mm
diffstat 1 files changed, 6 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/src/video/cocoa/fullscreen.mm
+++ b/src/video/cocoa/fullscreen.mm
@@ -28,6 +28,7 @@
 #include "../../core/sort_func.hpp"
 #include "cocoa_v.h"
 #include "../../gfx_func.h"
+#include "macos.h"
 
 /**
  * Important notice regarding all modifications!!!!!!!
@@ -134,6 +135,11 @@
 /** Small function to test if the main display can display 8 bpp in fullscreen */
 bool QZ_CanDisplay8bpp()
 {
+	/* 8bpp modes are deprecated starting in 10.5. CoreGraphics will return them
+	 * as available in the display list, but many features (e.g. palette animation)
+	 * will be broken. */
+	if (MacOSVersionIsAtLeast(10, 5, 0)) return false;
+
 	OTTD_Point p;
 
 	/* We want to know if 8 bpp is possible in fullscreen and not anything about