| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
load), and add support for (safe) loading with a LoadFilter
|
|
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
|
|
|
|
to terminate a dedicated OpenTTD
|
|
all other platforms (matheweis)
|
|
|
|
|
|
|
|
|
|
|
|
missed :)
|
|
_rightclick_emulate
|
|
VARDEF and put them in a more logical location
|
|
the cursor ha left the window
|
|
|
|
sync during GUI operation.
|
|
|
|
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...
|
|
if a header require a header make it include that header
|
|
while starting it
|
|
with a dedicated server
|
|
under high CPU load. Revert as change caused more problems than it fixed.
|
|
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)
|
|
the resolution for SDL via the in game menu
|
|
allocated.
|
|
|
|
right button pressed at the same time.
|
|
movement isn't needed anymore because after each even that movement is handled and the counter is reset. As such simply assigning instead of adding works.
|
|
right-click-dragging
|
