Slope track piece not rendered at tunnel entrance directly under horizontal surface

[cheweytoo]

Operating System

Ubuntu Linux 20.04.5

OpenRCT2 build

f91df41 develop

Describe the issue

Basically the same thing as #18376, but this time direction dependent: The slope track piece of any coaster that has this piece available is not rendered in a tunnel entrance directly under flat land. while the corresponding upslope piece on exiting a tunnel does show up.

Edit: Turns out it depends on the amount of land above, the upslope piece is affected too:

As with #18376, using "Hide Vertical Faces" makes the track piece appear.

So this is probably an original bug as well.

Area(s) with issue?

No response

Steps to reproduce

Build a "Mine Ride" entering a vertical wall on a downward slope. Or see attached park.

Attachments

mine_ride_noslope.zip

[jensj12]

You're chopping their heads off. Raise the ground one unit and the track piece will show, along with a larger tunnel (which is how it works (or used to work) for all tracked rides that enter a tunnel sloped).

[Broxzier]

Did you build that track with clearance checks disabled?

[cheweytoo]

You just made me check again, but no: This is a completely legal build without any cheats.

So I'd argue that while indeed more land on top makes the render change, this is still a bug.

[cheweytoo]

OK, I just used "arbitrary ride type changes" to cycle through most of the track types, and it seems all are affected.

Is the actual bug here that this is buildable?

[jensj12]

It is buildable like this in vanilla RCT2 and even RCT1. You need 2 units of height to build a tunnel, but on a slope there is only 1.5 units of clearance. Giving it a third unit makes it use the full 2 height units.

[cheweytoo]

So it's intentionally buildable then. That makes this a rendering bug :-)

I've updated title and description.

[karst]

I think lowering the "flat" tunnel's bounding box by 8, or expanding it by 8 on the bottom, would fix all these bugs, even the one I fixed before by changing the bounding boxes of the helixes (so we could revert that). I do wonder how difficult it is to access these bounding boxes but it's something I could look into

[ocalhoun6]

Paying attention to this a bit more, I've noticed something weird: this bug does not occur if the virtual floor is visible anywhere on the screen. The virtual floor doesn't even have to be anywhere near the tunnel entrance. If the virtual floor is displayed anywhere, this bug goes away.

Without virtual floor:

With virtual floor:

[karst]

similar to any other thing the floor is just another sprite placed on top or under it. In this case I think the bounding boxes match one another so the priority changes if another sprite is added on top or under it and it shows again. It's why the corrupt element used to work.