b400255dae
* build: doctest 2.4.11 in ref/
Single header test framework (MIT), vendored like the other libraries in
ref/ so the tests need nothing extra installed on the CI runners.
* refactor(physics): read vehicle definitions from text as well as files
TMoverParameters::LoadFIZ(path) opens the file and hands the parser over
to LoadFIZ_Parse(), which holds what LoadFIZ() did with it before. The
new LoadFIZ_Text() reads the same format from a string, so a definition
can be made up in memory, e.g. by a unit test. No change in behaviour for
files.
* build: the simulation core as a library the game links
The vehicle physics (McZapkie), the vehicle definition parser and the
helpers they use build as eu07_core, a static library the game links,
so the unit tests to come can link the very same objects instead of
compiling their own copy with their own settings.
The game's build settings (include dirs, definitions, compile options,
libraries) move from the executable to eu07_settings, an interface
target the library links publicly, so the game, the library and later
the tests all build with the same ones. What only the executable needs
stays with it: /MAP, /LARGEADDRESSAWARE, output dirs, the precompiled
header, runtime DLL copying, the crash reporter and the experimental
renderer. No change in what the game builds or links.
* test: unit tests of the simulation core, run as part of the build
eu07_unit_tests: C++ tests (doctest) of the simulation, which set up the
conditions, run the code and check the outcome. No game data, no window.
- the code under test is the core library (eu07_core), the very objects
the game links, built with the game's settings; engine_stubs.cpp stands
in for the logs, settings and scenery layers the library reaches for.
python gets linked with the settings but isn't needed to run the tests
- test vehicles are JSON definitions in tests/unit/data, with the sections
and keys of the game's vehicle definitions (tables as "rows", _keys are
comments), changed by the tests where needed and loaded from memory by
the game's own loader; an unknown section is an error rather than
silently skipped
- test::vehicle creates the mover the way TDynamicObject::Init() does and
steps it the way the simulation loop does, on a straight track of given
friction and gradient, optionally holding the brake pipe pressure the
way a coupled locomotive would
- the random numbers of the simulation are reseeded before every test
case, so a test gives the same result alone (IDE) or among the others
- building the game runs the tests at the end, once the game is linked,
and prints a one line summary ("Unit tests: 11/11 passed (80 checks)").
A failure prints the full report and fails the build, in CI and locally
alike, and removes the game binary so the next build reruns them. A
change of the tests alone relinks the game so they run (Ninja and
Makefile generators). -DWITH_TESTS=OFF leaves them out
- first tests: definitions reach the vehicle, KE service application and
release, deeper reduction brakes harder, every implemented distributor
valve charges/applies/releases, service braking stops a moving wagon
* test: stub basic_node::radius_() for GCC and Clang
The Linux build failed to link the unit tests: undefined reference to
scene::basic_node::radius_() from basic_node's vtable in engine_stubs.o.
basic_node has no key function for the Itanium C++ ABI (tooltip() is
declared plain but defined inline in the header), so GCC and Clang emit
its vtable in every unit using scenenode.h, and the vtable needs
radius_(), defined in scenenode.cpp, which the tests don't link. MSVC
emits vtables differently, so the Windows build linked.
* test: test vehicle definitions load with GCC and Clang
All the tests reading a definition failed on Linux with "unknown vehicle
definition section 0": the parsed definition was brace-initialised
(auto const json{parse(...)}), which GCC and Clang take for the
initializer list constructor of nlohmann::json, making an array holding
the definition, while MSVC copies it. Initialise it with =, and require
the definition to be a JSON object.
* test: SonarCloud issues of the unit tests
- test::definition_error for unusable test vehicle definitions instead of
std::runtime_error (S112)
- the rows of a table section written by a function of their own, less
nesting in definition::text() (S134)
- std::less<> for the section table (S6045)
- comments in the empty methods of the reseeding listener and stub (S1186)
- NOSONAR where the engine's headers fix the stubs: the extern globals
and the member function signatures (S5421, S5817, S1238)
- NOSONAR on LoadFIZ_Parse(): the cognitive complexity is the former body
of LoadFIZ(), moved as it was (S3776)
- a comment Sonar took for code reworded (S125)
MaSzyna - Railway vehicle simulator
Website · Report an issue · Community Discord · MaSzyna on Steam · MaSzyna on Epic Games Store
MaSzyna executable source code is licensed under the MPL 2.0 and comes with a large pack of free assets under a custom license.
Table of Contents
Getting Started
MaSzyna compiles and runs natively on Linux and Windows. Other platforms are not tested.
Heads-up
Our dev team is small; we keep improving the build process, but issues may still occur. If you get stuck, please ask on the official Discord server.
Prerequisites
For runtime requirements see Minimum Requirements.
1) Software (oldest tested in parentheses)
Note: MinGW is currently not supported.
2) Libraries (oldest tested in parentheses)
-
GLFW 3.x (3.2.1)
If a link error occurs, pass-DGLFW3_LIBRARIES="<path>"to CMake. -
GLM (0.9.9.0)
-
libserialport (0.1.1)
-
libsndfile (1.0.28)
-
LuaJIT (2.0.5)
-
GLEW (2.1.0)
-
libpng (1.6.34)
-
OpenAL (1.18.2)
-
pthread
-
Python 3.14 (64-bit; headers and import library required for embedding)
-
Asio (1.12)
3) Graphics API
- OpenGL 3.0 or newer
- DirectX 12 via NVRHI (optional, Windows only, for Better Renderer)
CMake flags
| Flag | Meaning |
|---|---|
-DCMAKE_BUILD_TYPE=Debug |
Debug build |
-DCMAKE_BUILD_TYPE=Release |
Release build |
-DCMAKE_BUILD_TYPE=RelWithDebInfo |
Release build with debug symbols |
-DWITH_BETTER_RENDERER=ON/OFF |
Enable/disable NVRHI-based renderer |
-DPython3_ROOT_DIR=<path> |
Root of the Python 3.14 install on Windows (python.exe, Lib, DLLs) for embed/copy steps; on Linux, optional if CMake picks the wrong interpreter |
Linux note:
WITH_BETTER_RENDERERuses DirectX 12 through NVRHI and is not supported on Linux.
Windows
Install Python 3.14 x64 from python.org and include the optional Python native development feature (headers and .lib for embedding). Pass -DPython3_ROOT_DIR="C:\Path\To\Python314" on the cmake line when you want the layout under that directory used for embedding and for copying Lib / DLLs next to the executable.
AppVeyor CI builds with the worker image’s preinstalled Python at C:/Python314-x64 (see appveyor.yml: -DPython3_ROOT_DIR=...).
# Clone repository with submodules
git clone --recursive https://github.com/MaSzyna-EU07/maszyna.git
cd maszyna
# Init vcpkg
call setup.bat
# Create directory for CMake build files
mkdir build
cd build
# Generate CMake project (replace %CONFIG% with Debug/Release/RelWithDebInfo)
cmake .. -G "Visual Studio 17 2022" -A x64 -DCMAKE_BUILD_TYPE=%CONFIG%
# Build (replace %CONFIG% accordingly)
cmake --build . --config %CONFIG% --parallel
Linux
# Install dependencies (Fedora/RHEL family)
sudo dnf install -y \
@development-tools \
cmake \
mesa-libGL-devel \
glew-devel \
glfw-devel \
python3.14-devel \
libpng-devel \
openal-soft-devel \
luajit-devel \
libserialport-devel \
libsndfile-devel \
gcc \
g++ \
wayland-devel \
wayland-protocols-devel \
libxkbcommon-devel
# Clone repository with submodules
git clone --recursive https://github.com/MaSzyna-EU07/maszyna.git
cd maszyna
# Create directory for CMake build files
mkdir build
cd build
# Generate Makefiles (NVRHI is not supported on Linux)
cmake .. -DWITH_BETTER_RENDERER=OFF
# Compile using all cores
make -j"$(nproc)"
Tip (Ubuntu/Debian): Package names differ; install equivalent
build-essential,libgl1-mesa-dev,libglew-dev,libglfw3-dev,python3.14-dev,libpng-dev,libopenal-dev,libluajit-5.1-dev,libserialport-dev,libsndfile1-dev, and Wayland/X11 dev packages as needed.
Installing
There is no make install yet. Copy the built executable to your MaSzyna installation manually.
-
Output directory:
./bin -
File name format:
eu07_YYYY-MM-DD_<commit>[_d]-
YYYY-MM-DD– build date -
<commit>– short commit hash -
_d– present in Debug builds
-
If you already have the MaSzyna assets, copy the executable to the install dir. Assets can be downloaded from eu07.pl.
Rainsted on Linux
If Rainsted (a third‑party starter) fails to detect the executable under Linux, you can create a small wrapper script named eu07.exe:
#!/bin/sh
./eu07 "$1" "$2" "$3" "$4" "$5"
If detection still fails, padding the file (with comments) up to ~1 MB may help.
Known Issues
-
GLFW linking – On some systems you must provide the GLFW library path explicitly with
-DGLFW3_LIBRARIES. -
X11/Wayland linking order – Linking order of X11 and related libs can matter.
-
NVRHI on Linux – The NVRHI/"Better Renderer" path targets DirectX 12 and is currently unsupported on Linux.
Support
-
Official Discord Server: https://discord.gg/qAh9ctWPQv
-
Project page: https://eu07.pl/
Minimum requirements
- OS: Windows 10 64-bit
- Processor: 2 core at least 2 GHz (e.g. Intel Core i3-2100 / AMD Athlon II X2)
- RAM: 6 GB RAM
- Graphics Card: supporting OpenGL 3.3 with at least 1GB VRAM
- 150 GB of free disk space
- Sound card supporting OpenAL with stereo
- Optional COM ports for custom control panel setups.
License
-
Source code: MPL 2.0
-
Assets: Custom license