Skip to content

Straight view volume box fix - #5121

Draft
AdamPlenty wants to merge 18 commits into
dkfans:masterfrom
AdamPlenty:StraightView
Draft

Straight view volume box fix#5121
AdamPlenty wants to merge 18 commits into
dkfans:masterfrom
AdamPlenty:StraightView

Conversation

@AdamPlenty

@AdamPlenty AdamPlenty commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Fixes #5097
Fixes #5120

Tested at 320x200, 640x480, 1280x800, and 1920x1080 resolutions.

@AdamPlenty
AdamPlenty marked this pull request as ready for review August 15, 2026 03:52
@cerwym

cerwym commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

Rather than accepting it, why did you choose 15 specifically, what you're doing there is changing the depth offset to stop occlusion in the bucket, honestly, I would prefer it if you made a reasonable review on what in the bucket occludes this.

Note : I've removed this entirely in the new renderer

@cerwym
cerwym requested review from cerwym and a lite review from Copilot August 15, 2026 08:40

@cerwym cerwym left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need deets

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adjusts the straight/front view volume box rendering so the highlight/volume box outline appears consistent across resolutions, addressing the visual artifacts reported in #5097 and #5120.

Changes:

  • Tweaks the Z-offset used when drawing both the normal and “fancy” frontview map volume boxes.
  • Aligns the two frontview volume-box rendering paths to use the same updated offset.
Suppressed comments (1)

src/engine_render.c:8567

  • The rounding adjustment in y_start/y_end and x_start/x_end uses ((a % b) >= b) which can never be true for non-negative values, so the ternary is dead code. This is misleading and makes it harder to reason about the pixel-to-slab mapping (especially when debugging resolution-specific artifacts).
    coord_z -= (15 * (long)stl_width) >> 2;
    for (int roomspace_y = 0; roomspace_y < room_slab_height; roomspace_y += 1)
    {
        int y_start = (box_height * roomspace_y       / room_slab_height) + ((((box_height * roomspace_y)       % room_slab_height) >= room_slab_height) ? 1 : 0);
        int y_end =   (box_height * (roomspace_y + 1) / room_slab_height) + ((((box_height * (roomspace_y + 1)) % room_slab_height) >= room_slab_height) ? 1 : 0);

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/engine_render.c
break;
}
coord_z -= (11 * (long)stl_width) >> 2;
coord_z -= (15 * (long)stl_width) >> 2;
@AdamPlenty

Copy link
Copy Markdown
Contributor Author

Rather than accepting it, why did you choose 15 specifically, what you're doing there is changing the depth offset to stop occlusion in the bucket, honestly, I would prefer it if you made a reasonable review on what in the bucket occludes this.

Note : I've removed this entirely in the new renderer

I've no idea; I just tried it arbitrarily and it seemed to work, so I went with it. My previous fix only fixed the top line.

@AdamPlenty

Copy link
Copy Markdown
Contributor Author

Need deets

What do you mean?

@Loobinex

Copy link
Copy Markdown
Member

Now you can see the box through walls:
image

@AdamPlenty

Copy link
Copy Markdown
Contributor Author

Now you can see the box through walls: image

I don't have this issue... ...with most walls.

@AdamPlenty

Copy link
Copy Markdown
Contributor Author

Only seems to happen if there's a path visible on the other side.

image

@Loobinex
Loobinex marked this pull request as draft August 22, 2026 11:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

4 participants