Age | Commit message (Collapse) | Author |
|
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
|
|
_realtime_tick was reset every time the diff was calculated. This
means if it would trigger, say, every N.9 milliseconds, it would
after two iterations already drift a millisecond. This adds up
pretty quick.
|
|
On all OSes we tested the std::chrono::steady_clock is of a high
enough resolution to do millisecond measurements, which is all we
need.
By accident, this fixes a Win32 driver bug, where we would never
hit our targets, as the resolution of the clock was too low to
do accurate millisecond measurements with (it was ~16ms resolution
instead).
|
|
|
|
|
|
|
|
|
|
emphasise differences.
|
|
|
|
|
|
|
|
|
|
We assume a conforming C++11 compiler environment that has a valid <thread>-header.
Failure to run a real thread is handled gracefully.
|
|
A conforming compiler with a valid <mutex>-header is expected.
Most parts of the code assume that locking a mutex will never fail unexpectedly,
which is generally true on all common platforms that don't just pretend to
be C++11. The use of condition variables in driver code is checked.
|
|
|
|
In 10 years there is no commit to change how BeOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).
With the arrival of SDL2 (and removal of SDL), BeOS is no longer
support. SDL2 suggests to use Haiku instead of BeOS.
|
|
In 10 years there is no commit to change how MorphOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).
With the arrival of SDL2 (and removal of SDL), MorphOS is no longer
support. There is an SDL2 port for MorphOS, but it is not maintained
by upstream SDL2, and nobody can currently test it out.
If anyone wants to re-add MorphOS, please do (revert this patch,
fix the problems, and create a Pull Request). If you need any help
doing so, let us know! It is not that we don't like MorphOS, it is
that we don't have anyone fixing the problems :(
|
|
|
|
macro _WIN32
|
|
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.
|
|
|
|
switching blitters. (JGR)
|
|
while paused skipped initialisation of the palette and resulted in black windows.
-Revert (r23978): No SDL-specific fix required anymore. The new fix applies to all backends.
|
|
threads. (JGR)
|
|
scrolled/jumped way to far, when OpenTTD lagged during mouse event processing.
|
|
|
|
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.
|
|
file io code instead of assuming MAX_PATH is okay
|
|
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
|
|
|
|
|
|
keyboard handler.
|
|
gets mouse focus while going to full screen, so manually force the mouse-is-in-window state
|
|
fullscreen toggle
|
|
set due to referencing a deleted mutex
|
|
palette was requested.
- Previously, the code would query the SDL_HWPALETTE flag, which doesn't always match the requested value.
- This would cause SDL to be restarted on every window resize event, effectively breaking resizing.
|
|
|
|
always requesting SDL_HWPALETTE, it is now only done for 8bp blitters in fullscreen mode.
- This fixes 32bpp blitters on 8bpp X11, which would only render garbage with SDL_HWPALETTE.
- This prevents the colors of other applications from being messed up when running a 8bpp blitter on a 8bpp system.
- When running a 8bpp blitter on an 8bpp system without SDL_HWPALETTE (e.g., in windowed mode), this uses a new shadow surface with color approximation.
- The use of a hardware palette can be forced on and off using -v sdl:hw_palette=1 or -v sdl:hw_palette=0
|
|
methods instead of static functions.
|
|
Eagle_rainbow)
|
|
|
|
from 8bpp -> 32bpp look ugly
|
|
- It seems this event is never triggered when using 1.2 (it has some
autorefresh feature which seems to have been removed in 1.3), but in theory
this event could also trigger on 1.2.
- Note that this fixes redraw issues when compiling against SDL 1.3, but it
still uses the "compatibility" rendering API using SDL_SetVideoMode and
SDL_UpdateRects. Eventually (when 1.3 is stable and released as 2.0), this
should probably be rewritting to use the new Windows and Renderers
available in SDL 1.3.
|
|
against SDL 1.3.
|
|
|
|
draw thread instead of the single threaded bit of the game loop. This causes a speedup of up to 15% when animation is turned on with the 32bpp-anim blitter
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|