|
Patric Stout
|
r28750:2657250b24e9
|
10 months ago
|
|
|
|
Rubidium
|
r27544:ff436bece3b8
|
18 months ago
|
|
|
|
Patric Stout
|
r27498:6d2aaf65c3e6
|
18 months ago
|
|
|
|
Patric Stout
|
r25712:79f3a6be4b7c
|
3 years ago
|
|
Fix: don't propagate shift/ctrl state till next game-tick ( #9381) When the game-loop is very slow, it was easily possible to start the loop with _shift_pressed being false, but end with _shift_pressed being true. This doesn't hurt the game as such, but for the user this can be very weird: I pressed "Buy Vehicle", pressed shift a bit later, and I still get a cost indication.
|
|
rubidium42
|
r25655:1030dcb7eb52
|
3 years ago
|
|
|
|
Milek7
|
r25368:ce512f9277c7
|
4 years ago
|
|
|
|
Michael Lutz
|
r25363:aeaaaf1c6dce
|
4 years ago
|
|
|
|
Peter Nelson
|
r25324:71e56110ba9f
|
4 years ago
|
|
|
|
Patric Stout
|
r25161:560705f96b3e
|
4 years ago
|
|
Feature: allow a toggle to enable/disable vsync
Vsync should be off by default, as for most players it will be better to play without vsync. Exception exist, mainly people who play in fullscreen mode.
|
|
Patric Stout
|
r25029:37f02ef4446d
|
4 years ago
|
|
Add: make modal windows update more smooth
Basically, modal windows had their own thread-locking for what drawing was possible. This is a bit nonsense now we have a game-thread. And it makes much more sense to do things like NewGRFScan and GenerateWorld in the game-thread, and not in a thread next to the game-thread.
This commit changes that: it removes the threads for NewGRFScan and GenerateWorld, and just runs the code in the game-thread. On regular intervals it allows the draw-thread to do a tick, which gives a much smoother look and feel.
It does slow down NewGRFScan and GenerateWorld ever so slightly as it spends more time on drawing. But the slowdown is not measureable on my machines (with 700+ NewGRFs / 4kx4k map and a Debug build).
Running without a game-thread means NewGRFScan and GenerateWorld are now blocking.
|
|
Patric Stout
|
r25015:8deed239577a
|
4 years ago
|
|
Fix: ensure switching blitter happens in the main thread
This because video-drivers might need to make changes to their context, which for most video-drivers has to be done in the same thread as the window was created; main thread in our case.
|
|
Patric Stout
|
r25014:e1f1bf3a062e
|
4 years ago
|
|
Add: [Video] move GameLoop into its own thread
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.
|
|
Patric Stout
|
r25011:61d28a13bb41
|
4 years ago
|
|
Remove: [Video] no longer draw in a thread
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.
|
|
Patric Stout
|
r25003:fdd8312ceea6
|
4 years ago
|
|
Add: Option to (dis-)allow accelerated video drivers. ( #8819) The video drivers using the OpenGL backend are currently our only accelerated drivers. The options defaults to off for macOS builds and to on everywhere else. Co-authored-by: Michael Lutz <michi@icosahedron.de>
|
|
Patric Stout
|
r24982:e1cfbcf8356c
|
4 years ago
|
|
Fix c4df0f95: bootstrap was only showing a black screen ( #8788) The bootstrap has the _switch_mode to SM_MENU, and never leaves this mode. Neither is it considered a modal window (while in some sense it really is). So .. we need to add another "draw anyway" exception, to make sure bootstrap is being drawn.
|
|
Patric Stout
|
r24970:1ff44d19fa4a
|
4 years ago
|
|
Add: settings to limit your fast-forward game speed
By default this setting is set to 2500% normal game speed.
|
|
Patric Stout
|
r24954:aa16760b21f3
|
4 years ago
|
|
|
|
Patric Stout
|
r24940:46781aedfe1c
|
4 years ago
|
|
|
|
Patric Stout
|
r24939:f00f6879a003
|
4 years ago
|
|
Codechange: [Video] make the prototype of PollEvent() the same for all drivers
Additionally, call it from the draw-tick.
|
|
Patric Stout
|
r24855:196c88971d0d
|
4 years ago
|
|
Codechange: deduplicate tick-handlers of all video drivers
They were all identical, so better put this in a single place hoping it is less likely to break.
|