summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2021-03-14Update: Translations from eintstranslators
norwegian (bokmal): 5 changes by Anolitt estonian: 13 changes by siimsoni korean: 5 changes by telk5093 italian: 1 change by AlphaJack german: 5 changes by danidoedel ukrainian: 15 changes by StepanIvasyn catalan: 5 changes by J0anJosep dutch: 5 changes by Afoklala lithuanian: 82 changes by devbotas spanish: 255 changes by MontyMontana portuguese (brazilian): 5 changes by Greavez
2021-03-14Doc: Clarify comment that SND_05_TRAIN_THROUGH_TUNNEL is only for steam ↵Tyler Trahan
engines (#8858)
2021-03-14Codechange: we are not booing straps .. we are bootstrappingPatric Stout
2021-03-14Fix: errors during bootstrap could still show up after bootstrapPatric Stout
For example, if you have a config that defines OpenGFX as baseset but for some reason you have no basesets anymore. In that case bootstrap downloads OpenGFX for you, but it will still show the error that "OpenGFX was not found" after the bootstrap. This was an error generated before the bootstrapped kicked in. Simply muting all errors during bootstrap solves this; as we cannot show them anyway, this is fine. Any errors that remain after bootstrap will be generated again anyway.
2021-03-14Fix: if bootstrap failed, it could end with an empty screen instead of errorPatric Stout
There are various of ways bootstrap can fail: - Failing network connection - Incomplete download - No write permissions - Disk full - (others I forgot) They all result in a screen with no windows. To ensure we at least always show something when anything bad happens, if the bootstrap is not successful, show a screen what the next step for the human should be.
2021-03-13Fix #8860: [Win32] Crashlog window wasn't reliably shown for crashes not on ↵Michael Lutz
the main thread.
2021-03-13Update: Translations from eintstranslators
english (us): 7 changes by 2TallTyler estonian: 17 changes by siimsoni hungarian: 100 changes by pnpBrumi ukrainian: 8 changes by StepanIvasyn dutch: 24 changes by Afoklala spanish: 338 changes by MontyMontana french: 29 changes by MalaGaM portuguese (brazilian): 1 change by Greavez
2021-03-13Fix #8851: don't allow infinite "exec" depth in script, but limit to 10 deepPatric Stout
This means if you execute a script from a script from a script, .. for more than 10 times, it bails out now. This should be sufficient for even the most complex scripts.
2021-03-13Fix: calling "exec" from script never returnedPatric Stout
Example: exec other.script echo hello The "echo" was never executed.
2021-03-13Feature: allow setting maximum zoom level at which sprites are drawn (#8604)Matt Kimber
2021-03-13Feature: allow filtering on name in rail station window (#8706)Didac Perez Parera
2021-03-11Fix #8733: Can't buy train engine when the "Engines only" filter is activestormcone
2021-03-11Update: Translations from eintstranslators
swedish: 22 changes by kustridaren ukrainian: 4 changes by StepanIvasyn lithuanian: 7 changes by devbotas spanish: 312 changes by MontyMontana
2021-03-11Change: Recolour graph windows to brown (#8700)Tyler Trahan
2021-03-11Fix #8647: draw tram catenary using 4 bounding boxes.frosch
The back sprite is now supposed to contain west, north and east pillars. The front sprite is supposed to contain the south pillar and the wires.
2021-03-11Fix: front/back sprites of action5 tram catenary were swapped.frosch
2021-03-10Codechange: Add fast path to catenary drawing in MaskWireBitsJonathan G Rennison
MaskWireBits always returns its input unchanged if the input has only 0 or 1 track bits set. Having only 0 or 1 track bits sets (i.e. non junction tiles) is by far the most common case. Examining the state of neighbouring tiles and the subsequent masking logic is relatively expensive and can be omitted in this case.
2021-03-10Update: Translations from eintstranslators
norwegian (bokmal): 26 changes by Anolitt spanish (mexican): 25 changes by absay japanese: 11 changes by Azusa257 korean: 7 changes by telk5093 german: 7 changes by danidoedel russian: 63 changes by Ln-Wolf finnish: 7 changes by hpiirai ukrainian: 5 changes by StepanIvasyn catalan: 7 changes by J0anJosep spanish: 7 changes by MontyMontana portuguese (brazilian): 12 changes by Greavez
2021-03-10Codechange: rework codeflow introduced in 098d5b22 (#8837)Patric Stout
It didn't sit well to me, how I wrote the commit initially. First casting a variable into another, only to write it back into the originally feels wrong. This flow makes a bit more sense to me.
2021-03-10Fix #8833: don't reload NewGRFs when we are shutting downPatric Stout
Otherwise that might cause calls to the video-driver, which are already shut down by now. This causes, depending on the video-driver crashes or weird effects.
2021-03-10Fix: abort world generation on exiting the game as soon as possiblePatric Stout
This prevents the window from "freezing" when you close it during world generation, as it first would continue the action.
2021-03-10Fix: abort GRFFileScanner on exiting the game as soon as possiblePatric Stout
This prevents the window from "freezing" when you close it during the scanning of NewGRFs, as it first would continue the action.
2021-03-10Fix: don't update framerates when a modal window is openPatric Stout
Otherwise the numbers are all over the place when a modal window just closed.
2021-03-10Add: make modal windows update more smoothPatric Stout
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.
2021-03-10Fix #8711: having gui_zoom lower than zoom_min causes crashes (#8835)Patric Stout
gui_zoom was never clamp'd between zoom_min/zoom_max. zoom_min controls how zoomed-in we load sprites. For a value of 1, no quad-sizes sprites are loaded. If gui_zoom would be 0, meaning it wants quad-sized sprites to display, it was printing random stuff to the screen, which could or could not result in crashes.
2021-03-10Codechange: Misleading function name for selecting refresh rate (#8836)sean
Co-authored-by: pnda <43609023+ThePNDA@users.noreply.github.com>
2021-03-09Codechange: only run InteractiveRandom() from the draw-thread (#8831)Patric Stout
Otherwise both the draw-thread and game-thread can do it both at the same time, which gives rather unwanted side-effects. Calling it from the draw-thread alone is sufficient, as we just want to create some unpredictable randomness for the player. The draw-thread is a lot more active (normally) than the game-thread, so it is the best place of the two to do this. Additionally, InteractiveRandom() mostly has to do with visuals that are client-side-only, so more related to drawing than to game.
2021-03-09Fix #8810: "aircraft out of fuel" news was looking in the wrong place (#8832)Patric Stout
v->tile for aircrafts is always zero when in the air. Only when it starts its landing (or take-off) patterns it becomes a sane value. So instead, base the news on the last x/y coordinates of the plane.
2021-03-09Update: Translations from eintstranslators
english (us): 18 changes by 2TallTyler korean: 17 changes by telk5093 german: 13 changes by danidoedel, 4 changes by Wuzzy2 finnish: 17 changes by hpiirai catalan: 17 changes by J0anJosep lithuanian: 33 changes by devbotas spanish: 17 changes by MontyMontana portuguese (brazilian): 20 changes by Greavez polish: 9 changes by yazalo
2021-03-09Codechange: remove special strings for language and resolutions (#8824)Patric Stout
As OpenTTD grew, we found other ways to do this, and we are no longer in need for a hack like this.
2021-03-09Fix: Scale PIP-padding the same as regular padding. (#8829)PeterN
2021-03-09Add: Display refresh rate game option (#8813)sean
2021-03-08Fix #8825: [OpenGL] Don't clear cursor cache from the game loop thread.Michael Lutz
2021-03-08Update: Translations from eintstranslators
lithuanian: 5 changes by devbotas portuguese (brazilian): 8 changes by Greavez
2021-03-08Fix: ensure switching blitter happens in the main threadPatric Stout
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.
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-08Codechange: don't set the window position when changing blitterMichael Lutz
There really is no need to make an extra call to the OS in these cases.
2021-03-08Codechange: remove the unused lock around BlitterPatric Stout
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-08Add: Buttons to open global goals from company goals and vice versadP
2021-03-08Change: Don't show global goals in company goal windowsdP
2021-03-08Fix #8817: keep NewGRF order for object class sorting (#8818)Didac Perez Parera
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-03-08Change: Clarify what effect town interactions have (#8744)Eddi-z
2021-03-08Fix #8808: [OSX, OpenGL] Crash on switching blitters due to double-mapping ↵Michael Lutz
the video buffer.
2021-03-08Fix 937d60f2: Broken company colours for 40bpp-blitter. (#8821)Michael Lutz
2021-03-08Add: Option to (dis-)allow accelerated video drivers. (#8819)Patric Stout
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>
2021-03-08Add: filter for "engines only" in build train window (#8733)Didac Perez Parera
2021-03-07Update: Translations from eintstranslators
estonian: 6 changes by siimsoni catalan: 3 changes by J0anJosep latvian: 37 changes by lexuslatvia portuguese (brazilian): 8 changes by Greavez polish: 1 change by azabost
2021-03-07Fix #8809: Crash when removing airport when hangar window openJonathan G Rennison