mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-07 05:03:35 +02:00
Henrik Rydgård
2de11efe4e
DecodeDXTBlocks limited its x loop to min(bufw, w), so when w > bufw everything from bufw to w was simply never written - the destination is sized for w, so those columns kept whatever the buffer held. The software sampler doesn't do that. It addresses a block as (v >> 2) * (texbufw >> 2) + (u >> 2), which for u past bufw runs on into the next row's blocks, the same way the linear formats run into the next row. So the two renderers disagreed on the same texture. Follow the sampler: decode w texels per row and let the block index carry on, with the range check widened to cover the blocks that reach past the last row's stride. Shares the SourceExtent helper from the previous commit, counting 4x4 blocks rather than texels. Rendering-visible where w > bufw for a DXT texture, which is the case that used to leave stale contents behind.