| Age | Commit message (Collapse) | Author |
|---|
|
Eagle_rainbow)
|
|
|
|
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|
|
|
|
|
|
fallback on OSX 10.7. Also add a few sprinkles of coding style accross cocoa display drivers
|
|
OSX 10.6 in the quartz video driver
|
|
|
|
on patch by leecbaker)
-Add: [OSX] Support for fullscreen mode when compiled against SDK 10.7. Otherwise fullscreen mode is disabled when OpenTTD is run on OSX Lion
|
|
|
|
it doesn't recompile everything that needs to be recompiled...
|
|
|
|
certain circumstances (based on patch by matheweis)
|
|
the window class for screen drivers to a common class
|
|
the view for windowed screen drivers to a common class
|
|
routines in windowed screen drivers
|
|
drivers to the generic class, deduplicating code
|
|
different screen drivers a bit
|
|
colour depths at once
|
|
|
|
quickdraw
|
|
milliseconds per game tick and use it
|
|
|
|
full screen mode
|
|
blitter when switching to full screen
|
|
blitter during start-up
|
|
patches lately... they either fail to compile or spew warnings
|
|
|
|
all other platforms (matheweis)
|
|
missed :)
|
|
consisted of unrelated values use static const (u)int
|
|
|
|
|
|
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...
|
|
was only validated during sprite blitting, other drawing operations didn't check it. Initial startup and window resize could therefore lead to crash.
|
|
getting the system colour profile failed. (tyler)
|
|
allocated.
|
|
video driver was used.
|
|
variable definitions with goto's. (planetmaker)
|
|
|
|
in a way that does not rely on the SDK version.
|
|
cleaning.
|
|
|
|
apply more coding style.
|
|
manager API calls with a documented alternative. (pyth)
|
|
Cocoa string.
|
|
box if it was hidden.
|
|
CrashLog infrastructure.
|
