RP412/BUILD.md

Building Red Planet 4.12 (Win32)

This is the Win32 source for the pod-racing game Red Planet, built on the in-house MUNGA engine and its L4 (Win32 / DirectX 9) platform layer. As of RP 4.12 the build targets Visual Studio 2022 (v143); the legacy VS 2005/2008 projects are retained for reference (see §5).

✅ Verified build (2026-07-12): all 4 projects build clean (Release|Win32) with VS2022 Build Tools 17.14 (MSVC 14.44, v143) + Windows 11 SDK (10.0.26100) + DirectX SDK (June 2010). Outputs: Release\rpl4opt.exe (the game), Release\RPL4TOOL.exe, lib\Munga_l4.lib, lib\DivLoader.lib. Runtime-verified against the VC9 baseline built from the same tree: identical log output and behavior at every checkpoint, including RIO init against vRIO and mission load (see §4 for the pre-existing crash both builds share).

---

1. Requirements

Component	Version	Notes
VS2022 Build Tools (or any VS2022 with C++ workload)	17.x, MSVC v143	Installed at C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools. Install via winget install Microsoft.VisualStudio.2022.BuildTools --override "--quiet --wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended".
Windows 10/11 SDK	any recent (26100 verified)	Comes with the VCTools workload.
DirectX SDK (June 2010)	—	Still needed for d3dx9 and dxerr only; everything else now comes from the Windows SDK. The projects reference it via $(DXSDK_DIR), which the SDK installer sets machine-wide. The DXSDK include/lib paths are appended after the Windows SDK paths (see the IncludePath/LibraryPath properties in the projects) so modern headers win — do not move them to AdditionalIncludeDirectories.

Bundled third-party libraries (already in the repo)

Committed under lib/, no install needed: OpenAL32.lib, libsndfile-1.lib (import libs). At run time the game needs OpenAL32.dll (system-wide install — assets/RP411/oalinst.exe — or beside the exe) and libsndfile-1.dll (beside the exe; a copy ships in assets/RP411/).

2. Building

& "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\MSBuild.exe" `
    WinTesla.sln /p:Configuration=Release /p:Platform=Win32 /m

Debug|Win32 also builds. x64 is not configured — this is a 32-bit build. The solution is WinTesla.sln with four v143 projects:

Project	Type	Output
MUNGA_L4/Munga_L4.vcxproj	Static lib	lib\Munga_l4.lib
RP_L4/RP_L4.vcxproj	App (Windows)	Release\rpl4opt.exe — the game
RP_L4/RPL4TOOL.vcxproj	App (Console)	Release\RPL4TOOL.exe
DivLoader/DivLoader.vcxproj	Static lib	lib\DivLoader.lib (Release)

Build order is resolved by ProjectReference (RP_L4 and RPL4TOOL both reference Munga_L4).

3. VS2022 migration notes (what changed and why)

Settings preserved from the VC9 projects: /Zp1 struct packing in Munga_L4 and RP_L4 (the engine's on-disk/on-wire binary formats depend on it — RPL4TOOL and DivLoader never had it), Unicode, subsystems, x86, /DYNAMICBASE:NO, optimization levels, and /FORCE:MULTIPLE (see below). Deliberate changes:

• CRT unified to /MD (Release) / /MDd (Debug). The VC9 build mixed /MT (Munga_L4, RPL4TOOL) with /MD (RP_L4) and forced the link.
• Import libs are no longer merged into Munga_L4.lib by the librarian; the exes link OpenAL32/d3d9/d3dx9/dinput8/dxguid/ws2_32 directly.
• WINDOWS_IGNORE_PACKING_MISMATCH is defined: the modern Windows SDK static_asserts against /Zp1; the VC9 build always compiled Windows headers at /Zp1, so this preserves those exact semantics. Un-/Zp1-ing the engine (pragma-pack only the serialized structs) is future work.
• _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS is defined: the code still uses stdext::hash_map; porting to std::unordered_map is future work.
• legacy_stdio_definitions.lib is linked: the June-2010 dxerr.lib references pre-UCRT stdio symbols.
• Source fixes (behavior-preserving): standard copy-ctor/assignment overloads added to Time (rvalues can't bind to volatile& in standard C++); operator==(SOCKADDR_IN&,...) in NETWORK.h made inline; the L4DINPUT callbacks renamed DIEnum* (they collided with L4CTRL's under LTCG); std::ios.in → std::ios::in in CAMMGR.cpp.
• /FORCE:MULTIPLE is still required: gOpNames, gReplacementData (hash_maps defined in a header) and GlobalEggFileName are genuinely defined in multiple TUs (LNK4006 warnings, same as the VC9 build). Moving them to a single TU is future cleanup.

4. Known runtime issue (pre-existing, both toolchains)

Standalone mission load (rpl4opt.exe -windowed -res 640 480 -egg TEST.EGG, run from a game working copy such as assets/RP411/) crashes with an access violation in d3d_OBJECT::LoadTexture (MUNGA_L4/L4D3D.cpp @ 262, called from LoadObject → DPLRenderer::MakeEntityRenderables) right after the Entity -1:10x class42 couldn't figure out how to MakeEntityRenderables log lines. The VC9 build of this tree crashes at the identical point, so this is a defect (or asset/config mismatch) in the 2007 DPL→D3D9 port, not a migration regression. The v143 build produces full PDBs — debug with cdb -g -G -lines -y Release rpl4opt.exe ... from the working directory.

Also note: Fail() compiles to abort() in release (MUNGA/DEBUGOFF.h) — e.g. running with L4CONTROLS=KEYBOARD alone aborts at VTV creation because no keyboard-only pod mapper exists (the old CRT showed a blocking R6010 dialog; the UCRT fail-fasts). Use L4CONTROLS=RIO;KEYBOARD with vRIO serving the RIO side, exactly like the arcade config.

5. Legacy VS2005/2008 build

The original .vcproj files and solution are kept as WinTesla_vc9.sln and still build with VC++ 2008 Express SP1 + DXSDK June 2010:

@echo off
call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
set "DXSDK_DIR=C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\"
vcbuild /nologo /rebuild WinTesla_vc9.sln "Release|Win32"

See docs/BUILD-NOTES.md for the original repository cleanup history and the findings behind the legacy build.