| Age | Commit message (Collapse) | Author |
|---|
|
|
|
One also looks for a company, the other doesn't. There were more
uses of the latter than the first, leaving very weird code all
over the place.
|
|
The idea back in the days was nice, but it never resulted in
anything useful. Most servers either read "(loaded game)" or
"Random Map", neither being useful. It was meant for heightmaps,
so you could find a server that was using a specific one .. but
there are many things wrong with that idea. Mostly, servers tend
to save and load savegames from time to time, after which the
original heightmap used was lost.
All in all, removing map_name all together is just better.
|
|
from the console (#9022)
|
|
An invalid starting year causes all sorts of weird behaviour and crashes in map generation.
Now just set the appropriate setting via IConsoleSetSetting so the validation
and, if needed, clamping is performed on the starting year value.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
The current "restart" command is now called "reload", as that is
what it does.
The old "restart" command is now called "restart", as that is what
it did.
As this has not been in any official release yet, this shouldn't
harm any kitten.
|
|
In the sequence:
- Load a game
- Start a newgame (via console)
- Restart a game (via console)
Gave you the loaded game back, not the new game.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Check if the job is still running two date fract ticks before it is due
to join, and if so pause the game until its done.
When loading a game, check if the game would block immediately due to
a job which is scheduled to be joined within two date fract ticks,
and if so pause the game until its done.
This avoids the main thread being blocked on a thread join, which appears
to the user as if the game is unresponsive, as the UI does not repaint
and cannot be interacted with.
Show if pause is due to link graph job in status bar, update network
messages.
This does not apply for network clients.
|
|
Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.
Co-authored-by: milek7 <me@milek7.pl>
|
|
|
|
Formally it was only done on exit. This means that if it crashes
changes in settings were not stored. This is often rather
frustrating. Additionally, targets (like emscripten) where people
are unlike to use "Exit Game", will never see their configuration
stored.
The drawback is that on every setting change there is some minor
I/O of writing the ini file to disk again.
|
|
If I explicitly tell the system I do not want sound, I still get
presented a nice message I do not have any BaseSounds available
on my system, and that I should download one to enjoy sound. Well,
let me tell you, with "-snull" that is really really not going to
help. So please, be quiet, and let me enjoy the game without
"boooooo" and "DING DING DING".
Thank you.
|
|
When the restart command is issued, a normal map is always spawned.
This improvement takes into account the current state of _file_to_saveload to check if a savegame/scenario/heightmap was previously loaded, and loads the same resource again.
|
|
automatic destruction to simplify control flow in openttd_main.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of an AutoFreeSmallVector.
|
|
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.
|
|
|
|
std::vector::[push|emplace]_back()
|
|
|
