[CnRJay]

What

image_gather4_lz_o on a 1D view threw. The 1D gather emulation picks the two texels around the coordinate itself, so it now adds the 6-bit x offset from the address to the left texel index before both texel centres are sampled. This offsets the footprint the same way the hardware does.

Tested

Windows 11, MinGW GCC Release build, ctest agc_driver_image_gather_one_dimensional passes (new, on the GPU). It covers image_gather4_lz and image_gather4_lz_o with clamp-to-edge and wrap samplers. The offsets range from -5 to +5, and every third thread also sets the unused y and z offset bits, which must be ignored. Every returned component is compared with a CPU reference.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

🤖 Generated with Claude Code

[adriadam10]

Checked the offset path on hardware (gfx1035 oracle, 1D F32 texture, clamp and wrap, offsets -32..31 with y/z and high bits set): the footprint shift matches in every row. Build + ctest green, the new test fails without the change. Merging.