Skip to content

Releases: characterecho-sean/edvr-exposure-fix

EDVR 0.2.0 - survives game updates

Choose a tag to compare

@characterecho-sean characterecho-sean released this 08 Aug 22:07

Elite computes auto-exposure separately for each eye. Near a bright source —
a star, a station floodlight — one eye can see it and the other cannot, so one
stops down and darkens while the other stays bright. EDVR makes both eyes use
one exposure result.

Measured on a held view at a star: the eyes' background brightness differed by
about 1.5 stops without the fix and about 0.4 with it. What remains is
the glow around the star in the eye that can actually see it, which is correct.

Install

Unzip, copy d3d11.dll and edvr.ini next to EliteDangerous64.exe (normally
%LOCALAPPDATA%\Frontier_Developments\Products\elite-dangerous-odyssey-64),
start the game. Press Scroll Lock in game to toggle it.

Uninstall by deleting those two files.

What's new in 0.2.0

It no longer breaks on game updates by definition. 0.1.x pinned the target
by its shader bytecode hash, which identifies one compiled shader and changes
whenever Frontier rebuilds their shaders — so every update would have needed
somebody to re-derive it. The fix now finds the pass by what it does: a
compute dispatch that writes a small buffer of exposure state and a tiny
parameter strip, and that runs exactly twice per frame, once per eye. Both
halves must hold for five consecutive frames before it touches anything.

If the shape ever stops matching, the fix does nothing, the game stays stock,
and the log says so. If it ever matches the wrong pass, it still checks that the
two resources are the same kind and size before copying, and the log names the
shader it settled on so you can pin it in edvr.ini.

Scroll Lock works. Making detection the default had silently disabled the
toggle — it required a pinned hash, and a stock install no longer has one.

The log is plain text. Open it in Notepad and paste the whole thing; no
decoder. It records your game build, which shader the fix settled on, whether it
engaged — and now says so explicitly when detection finds nothing, which the
previous build reported as silence indistinguishable from never launching VR.

Verification

edvr-0.2.0.zip — SHA-256:

86316EBF6DB9FFD3C4A8CE642DC85CF1FA902D8662BFBC4810066B0FD52B2C3D

Check it with Get-FileHash edvr-0.2.0.zip in PowerShell.

The archive holds exactly four files: d3d11.dll, edvr.ini, README.txt,
LICENSE.txt. The DLL is built from this tag by build.bat; a DLL that sits
next to a game executable and intercepts graphics calls looks structurally like
something worth flagging, and some scanners will flag it, so the source is here
to read and to build yourself.

Scope

It does not modify, patch or write to the game's memory or any game file, does
not touch the network or anything the server sees, does not read or change
gameplay state, and does not interact with anti-cheat. It loads as a d3d11.dll
proxy, forwards every call to Windows' real d3d11.dll, and issues one extra
Direct3D copy per frame.

Developed against game build 330683 (4.4.0.3). A different build is expected
rather than a problem.

Frontier's launcher may remove d3d11.dll when it verifies the install. That is
not a fault — it has simply uninstalled EDVR. Copy the file back.

Not affiliated with, endorsed by, or supported by Frontier Developments plc or
Valve Corporation. If Frontier asks for this to come down, it comes down.