Repository navigation
How Matching Works
A matched function compiles to the same bytes as the corresponding function in the original executable. An equivalent function has the same behavior but different generated machine code. Both represent recovered implementations; matching is the stricter goal used for byte-level reconstruction.
For a unit, contributors compile its source with the designated compiler and flags, then compare each function's emitted bytes with the original executable bytes. The unit's address ranges identify which executable functions are checked. The project gates report whether each function is matched or functional and also check related class vtables and DLL linking.
Names such as FUN_141234567 and DAT_143012345 encode an executable address when a meaningful original name has not been recovered. FUN_<va> denotes a function and DAT_<va> a data symbol; <va> is the address in hexadecimal. Unk_* names mark types or members whose semantic names or full layouts remain unknown. Replace placeholders with typed, behavior-equivalent C++ as evidence becomes available, while preserving the relevant ABI and layout.
An alias is a linker /alternatename line that maps a placeholder declaration onto the real function or data symbol. It is needed when a unit calls a function through a stand-in name, for example a free FUN_<va> declaration or a member of an Unk_* view, while the definition lives in another unit under its real name. The alias makes both names resolve to the same code, so the call compiles and matches before the declarations are cleaned up. Removing an alias means rewriting the caller to use the real declaration (the same callee with the same arguments, so the code does not change). Fewer aliases means the source reads like the original and builds without generated linker glue.
The game code targets MSVC 14.16: Visual Studio 2017 version 15.9, compiler cl 19.16.27054. Exact compiler and header versions matter because small toolchain changes can alter code generation. The build guide and contributor guide document toolchain checks and setup.
Some prebuilt middleware sections were built with older compilers. For example, CRI Movie code uses VC9 (cl 15.00, Visual Studio 2008 SP1); some Scaleform Video add-on code uses VC11 (cl 17.00, Visual Studio 2012 Update 4). These sections use their corresponding compiler configuration for byte matching. Other Scaleform code uses the main MSVC 14.16 toolchain.