fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re(ui): the game does query the display gamma -- measured, with its control

Browse Source 
Last iteration's corrected experiment, run. Boot with --log_mask=12
--log_level=3 (Kernel logging on, Cpu/Gpu off), which changes nothing
about the output and so cannot perturb the capture harness the way the
gamma-cvar experiment would have.

VdGetCurrentDisplayGamma is called once, at video init:

  d> VdGetSystemCommandBuffer(701CF830, 701CF804)
  d> VdGetCurrentDisplayGamma(701CE1F8(00000000), 701CE1F0(0))
  d> VdSetDisplayMode(40000000)
  d> VdGetCurrentDisplayInformation(701CF110)

The control is in the same log: 359 VdRetrainEDRAM and 358
VdGetSystemCommandBuffer lines, so an absent call would have been
visible. Per the export's own comment the returned type is "used in D3D
SetGammaRamp/SetPWLGamma" -- the game asks the question a ramp-builder
asks, at the moment one would ask it.

Still open, and stated: whether it then WRITES the ramp, and whether the
measured gamma 1.34-1.49 is that ramp. The write is a GPU register
operation (DC_LUT), invisible to kernel logging; a GPU trace records
gamma ramps as a command type (TraceWriter::WriteGammaRamp), which is
where to look next.

Worth its own METHOD line: this had been parked behind "needs the
emulator to reach a menu" for several iterations, and it needed the
emulator only to BOOT -- video init happens in the first seconds. A
blocker that stops one experiment does not stop every experiment in the
same area.
This commit is contained in:
Sylpheed RE agent
2026-08-29 02:51:32 +00:00
parent 93b0a6b20f
commit c6ce000002
4 changed files with 52 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/port/HANDOFF.md
View File

@@ -237,9 +237,14 @@ authored version can be deleted.
ramp from the `DC_LUT` registers in the swap path (`apply_gamma_table.ps` /
`apply_gamma_pwl.ps`). So there is no emulator post-process to subtract, and
any gamma in a capture is one the game installed.
🟡 Still not established: that this game installs a ramp at all, or that
γ ≈ 1.4 *is* it. The run logs cannot say — kernel exports log at Debug and the
harness masks Kernel logging — so that absence means nothing.
✅ **Measured 2026-08-29: the game DOES query the display gamma.** Booted with
Kernel logging on (`--log_mask=12 --log_level=3`, which changes nothing about
the output), `VdGetCurrentDisplayGamma` is called once at video init, between
`VdGetSystemCommandBuffer` and `VdSetDisplayMode` — the moment a ramp-builder
would ask. Control in the same log: 359 `VdRetrainEDRAM` lines, so an absent
call would have shown.
🟡 Still open: whether it then *writes* the ramp, and whether γ ≈ 1.4 is it.
That write is a GPU register operation (`DC_LUT`), invisible to kernel logs.
⚠️ Note the ramp depends on the display type the game is *told*; canary
hard-codes TV/BT.709, which on hardware is a console setting. **So this is a
display profile, not a fixed property of the game** — reasonable to expose as a