OpenLoco v25.12 is out! This release marks a major milestone for the project. We completed the C++ reimplemention in v25.09 a few months ago, but were still dependent on vanilla memory space. This month, we celebrate the complete reworking of the memory space as well.
In short, this means the game can now be compiled natively for all platforms. This makes this month’s release available in 64-bits architecture for Windows, Linux, and macOS. You can expect builds to be faster, and much easier to port to new operating systems. Of course, we are extremely happy with this result, and what this means for future possibilities.
In this blog post, we’ll look back on how the memory space was reworked, as well as some quality-of-life changes that were merged this month, and the progress the OpenGraphics project has seen. Let’s get going.
Big loco_global integration extravaganza
Until this month, we still mirrored the vanilla game’s approached to memory space in most places.
As often talked about in previous blogs, this was done with loco_global instances.
Last month, we reported on the progress of reworking this, going from
342 loco_globals in the v25.10 release to just 157 in v25.11…
Remarkably, this month takes us down to 0 loco_globals — yes, zero!
It was a massive team effort, but it’s paid off massively, making 64-bit builds finally possible.
We usually list PR numbers in our dev log sections, however there were 46 PRs just for
loco_global removal this month! If you’re curious to see what such PRs look like,
you can find them on GitHub. Follow
this link
for a list of the relevant PRs.
To illustrate the growth and removal of loco_global instances from the project’s inception to now,
please take a look at the graph below. As more of the game became reimplemented, more memory had to be
shared between vanilla functions and our C++ functions, thus increasing the number of loco_globals.
Only once all vanilla systems had been reimplemented could the relevant memory be fully integrated.
Clearly, the last few months saw the final stretches of this effort.
Larger windows and new window styles
Compared to other Chris Sawyer games, Locomotion stands out due to its relatively sober window decorations. In fact, the ‘gradient’ look that characterises them is drawn using just one big sprite! For this reason, window sizes were limited to a width of 800 pixels — that’s all the sprite afforded!
Of course, nowadays, we have screens that are quite a bit bigger, so we frequently got requests for windows to be made larger. Well, here we are! Certain windows, e.g. the vehicle list and map window, can now be resized up to 2000x2000 pixels — much wider than was possible in the original game.
While we were working on this, Aaron had fun playing with introducing some new variants of the default window frame style. The gradient can now be disabled, resulting in a solid background colour. Moreover, the frame background can now be made translucent, resulting in a neat effect that we just had to include. Have a look at the gallery below for some examples.
More resizeable windows
Some players have amassed thousands of objects. Even with the filters OpenLoco introduced, from time to time we received requests to expand the object selection window. With larger windows now being possible, we’ve opted to make the object selection window resizeable. The default dimensions haven’t changed, but you can now resize it (#3405) to be a whopping 2000x2000 pixels, for all your extreme object listing needs.
It was brought to our attention that the vehicle list was quite glitchy when made smaller than its default size. We seized the opportunity to rework its resize routines, capitalising on the increased window limits as well. You can now resize it (#3531) to be quite a bit taller indeed!
Finally, the music selection window has been reworked by @LeeSpork. The window now lists the years music applies to, and allows you to order the list by name or year. This is made even more useful by allowing you to resize the window! We hope this increases your playlist customisation prowess quite a bit (#3384).
Doubling down on CMake
Over the past few years, we’ve continued to rely on CMake to tie our toolchain together. While initially we were dabbling with Visual Studio solution files for Windows, and several CMake files for Linux and even macOS, @Duncanspumpkin unified these to work on all platforms, and we’re now reaping even more the fruits of this labour. Since we had to rework our CMake toolchain again to make 64-bit builds possible, we took the opportunity to drop a bunch of now-unnecessary things in the process. Let’s take them one at a time.
Interop removal
First off, no longer needing to interop with the vanilla game has allowed us to remove a fair bit of code (#3491). This moment has been highly anticipated, and @Duncanspumpkin was all to eager to get it done.
CMake presets
While CMake has been the go-to tool to build OpenLoco for a while, it could be a little confusing to get it to build so-called cross-platform builds, in this case building 32-bit software on a 64-bit system. Now that this is no longer necessary, CMake presets could be simplified quite a bit (#3523). The project readme was adjusted accordingly. Whether you’re on Windows, Linux, macOS, or even BSD, it should be super easy to set up the compiler toolchain now.
Linux builds
For our continous integration (CI) build platform, we generally rely on vcpkg to build libraries we depend on, e.g. the SDL2 hardware abstraction layer. While Linux distributions tend to have their own package manager, you can opt-in to using vcpkg if the system packages are not up-to-date enough. All this to say, our ‘vcpkg’ Linux preset has now been updated to use x64 (#3494) as well.
macOS builds
The return of macOS builds is something that part of the team has been eagerly anticipating.
Even when the codebase wasn’t entirely ready, Aaron started to hack away at getting
native 64-bit builds (#3288)
for this platform. Much of the work tied in with the loco_global rework, and was ultimately split off
into their own PRs to ease the review process.
Duncan created a CI job for macOS (#3499)
as well, so we now have regular macOS builds on GitHub again!
Header checks
Finally, @ZehMatt did quite a bit of house cleaning (#3532),
modernising parts of the CMakeLists files that were a bit neglected, and reworking the header checks.
These checks are quite important, as they ensure we don’t have any implicit dependencies
between headers. This allows us to keep headers small while not getting surprised when using them.
OpenGraphics
This month we had 11 vehicle contributions from @glenjimen and a bridge contribution from @shussaura85!
Vehicles
Bridges
Happy Holidays!
Thank you for supporting OpenLoco over the years! We’re very happy with the milestones we’ve reached this year, both on a code and at a community level. With the end of 2025 in sight, we wish you all happy holidays!
Thanks to @Glenjimen for this little diorama!