summaryrefslogtreecommitdiff
path: root/src/video/sdl_v.cpp
AgeCommit message (Collapse)Author
2021-03-08Add: [Video] move GameLoop into its own threadPatric Stout
This allows drawing to happen while the GameLoop is doing an iteration too. Sadly, not much drawing currently can be done while the GameLoop is running, as for example PollEvent() or UpdateWindows() can influence the game-state. As such, they first need to acquire a lock on the game-state before they can be called. Currently, the main advantage is the time spend in Paint(), which for non-OpenGL drivers can be a few milliseconds. For OpenGL this is more like 0.05 milliseconds; in these instances this change doesn't add any benefits for now. This is an alternative to the former "draw-thread", which moved the drawing in a thread for some OSes. It has similar performance gain as this does, although this implementation allows for more finer control over what suffers when the GameLoop takes too long: drawing or the next GameLoop. For now they both suffer equally.
2021-03-08Remove: [Video] no longer draw in a threadPatric Stout
Drawing in a thread is a bit odd, and often leads to surprising issues. For example, OpenGL would only allow it if you move the full context to the thread. Which is not always easily done on all OSes. In general, the advise is to handle system events and drawing from the main thread, and do everything else in other threads. So, let's be more like other games. Additionally, putting the drawing routine in a thread was only done for a few targets. Upcoming commit will move the GameLoop in a thread, which will work for all targets.
2021-03-08Fix #8784: using alt+enter didn't update the fullscreen toggle visibly (#8820)Patric Stout
Basically, the window was not invalidated, so it was never redrawn. This made it look like it wasn't working, but it really was.
2021-02-28Add: settings to limit your fast-forward game speedPatric Stout
By default this setting is set to 2500% normal game speed.
2021-02-24Codechange: [Video] move InteractiveRandom() to the VideoDriverPatric Stout
2021-02-24Codechange: [Video] make the prototype of PollEvent() the same for all driversPatric Stout
Additionally, call it from the draw-tick.
2021-02-20Remove: [SDL] SDL 1.3 never happened, so remove all the special code for itPatric Stout
2021-02-20Codechange: deduplicate tick-handlers of all video driversPatric Stout
They were all identical, so better put this in a single place hoping it is less likely to break.
2021-02-20Codechange: be consistent in what CheckPaletteAnim() does and when it is calledPatric Stout
Additionally, make sure this is a class method. Later commits will make use of this.
2021-02-20Codechange: be consistent in naming the paint function Paint()Patric Stout
Also move this function to be a class member. This to allow further deduplicating of code in a later commit.
2021-02-20Codechange: use (Un)LockVideoBuffer() to manage video bufferPatric Stout
2021-02-20Codechange: move all input-handling of video-drivers into InputLoopPatric Stout
2021-02-19Fix: during switching of game-mode, drawing could show closed windows that ↵Patric Stout
shouldn't be closed yet The higher your refresh-rate, the more likely this is. Mostly you notice this when creating a new game or when abandoning a game. This is a bit of a hack to keep the old behaviour, as before this patch the game was already freezing your mouse while it was changing game-mode, and it does this too after this patch. Just now it freezes too a few frames earlier, to prevent not drawing windows people still expect to see.
2021-02-19Feature: configurable refresh-rate and change default to 60fpsPatric Stout
Most modern games run on 60 fps, and for good reason. This gives a much smoother experiences. As some people have monitors that can do 144Hz or even 240Hz, allow people to configure the refresh rate. Of course, the higher you set the value, the more time the game spends on drawing pixels instead of simulating the game, which has an effect on simulation speed. The simulation will still always run at 33.33 fps, and is not influences by this setting.
2021-02-19Change: sleep till the next tick in the main loopPatric Stout
Sleep for 1ms (which is always (a lot) more than 1ms) is just randomly guessing and hoping you hit your deadline, give or take. But given we can calculate when our next frame is happening, we can just sleep for that exact amount. As these values are often a bit larger, it is also more likely the OS can schedule us back in close to our requested target. This means it is more likely we hit our deadlines, which makes the FPS a lot more stable.
2021-02-19Change: allow video-drivers to miss deadlines slightlyPatric Stout
Before, every next frame was calculated from the current time. If for some reason the current frame was drifting a bit, the next would too, and the next more, etc etc. This meant we rarely hit the targets we would like, like 33.33fps. Instead, allow video-drivers to drift slightly, and schedule the next frame based on the time the last should have happened. Only if the drift gets too much, that deadlines are missed for longer period of times, schedule the next frame based on the current time. This makes the FPS a lot smoother, as sleeps aren't as exact as you might think.
2021-02-19Add: draw the screen at a steady pace, also during fast-forwardPatric Stout
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.
2021-02-19Codechange: track _realtime_tick more accuratePatric Stout
_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.
2021-02-19Codechange: switch all video drivers to std::chrono for keeping timePatric Stout
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).
2021-02-14Fix: VkMapping declarations violated C++ ODR rule.milek7
2021-01-14Feature: Choose a sensible window size on a fresh OTTD config file. (#8536)Michael Lutz
2021-01-08Codechange: Remove min/max functions in favour of STL variants (#8502)Charles Pigott
2020-12-27Codechange: Use std::string in FIO search path handling.Michael Lutz
2020-06-04Codechange: Realign SDL driver with SDL2 driver to ease maintenance and ↵TechGeekNZ
emphasise differences.
2020-05-21Codechange: Use std::string in the driver and blitter selection code.Michael Lutz
2019-11-10Cleanup: Removed SVN headersS. D. Cloudt
2019-04-18Codechange: use std::vector for _resolutionsglx
2019-04-10Codechange: Use null pointer literal instead of the NULL macroHenry Wilson
2019-04-06Codechange: Replace custom thread code with C++11 thread objects.Michael Lutz
We assume a conforming C++11 compiler environment that has a valid <thread>-header. Failure to run a real thread is handled gracefully.
2019-04-06Codechange: Replace custom mutex code with C++11 mutex'es.Michael Lutz
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.
2019-03-30Change: [SDL] Do not offer video smaller than 640x480Niels Martin Hansen
2019-03-05Remove: BeOS support (deprecated by Haiku)Patric Stout
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.
2019-03-05Remove: MorphOS / AmigaOS supportPatric Stout
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 :(
2019-03-02Codechange: Remove ability for SDL to be dynamically loaded on WindowsCharles Pigott
2018-12-27Fix: [Win32] WIN32 may not be defined, always prefer the compiler predefined ↵glx
macro _WIN32
2018-07-19Feature: Framerate display window (#6822)Niels Martin Hansen
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.
2018-04-30Fix: Some spelling errors in printed messagesMatthijs Kooijman
2017-03-11(svn r27775) -Fix [FS#6510]: Insufficient thread synchronisation when ↵frosch
switching blitters. (JGR)
2017-03-11(svn r27774) -Fix [FS#5889]: Enabling palette animation for 32bpp blitters ↵frosch
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.
2016-10-30(svn r27670) -Add: [FS#6471] Assign descriptive names to (GNU pthread) ↵frosch
threads. (JGR)
2015-02-22(svn r27167) -Fix: [SDL, Windows] Right-mouse-button scrolling ↵frosch
scrolled/jumped way to far, when OpenTTD lagged during mouse event processing.
2014-04-28(svn r26538) -Codechange: remove double accounting of the driversrubidium
2014-04-27(svn r26522) -Add: A config-file-only setting to disable usage of 8bpp video ↵frosch
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.
2014-04-23(svn r26489) -Codechange: properly account for the end of buffers in the ↵rubidium
file io code instead of assuming MAX_PATH is okay
2014-04-23(svn r26486) -Codechange: replace a number of snprintfs with seprintfrubidium
2014-04-23(svn r26482) -Codechange: add an include that allows us to undefine/redefine ↵rubidium
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
2014-02-16(svn r26351) -Fix: Protect all VideoDriver_SDL methods with the _draw_mutex.frosch
2014-01-02(svn r26209) -Codechange: remove some template magic and simplify some coderubidium
2013-11-12(svn r25970) -Fix [FS#5787]: [SDL] Recursive mutex locking when changing blitterrubidium
2013-08-05(svn r25671) -Codechange: Pass character and key code separately to the ↵michi_cc
keyboard handler.