Fix railway/path clipping when on same height

[JeroenDStout]

Paths and railways built through one-another with zero-clearance show flicking. Changing the bounding box height stabilises it.

This change pushes the bounding box of straight railway and car ride pieces up by 1. This consistently puts them above regular pathways.

The change also pushes peeps up by 5 (instead of their default 3) to prevent them from causing depth fighting again. Although I have not checked every single possibility, as far as I can tell peeps are never in a situation where they depth fight with something that is 2 above them. Litter is pushed up by 1 to appear on top of the tracks.

This is all in anticipation of the future waiting-for-crossing PR, which is why I only changed straight track pieces. I imagine once waiting for crossing is in, allowing track pieces to be built onto paths can be enabled even without zero clearance.

[IntelOrca]

Hmm, I the thing is - you should just be able to have it draw based on map element order on the tile, if two things share the same boundary box. But @janisozaur and @marijnvdwerf might have a better idea if that is possible.

[JeroenDStout]

It is true that some sort of meta-ordering would be better, but peeps and litter already use this shifted method to always appear above paths (and peeps above litter). The boundary box is also not identical for both, the path & track just share the same z.

[Gymnasiast]

I'm not sure if car ride should get the same treatment. Otherwise, it looks good to me.

Work to be done is indeed allowing building railways through paths, and adding proper crossing sprites (even if it's just two rails without track bed, that would look a lot better).

[JeroenDStout]

I added the car ride because it is the only other track I could think of that I could conceivably see having crossings.

Personally I thought of this PR as a fix for the z-fighting in existing cases (I see a lot of parks with zero-clearance crossings), and save the waiting / custom sprites / 'legal' building for a future PR.

[IntelOrca]

I am not against this change, and it can be at least a temporary solution for now until we fix ordering based on tile stack.

[JeroenDStout]

This inevitably grew a little bit. Using custom sprites we could support drawing railways through any path. I have modified the paint_session struct and related code to be aware of same-height paths. This can be used in the railway drawing code to change the visuals. This same-height code might have a lot of other uses for when it is useful to know if things are intersecting.

[Gymnasiast]

ittElement?

[JeroenDStout]

Sorry, that was a shorthand I did not mean to push. I gave the variable a proper name in the next push.

[JeroenDStout]

More subtle indent sprites. The missing corner from the SPR_MINIATURE_RAILWAY_QUARTER_TURN_3_TILES_SW_SE has also been added.

Between tiles currently a small bit of track is visible. This can still be fixed by creating bespoke 'track going underneath' sprites for the (relatively few) sprites where this visually is a problem.

[marijnvdwerf]

Not a fan as this should increase the testpaint failure rate. It doesn't seem to do so, but that seems to be a bug.

[marijnvdwerf]

Also, the indenting of most comment blocks doesn't seem to match the indentation level of the surrounding code. And I've seen some lines with only whitespace.

[JeroenDStout]

But does this mean the code should be altered to prevent a trip-up for testpaint? Because in a sense it is correct this is not drawing identical to vanilla.

I shall change the indent style, but I believe the code style does not say anything about whitespace lines.

[Gymnasiast]

imageId

[Gymnasiast]

Is this ready, as far as you're concerned? Code looks good, only one minor line note.

[JeroenDStout]

I think I realised a problem with this code - train corners have no overlay grooved pieces and will not be visible when intersecting with roads.

Long term I would be interested in a solution where the railway track just has a toggle for alternative track where the train also runs visible lower, like this:

...except with an appropriate transition piece.

In the short term I think the solution is just to add grooved sprites for all railway tracks. It will take me some time to do but it would be a good instant improvement for any park where railways intersect paths. I suggest the PR will be ready when those sprites are implemented, too.

[Gymnasiast]

How about only handling straight track pieces for now?

[JeroenDStout]

I am tempted to say yes but unless the path selectively is bumped up a z-level, it will consistently clip above all turns; so the rails will be invisible (certainly not on top) when-ever a track intersects with a path. Implementing that selective bumping would be adding a lot of logic to the path paint function which I feel does not belong there.

(And vainly from a showman perspective, showing this feature first in action with a turn in the track will make a bigger impression than adding more later.)

[Gymnasiast]

I'm not sure I understand the need for handling turns, actually. Almost all real-life crossings are straight. At some point, we have to limit the scope and come up with something that can be merged for everyone to enjoy. I think it's better to settle for something more limited that works now. You can always add more stuff later on.

[JeroenDStout]

I get where you are coming from, though I don't see the hurry! I will add the required code for bumping the path up a level when appropriate (so it doesn't clip above all tracks) and fix the few pixels of track sticking through the path every tile.

The reason I am big on corners was because the 2nd reaction after "great" to this, which I've seen, is people wanting tramlines to run through their entire park. But I'll save it for a later PR.

[JeroenDStout]

Now works without wrong pixels in straight pieces:

Selective code in path means turns still work as in vanilla:

[JeroenDStout]

Now drawing in a different way, with extra sprites.

Going onto a path has a special lead-in (so the effect is less sudden), and it works on a variety of paths.

[pizza2004]

Is there possibly a way to make the rails work without having the black lines around them? I mean, like, while still being visually distinct from the path underneath. I just think it looks a tad odd how they transition from having the lines over the path to not having them on their regular track.

[Gymnasiast]

@pizza2004 I preferred the darker lines, but then some didn't. I guess it's just not possible to come up with something that will satisfy everyone. At this point my priority is to have it available for everyone, and we can always revisit the sprites later.

[HaasJona]

If you look at how rail transitions work in real life, the gaps for the wheel to go in are only on the inside on the rail. On the outside, the ground is usually relatively flush with the rail. I would therefore vote for the darker spots to be only on the inside of the rail.

[JeroenDStout]

Upon reflection I agree with @HaasJona, I think the far-most outer shadow could be tweaked to be slightly larger on the inside than outside. Would you be willing to edit the sprites again, @oli414 ?

I think the shadow mask should be self-explanatory.

[oli414]

@JeroenDStout For sure. I'm working this whole weekend so I won't have the time to do it but I can make them next week.

Mind adding some reference images to take a look at @HaasJone or @JeroenDStout

[HaasJona]

Something like this:

https://www.shutterstock.com/de/image-photo/railway-crossing-suburbs-adelaide-south-australia-661719655

Rough in game sketch:

[oli414]

I see what you're getting at. I quite like your draft already, I'll try a few different things in that same vein. But I do think it is more visually representative of the actual situation. Thanks.

[oli414]

@JeroenDStout The transparency thing doesn't appear to be working for me when grabbing your fork (Looks like it reads random bytes for the masks). But I got new sprites ready that I just need to have a quick look at in-game.

[JeroenDStout]

@oli414 Ah, I forgot this branch doesn't include the fixes I made to the sprite importer. If you pull from #6362 you can use the executable that generates for sprite importing.

But I do hope to soon finish up #6362 so that work-around won't be necessary.

[Gymnasiast]

This will need to be tested well with some NE parks to ensure it doesn't mess up edge cases w/r/t path drawing.

[JeroenDStout]

@Gymnasiast Yes. The situations in which the behaviour changes, right now, is when both a TRACK_ELEM_FLAT and a path element are visible; and share the same xyz. Turns of any kind should not change drawing behaviour.

So the question is, are there situations where a TRACK_ELEM_FLAT intersects a path while not a railway; and is the path drawing on top of the track "more wrong" than the glitchy undefined behaviour we have now?

[Gymnasiast]

If it only changes behaviour in such cases, then it's good. I thought it would change behaviour in more cases.

[Gymnasiast]

Alignment looks a bit odd here. Same for the last entry.
Both forms of alignment are fine, but you must pick one for a block ;-)