What's new in 1.9.5
Performance: more of the game runs as native code
The game's own code runs faster. The translated game code kept the Xbox processor's registers in memory and wrote every change back. Its floating-point and integer registers now stay in the PC processor's registers inside each function. Every changed function was run against its old version from the same starting state, and gave the same results.
The busiest Direct3D library functions are written in C. The game's draw calls, the vertex setup before each draw and its shader constants are now hand-written code instead of translated Xbox code. They send the graphics chip exactly the same commands, checked call by call over millions of draws, at about half the cost.
The controller is read directly. The game no longer goes through an imitation of the Xbox's USB chip to read the controller; it asks the PC's own input (controller, keyboard, mouse and your bindings).
The render thread does less per draw. Draws with nothing changed between them are sent to the graphics card as one. Vertex data and commands are copied with faster copy routines, and graphics state lookups are quicker.
Lighter frames. Busy gameplay ran at about 450 fps on average on a fast PC in testing (Windows, Direct3D 11), with the game's code down to about 1.7 ms a frame. Earlier test logs showed over 3.5 ms in busy scenes.
Fewer draw calls. Draws that differ only in their vertex constants are sent to the graphics card as one draw; the constants travel with the vertices.
Linux gets the render thread too (OpenGL), and the game no longer spins a core while it waits for the graphics card.
High frame rates
Animations keep their speed. Each frame an animated character moved on by whole milliseconds of (frame time x animation speed), the rest dropped. At 500 fps animations playing below full speed kept about half their time or less: slow attacks, cutscene animations that stopped short, and heads that did not turn toward what a character looks at. The fractions are now kept and added up.
Falling keeps its speed. A falling character's speed grew once per frame, so at high frame rates anything that jumped or stepped off a ledge fell many times too fast and landed deep in the ground. It now grows with time, exactly as at 30 fps.
Small moves are kept. Movement under 0.01 units a frame was dropped, which above about 300 fps was most of it (characters stood still or caught on the ground). The threshold now shrinks with the frame time.
Unlocked: frames at least a millisecond apart. After a late frame the next few could come through back to back, under a millisecond apart, which the game's clock could not keep straight (the Westfold intro's run played slowly). Unlocked now means up to 1000 frames a second, each given its proper time.
Sound
No more cut-outs or crackling audio. Whenever the game updated its sounds, the emulated sound chip skipped that slice of audio: 3-10% of all sound came out as silence in short slices, and sounds seemed to stop part way, more the higher the frame rate. The sound now plays on, and the game's sound commands are applied between slices.
Volume changes glide across each slice instead of stepping.
Tested (1.9.5)
On Windows by the author: gameplay in busy scenes at unlocked frame rates (Westfold and others), with profiles of each change; the F10 menu fix; animation speed, the prologue and sound at up to 1000 fps.
On Linux at fixed frame times (33, 8, 2, 1 and 0.7 ms): animation time, falls and landings, and the world clock measured against 30 fps; sound lengths and gaps measured at 30 fps and unlocked.
Under Wine (Direct3D 11): levels load and play, fights render correctly.
On Linux: gameplay renders correctly; the native Direct3D functions checked against the translated ones call by call (14.7 million calls); every function changed by the register work compared old against new (8,348 identical, none different).
Windows, Linux and macOS builds compile.
Not tested by hand: the macOS build on a Mac.