| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Frame rate and various game loop/graphics timing measurements and graphs. Accessible via the Help menu, and can print some stats in the console via the fps command.
|
|
This was caused by a missing \0-character on reaching the buffer limit.
|
|
|
|
|
|
properly with the Windows 10 Fall Creators Update.
|
|
|
|
switching blitters. (JGR)
|
|
|
|
scrolled/jumped way to far, when OpenTTD lagged during mouse event processing.
|
|
unsigned variables when using gcc
|
|
|
|
modes.
-Remove: [win32] fullscreen_bpp setting, which is replaced by above setting.
-Change: Disable usage of 8bpp blitters and video modes by default. Many modern OS and hardware cause issues with those.
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
thread has finished initialising, preventing potential deadlocks.
|
|
(frosch123)
|
|
ready and set _screen.dst_ptr immediately when the buffer changes (frosch123)
|
|
called via WndProcGdi which already has the mutex. The issue which r25550 tried to fix still exists as FS#5867.
|
|
sse blitters (MJP)
|
|
With 32bpp base set about 30% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 5 and 1% of total run time
|
|
|
|
non-enumeral type
|
|
|
|
position.
|
|
caret position.
|
|
the input focus changes.
|
|
directly without a trip through the window messaging system.
|
|
non-Unicode build.
|
|
strings into UTF-8 for non-Unicode builds. And don't crap out on DBCS code pages either.
|
|
correctly.
|
|
keyboard handler.
|
|
edit box has the input focus.
|
|
threads could crash OpenTTD
|
|
Eagle_rainbow)
|
|
|
|
unsupported fullscreen display mode (like 8 bpp modes in Windows 8).
|
|
|
|
resolution you were, not to the fullscreen resolution (Windows only)
|
|
(fullscreen, 8bpp/32bpp), and a window already exists, it was forced out of maximize mode, and its resolution/position was reset, often causing unwanted side-effects. As a "bonus", a WC_SIZE was triggered, and if the system was going from 8bpp to 32pp, this caused a forced window update in a limbo-state of the blitter (not fully 32bpp just yet, but for sure no longer 8bpp); this could cause random memory access which could lead to ACCESS_VIOLATIONS
|
|
threaded drawing.
|
|
|
|
animation into a separate thread.
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|
|
cursor more prominently during the initialisation of OpenTTD
|
|
|
|
|
|
go to full screen at the resolution of the configuration file when starting OpenTTD
|
|
|
