| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
the main thread.
|
|
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
|
|
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.
|
|
Example:
exec other.script
echo hello
The "echo" was never executed.
|
|
|
|
|
|
|
|
swedish: 22 changes by kustridaren
ukrainian: 4 changes by StepanIvasyn
lithuanian: 7 changes by devbotas
spanish: 312 changes by MontyMontana
|
|
|
|
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.
|
|
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
This prevents the window from "freezing" when you close it during
world generation, as it first would continue the action.
|
|
This prevents the window from "freezing" when you close it during
the scanning of NewGRFs, as it first would continue the action.
|
|
Otherwise the numbers are all over the place when a modal window
just closed.
|
|
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.
|
|
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.
|
|
Co-authored-by: pnda <43609023+ThePNDA@users.noreply.github.com>
|
|
|
|
|
|
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.
|
|
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.
|
|
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
|
|
As OpenTTD grew, we found other ways to do this, and we are no
longer in need for a hack like this.
|
|
|
|
|
|
|
|
|
|
lithuanian: 5 changes by devbotas
portuguese (brazilian): 8 changes by Greavez
|
|
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.
|
|
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.
|
|
There really is no need to make an extra call to the OS in
these cases.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Basically, the window was not invalidated, so it was never redrawn.
This made it look like it wasn't working, but it really was.
|
|
|
|
the video buffer.
|
|
|
|
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>
|
|
|
|
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
|
|
|
|
chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
|
