OpenLoco v26.01 is out! Last month we finally finished making the game binary standalone; this means we now enter a bit of a refactoring and general code cleanup phase.
Over the next few months, the refactoring will be aimed towards getting ready for a new save format (NSF). For the NSF, we will be aiming to increase the map size limits, and generally most other limits. It is not a simple task of just changing some constants though, so don’t expect this to be completed for a while. Related to the NSF, we will also be looking at introducing a new object format (NOF). The NOF will allow removing limitations of the DAT format and will hopefully be more human readable. Much like the NSF, this will take quite some time to fully decide how it will work.
Even when we move to a NSF and NOF, we will still maintain support for the old formats in various ways, so don’t worry about losing your favourite custom objects.
Other areas for improvement are path finding. I suspect that we won’t be able to improve the land path finding just yet, without an NSF, but the water path finding should be achievable. If you have knowledge on pathfinding algorithms, it would be great to hear from you.
OpenLoco
Parallel drawing
@ZehMatt added parallel drawing support to OpenLoco (#2825). For the first time, having a multi-core CPU will actually improve performance in OpenLoco! The way drawing works in OpenLoco is that the window is split up into columns of 32 pixels wide (the width of a tile). Each column is drawn independently of the others. This is trivially parallelisable and @ZehMatt really showed this as the number of lines of code required to add parallel drawing was just 28!
However, keep in mind that drawing is not always the bottleneck of OpenLoco. Just running the simulation can be very CPU intensive, and that is not something we can easily parallelise at this time.
Related to this change, @lapingvino on Discord mentioned this change caused dependency issues on
his system. I might have been a little dismissive of the issue at first as we were only using the
C++ standard library parallelism features, but after looking into it properly it did turn out that
GCC’s libstdc++ depends on Intel TBB for parallelism. So if you are using libstdc++ you now need to
remember to have TBB if you want parallel drawing to work
(#3608).
Unfortunately, GCC will silently remove the parallelism if TBB is not found so we didn’t catch this
on any of our CI systems as they only have the minimum of required dependencies installed.
Name unknown flags and variables
@Cgettys, myself, @shusaura85 all worked on identifying various flags, variables and other unknowns in the codebase (#3512, #3615, #3571, #3600, #3550). Ideally, we would like to have all save file and object file related data identified before embarking on the NSF and NOF work. It’s not terribly exciting work, but I personally quite enjoy finally assigning a name to something and understanding how it affects the simulation.
Various refactoring and bugs
@AaronVanGeffen, myself, @ethan-xd, @ZehMatt, @LeeSpork, @LeftOfZen, all worked on various minor refactoring and minor bugs. Checkout the changelog for details on the bugs.
OpenGraphics
We made a mistake last month and accidentally didn’t include all of the OpenGraphics objects that had been created. We have corrected the issue and you should now see all of the objects released last month.
Onto the fun stuff; this months was the most productive month yet! Contributions have been organised by creator below.
@phosporus551
@phosporus551 had an insane 37 contributions this month:
28 OpenGraphics recreations:
7 branch new narrow-gauge trains (that don’t replace a vanilla object). These fill a gameplay gap in the mid tier for narrow-gauge trains. Whilst wider game balance for vehicles still has to be discussed in more detail, these certainly go a long way to bridging the underpowered nature of the vanilla narrow-gague vehicle selection.
2 revisions on existing OpenGraphics objects:
@shussaura85
@shussaura85 fixed a vanilla compatiblity issue with level crossings not being able to be placed on the existing OG_ROADRGH, as well as added OG_BRDGGIRD:
@glenjimen
@glenjimen contributed OG_COAL1:
