v0.3.0 - the campaign runs with memory above 4 GB

The campaign runs with memory above the 4 GB line

Crysis 2 x64 could already be played on this launcher. What it could not do was use memory above
4 GB without cutscenes quietly dying - and the reason turned out to be the launcher's own code,
not the engine.

The cutscene that would not start

With memory steered high, a level's opening cutscene would begin and then stand still. The
sequence was in the playing list, its length was read correctly, its speed was 1.0, and its clock
never advanced by a single frame. The scene never reported Done, so the level script waited
forever and the player stood there without a body. No crash, no log line, nothing to search for.

The guard that protects the movie update loop from corrupt entries rejected every pointer whose
high half was non-zero. That was a correct check when all of this game's memory sat below 4 GB.
Once the arenas move up, a sequence pointer of 0x2_1CF88110 is perfectly valid - and the guard
threw all of them away, skipping the line that advances the clock. It was built to silently drop
what it does not recognise, so it did exactly that, for every cutscene in the game.

Both guards now check what they actually mean: a pointer against the real user-mode range, and
module bounds read from the module's own PE header rather than hard-coded constants.

Measured as the distance the camera travels during the opening cutscene:

	Battery Park	FDR
before	0.004	-
after	4.816 / 4.766	5.875

Then a full campaign run: fourteen levels in a single process, 5.8 GB allocated above the
4 GB line, every cutscene playing.

The workaround this retires

A band of allocations between 14 and 16 MB used to be pinned below the line, because with it high
the game broke. It was never a cure. Keeping those allocations low simply kept sequence pointers
where the broken guard would accept them. The band now goes high with everything else, and the
workaround is off by default.

Also in this release

• A renderer crash on level transitions. Seen twice at the same instruction: a smart-pointer
  copy whose target was released when a level unloaded. Repaired on the fault rather than guarded
  on every call - a guard that decides wrongly is what caused the bug above. Disable with
  -norndfix.
• IStatObj::Invalidate takes two parameters, not one. The float tolerance was never passed,
  so whatever happened to be in a register decided whether a change counted as significant.
• Scripts no longer hard-code one machine's path. The game folder is found by looking for
  Bin64\CrySystem.dll and GameCrysis2 together - the Mod SDK matches the first on its own and
  would otherwise be picked instead. Pass -Game to override.
• play.ps1 keeps the previous session's logs before starting, so a crash is not erased by
  the run you start to check whether it crashes again.
• level_switch.ps1 exercises a transition inside one process, which is where the renderer
  crash lives - loading a level directly never reproduces it.

What a playthrough looks like

Honest list, from that fourteen-level run: a few props do not appear while still blocking you
(the AA-gun area on Bryant Park, parts of Prism2), some textures stay unloaded in the same places,
one monitor on Prism shows the wrong image, and one Screamer had no sound. None of it stops the
run. Details are in the README.

Install

Drop launcher64.exe into your Crysis 2 Bin64 folder and run it. Full instructions, including
what you need from the Mod SDK, are in the README.

v0.2.1 - says what is wrong

Follow-up to v0.2.0, which fixed the startup crash. This one is about what
happens when something is not where it should be.

The launcher now tells you what is wrong

Put launcher64.exe in the wrong folder, or run it without the Mod SDK
installed, and Windows used to say:

The code execution cannot proceed because CrySystem.dll was not found.
Try reinstalling the program.

Both halves of that are wrong. Reinstalling the launcher fixes nothing, and
the file it names is not part of Crysis 2 at all - it comes with the Mod SDK.
The launcher also stayed in the background until you dismissed the box.

Now the launcher answers instead: what was not found, the folder it looked
in, that the 64-bit engine ships with the free Mod SDK, and where the file
has to go. The same for a mismatched SDK, and for a failure during startup,
which now points at the two log files worth attaching to a report.

The readme answers "what do I download" first

A table of the three things you need, with a link to the Mod SDK, the folder
layout to check yours against, and a list of the messages the launcher can
show with what to do about each.

Install

You need Crysis 2 patched to 1.9 and the Crysis 2 Mod SDK installed into the
same folder - the Mod SDK is what puts the 64-bit engine into Bin64.

1. Download launcher64.exe below.
2. Put it in <game folder>\Bin64\, next to CrySystem.dll.
3. Run it.

Nothing is overwritten and no game file is modified. The original 32-bit
Crysis2.exe keeps working exactly as before.

Also

The build no longer generates an import library: the engine is resolved with
LoadLibrary at startup, which is what made the message above possible, and
it removes a step for anyone building from source.

Verified on this build: 3 of 3 clean starts to the menu, Times Square loaded
from the command line in 27.6 seconds, and the four failure paths checked by
running the launcher in an empty folder and reading the box it produced.

v0.2.0 - fixes the startup crash

Fixed: the crash on startup

If the launcher died on startup with

Failed CMTSafeHeap::m_pBigPool allocation

this release fixes it. Every earlier release contains the bug, so if you
downloaded v0.1.0 through v0.1.3, replace the file.

The cause was in the launcher, not in your game install. The launcher creates
the engine itself and then has to hand that engine to the game DLL. That
hand-off was missing, so the game brought up a second engine on top of the
first one, and the second one failed while allocating its memory pools.

Nothing about your setup was wrong. Disc version, Steam, repack, language,
missing DLC - none of it mattered, and none of the workarounds people tried
were needed.

Also fixed

• +map <level> on the command line now works. Our own console variables were
  being written after your arguments and overriding them; your arguments go
  last now.
• Starting a second copy by accident asks first. Two launchers writing the same
  log file made every crash report harder to read than it needed to be. Pass
  -allowmultiple if you actually want two.

New flags

These are diagnostics. You do not need them to play, but they are what found
this bug, and they will find the next one faster.

Flag	What it does
-traceallocs	logs large engine allocations and the addresses they got
-forcehighheap	forces the engine's memory above the 4 GB line, which makes pointer-truncation bugs reproducible on demand instead of by luck
-enginefix	corrects a 32-bit pointer store in retail CrySystem. Off by default: the store is real, but it is not what was breaking startup
-allowmultiple	skip the second-instance question

build.ps1 now finds the game by itself, and takes -GamePath if it guesses
wrong. test.ps1 runs the launcher a few times and reports whether the game
actually reached its menu.

Install

You need Crysis 2 patched to 1.9 and the Crysis 2 Mod SDK installed into the
same folder - the Mod SDK is what puts the 64-bit engine into Bin64.

1. Download launcher64.exe below.
2. Put it in <game folder>\Bin64\, next to CrySystem.dll.
3. Run it.

Nothing is overwritten and no game file is modified. The original 32-bit
Crysis2.exe keeps working exactly as before. To uninstall, delete the file.

If it still goes wrong

The launcher writes launcher_diag.txt into the game folder on every start.
Send that file, and Game.log next to it. With -traceallocs the log gets far
more detail about where memory went.

Verified on this build

25+ clean starts to the menu, all flags exercised, 10 minutes in a level and
8 minutes in a heavy one with flat memory use, window minimise and restore,
clean shutdown, and a build from a fresh clone of this repository.

v0.1.3 - allocator probe

Adds an allocator probe to the diagnostic report. No functional changes - the timer fix, borderless
mode, cursor handling and intro settings are identical to v0.1.1.

Why

Some systems fail during engine startup with:

Failed CMTSafeHeap::m_pBigPool allocation

The message means an internal pool allocation of at most 14 MB returned NULL, which can happen with
tens of gigabytes of memory free - the engine's own allocator is already in a bad state by the time
it asks. Verifying game files does not address it, and the same failure occurs with unrelated
launchers, so it is a property of the engine rather than of any one launcher.

What was added

CrySystem.dll is imported statically, so it is loaded and initialised before any launcher code
runs. That makes its allocator state readable before the engine has a chance to fail. The report
now records that state, and repeats the largest allocation the engine performs during startup
through msvcr90, the runtime the engine itself uses.

A healthy system reports:

bucket slab    : 0x0000000002570080 (below 4 GB, as expected)
crt malloc ptr : 0x00000000365A1230
msvcr90 14MB   : OK

A NULL slab means the engine's allocator never initialised. A failed 14 MB allocation means the
runtime cannot serve the request. The two cases have different causes, and the report now
distinguishes them.

Install

1. Download launcher64.exe below.
2. Place it in <game folder>\Bin64\, next to CrySystem.dll and Editor.exe.
3. Run it.

Requires Crysis 2 and the Crysis 2 Mod SDK, which provides the 64-bit engine DLLs. No game file is
modified; to uninstall, delete launcher64.exe.

Startup problems are best reported with launcher_diag.txt and Game.log from the game folder.
The diagnostic file is written before the engine starts, so it survives a startup crash.

v0.1.2 - environment diagnostics

Adds environment details to the diagnostic report. No functional changes - the timer fix, borderless
mode, cursor handling and intro settings are identical to v0.1.1.

What was added

launcher_diag.txt now also records:

• Install path. A Steam installation under Program Files behaves differently from one on a
  separate drive, and the engine writes several files into its own folder.
• Write access, determined by creating a file rather than by inspecting permissions. Permission
  checks can report access that does not exist in practice; an actual write cannot.
• Free disk space.
• System locale and ANSI codepage. Locale affects string handling in code written before
  locale-aware comparison was routine. Turkish is the standard example: i does not uppercase to
  I, so comparisons behave differently than their author assumed.

These are the parts of a system that hardware information does not cover and that cannot be
reproduced on a different machine.

Install

1. Download launcher64.exe below.
2. Place it in <game folder>\Bin64\, next to CrySystem.dll and Editor.exe.
3. Run it.

Requires Crysis 2 and the Crysis 2 Mod SDK, which provides the 64-bit engine DLLs. No game file is
modified; to uninstall, delete launcher64.exe.

v0.1.1 - fixes startup crash

Fixes a startup crash present in v0.1.0. Anyone on v0.1.0 should use this build instead.

The crash

v0.1.0 could abort during engine startup with:

CryEngine Fatal Error: Failed CMTSafeHeap::m_pBigPool allocation

The pools involved are between 32 KB and 14 MB, so available memory was never the issue.

The cause was two static imports added in v0.1.0 - WINMM and GDI32. The Windows loader resolves
static imports before any of the program's own code runs, pulling those libraries and their
dependencies in ahead of the CRT and shifting the process address space.

That matters here more than it would elsewhere. This launcher is built against the VC90 runtime
specifically so the process heap lands below the 4 GB line: retail CrySystem contains a bucket
allocator that stores slab addresses truncated to 32 bits, and above that line those pointers come
back corrupt. Once the layout shifted, allocation failed and the engine aborted.

The fix

Both libraries are now loaded at runtime, after the CRT is initialised. The DPI reading uses
GetDpiForSystem from USER32, which is already imported, so GDI32 is no longer needed at all.
The import list is back to what it was in the last known-good build.

Nothing else changed: the timer fix, borderless mode, cursor handling and intro settings are
unaffected.

Install

1. Download launcher64.exe below.
2. Place it in <game folder>\Bin64\, next to CrySystem.dll and Editor.exe.
3. Run it.

Requires Crysis 2 and the Crysis 2 Mod SDK, which provides the 64-bit engine DLLs. No game file is
modified; to uninstall, delete launcher64.exe.

v0.1.0 - first release

First public release.

Install

You need Crysis 2 (patched to 1.9 - the Maximum Edition already is) and the Crysis 2 Mod SDK.
The Mod SDK is what puts the 64-bit engine DLLs into the game's Bin64 folder; without it there is
nothing here to run.

1. Download launcher64.exe below.
2. Put it in <game folder>\Bin64\, next to CrySystem.dll and Editor.exe.
3. Run it.

No game file is modified and nothing is overwritten - the original 32-bit Crysis2.exe keeps working
exactly as before. To uninstall, delete launcher64.exe.

What this build fixes

The 64 FPS cap is gone. The cause was the Windows timer quantum, not the engine: the default
resolution is 15.625 ms, and 1000 / 15.625 = 64.0. The main thread waits on the physics barrier and
Windows rounds that wait up to a full quantum, so one frame cost one quantum. Nobody in the engine
ever raises the timer resolution. Expect 200-300 FPS where you had a hard 64.

If you have been using RivaTuner, an Nvidia frame cap, or Low Latency Mode to work around this,
you no longer need them - those worked by raising the timer resolution as a side effect.

Tearing, VSync input lag and Alt-Tab crashes are fixed together by running borderless windowed,
so presentation goes through the compositor. No tearing, no cap, no added latency, and no exclusive
device to lose when you switch away.

The invisible cursor is fixed. The game loads its cursor from the running executable's resources,
which a hand-built launcher had none of.

The debug overlay is off by default, along with the intro videos, which the x64 build cannot
decode and drew as white rectangles.

If something goes wrong

Every launch writes launcher_diag.txt into the game folder: your hardware, display mode, and the
size and date of every engine module and game pak. Attach it to a bug report and the cause is
usually obvious immediately.

Two flags exist if a fix misbehaves on your setup:

Flag	Effect
-noborderless	leave the window alone, use whatever mode the game picks
-keepintro	keep the intro videos and the debug overlay

Remaining known issues are listed in the README.

Bug reports and anything behaving strangely are very welcome.