erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions

docs(issues): #458 — block test structurally identical to retail; next step is one exact block_check capture at the doorway pose

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-09-03 12:37:55 +02:00
parent 081a633419
commit 7104b8e588
1 changed files with 12 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/ISSUES.md
View file

@ -76,6 +76,18 @@ admission: the per-view block edge-plane test (`WalkVisibilityMath.BlockCheck` a
`LScape::draw_check_blocks` @0x00505f80's clip-height grid — BN elides the 192 m block
interval to `0f` there) and the exit-view union at this pose (two surviving views).
**Structural comparison (lead, 2026-09-03):** `LScape::draw_check_blocks` @0x00505f80 and
`WalkLandscape.CheckBlocks` match in structure — the two-parity corner-interval rows
(`block_interval[((x-1)&1)*(mw+1)+y]` east, `[(x&1)*(mw+1)+y]` west), the per-view
overwrite of `in_view` (`Render::block_check(west_y, west_y+1, east_y, east_y+1, max_zval,
min_zval)` @0x005061df), and `landcell_check`'s cell union. The admission of `a9c9` therefore
comes from the NUMERIC inputs at this pose (the two exit views' edge planes, the CY plane,
or `Render::get_clip_height`'s per-corner classification) and cannot be settled by reading.
NEXT STEP: one exact retail capture — a cdb template on `Render::block_check` @0x005061df's
caller that prints, for block `a9c9` at the doorway pose, the four corner intervals, the
z slab and the returned BoundingType, alongside acdream's `BlockCheck` inputs for the same
corners; compare plane by plane.
**Degrade note (2026-09-03 review):** the FW0 sibling row for the SAME pose pins
`RetailFrameWalk.DegradeMultiplier = 0f` because that capture ran under cdb load with
`Render::deg_mul` depressed; the OH doorway capture also ran under cdb, so check the