The International Simutrans Forum

Development => Bug Reports => Topic started by: Dwachs on August 06, 2018, 07:31:57 PM

Title: Clipping problems with tunnel portals
Post by: Dwachs on August 06, 2018, 07:31:57 PM
I have this tunnel bug also in an older build, so it is not due to the patch.

Edit: should be fixed in r8550
Title: Re: Re: Terrible performance changing undergroud view mode or slice level.
Post by: DrSuperGood on August 07, 2018, 10:07:13 AM
Edit: should be fixed in r8550
Partly fixed for double height paksets? The entrance art is drawn correctly but the back walls of tunnel entrances are missing when viewing them at the ground slice level. This results in it looking like the tunnel entrance is floating. I think this is unrelated to the clipping problem but still is a bug with them.

Not at all fixed for single height paksets. As before the accurate draw method will clip parts of the tunnel art while the fast draw used when fast forward will correctly display the entire entrance.

Maybe this needs its own topic since we have determined it has nothing to do with the patches?
Title: Clipping problems with tunnel portals
Post by: Dwachs on August 07, 2018, 01:34:35 PM
There are clipping problems as can be seen here:,18338.msg174506.html#msg174506

They are not due to the patch discussed in that topic.
Title: Re: Clipping problems with tunnel portals
Post by: Dwachs on August 07, 2018, 01:38:08 PM
@DrSuperGood: Can you provide a small savegame. I checked with pak64, which worked...

Edit: Also tested with pak128, could not reproduce any glitches.

Title: Re: Clipping problems with tunnel portals
Post by: DrSuperGood on August 08, 2018, 08:36:58 AM
When testing this I removed my slice change performance optimization patch and reverted to trunk in case it was the cause but there was no change and the issue is still present. These were done using the GDI back end in windowed mode, however that really should not make a difference as drawing is done by software.

I have attached proof images as well as the saves these were taken on. All the saves are freshly created.

The pak128 tunnel entrance. As one can see it is missing the back wall so it looks like the entrance mouth is floating in mid air. This only happens when viewed at the level of the tunnel way, with it correctly showing the side wall when viewed the slice above. There also is some buggy logic when it comes to displaying the end of road bollards, they are only shown correctly for the tunnel entrance when viewing the slice the tunnel entrance ground is at (not any above it) where as for outside roads they are always show irrespective of slice (level it is at and all above).

The pak64 tunnel entrance is showing the same graphic clipping issues as the pak128 tunnel entrances used to suffer from. One can see this by comparing the image with the image obtained during fast forward play (both provided) where the tunnel entrance graphics do not suffer the clipping issue. They are also missing the back wall like the pak128 tunnel entrance do appear to float. Unlike pak128, pak64 ways are single height so there is no way in slice mode to see the way of the tunnel entrance with its back wall showing.

To clarify what is meant by back wall. Walls such as those that are missing from the tunnel entrances are technically the back walls of the tile in front even though they appear to be the walls of the to the tunnel entrance. Mechanically this means they are computed when updating the back wall images of the times in front of the tunnel entrance, and not the tunnel entrance tile itself.
Title: Re: Clipping problems with tunnel portals
Post by: Dwachs on September 04, 2018, 06:03:05 PM
r8566 fixes some clipping problems with tunnel entrances in underground view mode.

Missing backwalls: In sliced mode, tunnel entrances are treated as flat tiles for display purposes, hence no vertical walls between tunnel entrance and outside tiles. The display methods only distinguish between visible/not visible, not between inside/outside.

Double height: I have no idea how to fix this. It is in grund_t::calc_back_image, but I do not understand enough of the code there to fix it.