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

33
docs/re/structures/ui-render-tone-curve.md
View File

@@ -93,11 +93,31 @@ captured frame is a ramp **the game installed**.
✅ The stated confound is gone: the measured exponent is not an emulator artefact
bolted onto the game's output.
🟡 **Not established: that this game installs a ramp at all**, or that
γ ≈ 1.34–1.49 *is* that ramp. The run logs cannot say — kernel exports log at
Debug and this harness masks Kernel logging (`log_mask = 13`, per
`boot_menu.sh`'s own comment), so the absence of gamma lines in them is expected
and means nothing. That is the reach of this negative.
✅ **The game DOES query the display gamma — measured 2026-08-29.** Booted with
`--log_mask=12 --log_level=3` (Kernel logging on, Cpu/Gpu off), which changes
nothing about the output. `VdGetCurrentDisplayGamma` is called **once at video
init**, between the command-buffer setup and `VdSetDisplayMode`:
```
d> F8000008 VdGetSystemCommandBuffer(701CF830, 701CF804)
d> F8000008 VdGetCurrentDisplayGamma(701CE1F8(00000000), 701CE1F0(0))
d> F8000008 VdSetDisplayMode(40000000)
d> F8000008 VdGetCurrentDisplayInformation(701CF110)
```
**The control is in the same log:** 359 `VdRetrainEDRAM` and 358
`VdGetSystemCommandBuffer` lines, so an absent call would have been visible.
Evidence in [`data/gamma-call-evidence.txt`](../data/gamma-call-evidence.txt).
Per the export's own comment the returned type is "used in D3D
SetGammaRamp/SetPWLGamma", so the game asks the question a ramp-builder asks, at
the moment one would ask it.
🟡 **Still not established: that it then WRITES the ramp**, or that γ ≈ 1.34–1.49
is that ramp. The write is a GPU register operation (`DC_LUT`), invisible to
kernel logging — this run had Gpu logging masked off, and individual register
writes are not logged in any case. A GPU trace records gamma ramps as a command
type (`TraceWriter::WriteGammaRamp`), which is the next place to look.
⚠️ And the ramp a game builds depends on the display type it is *told*. Canary
hard-codes `2` (TV/BT.709); on hardware that is the console's display setting. So
@@ -116,6 +136,9 @@ on an **absolute** rmse threshold and a brighter frame biases it (see
The right run changes nothing about the output: boot with `LOG_MASK=12
LOG_LEVEL=3` (both are needed — kernel calls log at Debug) and look for
`VdGetCurrentDisplayGamma` and the `DC_LUT` writes. Same frames, no perturbation.
✅ **Run, and it answered the first half** — see above. ⚠️ And note it needed the
emulator only to **boot**, not to reach a menu: video init happens in the first
seconds. This had been parked behind the title-screen blocker for no reason.
## What a port should do with this