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.
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.
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.
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.
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.
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
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 :(
Microsoft Visual C++ 2015 Update 3 (and possibly other versions) consider a struct member undefined in a
static_assert in the struct body. Moving the static_assert to a member function solves the issue.
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.
Rewrite of almost the entire music control logic to a more modern style, hopefully also easier to understand. The old playlist handling made it look like arcane magic, which it doesn't have to be.
- Playlists are now stored in std::vector of objects instead of arrays of bytes with magic sentinel values, that need to be rotated around all the time. Position in playlist is stored as a simple index.
- The theme song is now reserved for the title screen, it doesn't play on any of the standard playlists, but is still available for use on custom playlists.
- When the player enters/leaves the game from the main menu, the music always restarts.
- Playback state (playing or not) is kept even if music becomes unavailable due to an empty playlist (or an empty music set), so it can restart immediately if music becomes available again.
- The shuffle algorithm was changed to a standard Fisher-Yates.
- Possibly better behavior when editing a custom playlist while it's playing.
- Custom playlists should be compatible.
- Framework for supporting custom playlists with songs from multiple music sets.
-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.
For example with GCC 4.8, x86_64 Linux, Intel i5-3337U this patch improves the performance of Pile, Treham and Hamac test save games by about 10% in over-all run time at fast forward at 1920x1080 when zoomed out and when trees are not disabled.
Patric Stout