NRT: technical purpose of road/tram underlays and overlays in NML

[Auge]

Hello

What is the "default" purpose of underlay and overlay sprites for road and tram types? In my set I use the underlay for the road sprites (without pavements) and the overlay in example for road markings. I used the freely available code of other NRT sets as a guide but I think, I oversimplified it.

After inspecting the example in the NML-repository I am absolutely confused because the example with yellow, green, red and blue road types does not clarify anything for me. All road type sprites (underlay and overlays) looks (beside the different colours) the same, all sprites covers the same areas.

What is the purpose of the underlay if it is completely covered by the overlay?

I would like to be able to provide sprite replacements for the roads with pavements. This for roads, that should get pavements in the inner city areas but also for roads, that shouldn't get pavements at all. On the other side I would like to prevent the need to draw own grass sprites as pavement replacements because this would make the set stylistic depending on a base set. Is there a simple solution with the underlay-overlay-system? As far as I know it is (at least in NML) not possible to replace one base set sprite with another base set sprite (i.e. road with pavement sprite with a grass sprite).

Thanks in advance and tschö, Auge

[Andrew350]

The example in the NML repo is not meant to be very sensible graphics-wise, it is just showing a (very) basic implementation code-wise.

The difference in purpose for underlay and overlay sprites is very obvious for tramtypes where the underlay is used for the ballast, which is drawn only for grade-separated tramways, while the overlay sprites are the rails which get drawn everywhere.

For roadtypes this distinction is less clear since both underlay and overlay sprites are always drawn (if provided), so it basically just comes down to your own preference in how you want to structure your set. Some people (like myself) don't use overlay sprites at all for roadtypes and instead just bake all the details into the underlay sprite. This works well enough if all of your different roadtypes are visually unique. For other cases however where you want to have one road texture, but several variations of lane markings or sidewalks or other details, then it may make more sense to use overlays for those things to reduce duplication of sprites. But it is really up to you, both ways will work (mostly) fine in any case

As for changing the base sprite for city roads, I don't think there is a better way to do it than replacing them with your own terrain sprites, as annoying as that is. It used to be that all roads kept the base road sprite underneath them like that, then at some point it was changed for the rural roads to draw grass underneath instead, but for some reason that change was not applied to the city roads as well. Not sure if there was a good reason for that or not, but perhaps that's something to look into to ask about changing

[Auge]

Hello

The difference in purpose for underlay and overlay sprites is very obvious for tramtypes where the underlay is used for the ballast, which is drawn only for grade-separated tramways, while the overlay sprites are the rails which get drawn everywhere.

This is also, how I interpreted it. Haven't implemented the tram track types into my set until now but that makes me moving straight forward instead trying it out again and again. Thanks for your clarification.

For roadtypes this distinction is less clear since both underlay and overlay sprites are always drawn (if provided), so it basically just comes down to your own preference in how you want to structure your set. […] For other cases however where you want to have one road texture, but several variations of lane markings or sidewalks or other details, then it may make more sense to use overlays for those things to reduce duplication of sprites. But it is really up to you, both ways will work (mostly) fine in any case

I implemented the lane markings as overlays. So it is o.k. to do it that way.

As for changing the base sprite for city roads, I don't think there is a better way to do it than replacing them with your own terrain sprites, as annoying as that is.

What a pity. To make this looking proper one needs to provide the OpenGFX grass tiles and to adapt self drawn nearly original looking grass sprites at least. Not to even think about further base sets. O.k., it's currently as it is.

It used to be that all roads kept the base road sprite underneath them like that, then at some point it was changed for the rural roads to draw grass underneath instead, but for some reason that change was not applied to the city roads as well. Not sure if there was a good reason for that or not, but perhaps that's something to look into to ask about changing

At least with a loaded NRT-set it would be nice to not loading the default road-with-pavement underlays and to leave it to the set author to provide proper sprites and code (maybe with switching to the default sprites).

Thank you very much for your advice.

Tschö, Auge

[Andrew350]

At least with a loaded NRT-set it would be nice to not loading the default road-with-pavement underlays and to leave it to the set author to provide proper sprites and code (maybe with switching to the default sprites).

I was seriously considering opening a bug report to change this behavior (since it is wrong, as far as I'm concerned), unfortunately pretty much every roadtype set in existence relies on replacing the base city road sprites (1313-1331) with their own sprites in order to work, which means changing it now to the correct behavior (using terrain sprites instead) would almost certainly break just about every roadtype NewGRF, so it is unlikely to ever be an accepted change*

*Unless somehow every NRT author could be convinced to adapt to it...

[kamnet]

*Unless somehow every NRT author could be convinced to adapt to it...

If this is truly the proper way to do it, then it should be done. Any author who doesn't update either isn't developing for OpenTTD anymore or doesn't care and their stuff should be left behind and considered obsolete. And if their project is open source, then it can be forked by somebody who cares enough to change. it.

[Quast65]

Would this open a door to custom tunnels per roadtype?

[Andrew350]

If this is truly the proper way to do it, then it should be done. Any author who doesn't update either isn't developing for OpenTTD anymore or doesn't care and their stuff should be left behind and considered obsolete.

Well, that's just my opinion on it, that doesn't necessarily mean anyone else agrees with me It is a bit of a double-edged sword in that it does make sense to be consistent with rural roads and force roadsets to also provide the sidewalk as part of the roadtypes themselves (rather than relying on the base sprites underneath), but the current way of simply replacing the base road sprites is much easier and simpler, as it effectively means only having to use a single "replace" block to change sidewalks for all roadtypes at once. And to be clear, I take advantage of this shortcut myself, so I would be just as affected as everyone else by such a change

Either way it probably needs some discussion with other roadset authors before just going for it and breaking everyone's stuff unexpectedly

Would this open a door to custom tunnels per roadtype?

No, that would be a separate feature, ButGroundTypes

[Emperor Jake]

No, that would be a separate feature, ButGroundTypes

I think ButGroundTypes is overly complex and unlikely to ever be implemented. The reason for roadtypes not having their own tunnel portals is because they would clash when it can't be decided when the road or tram tunnel graphic should be used, since both can share the same space.

Fortunately, there are other possible solutions, like the implementation of tunnel types akin to bridge types, which is being worked on here: https://github.com/Brickblock1/OpenTTD

I was seriously considering opening a bug report to change this behavior (since it is wrong, as far as I'm concerned), unfortunately pretty much every roadtype set in existence relies on replacing the base city road sprites (1313-1331) with their own sprites in order to work, which means changing it now to the correct behavior (using terrain sprites instead) would almost certainly break just about every roadtype NewGRF, so it is unlikely to ever be an accepted change*

I would support this change as well, I've started coding a roadtype set myself and for now I replaced the default road sprites with ISR-style ground in order to give the player better control of where sidewalks should and shouldn't be. It would be great if there was a better solution to this.

[Quast65]

Fortunately, there are other possible solutions, like the implementation of tunnel types akin to bridge types, which is being worked on here: https://github.com/Brickblock1/OpenTTD

That would be awesome!

[Andrew350]

ping

Hey, so just to update you I've gone ahead and posted an issue to GitHub requesting the change. Hopefully I made the point clearly Assuming the devs agree and make the change I'll try to contact as many NRT authors as I can to inform them of it in order to make preparations and/or air their grievances about it. If anyone has anything to add whether you agree/disagree make sure to mention it on the ticket

https://github.com/OpenTTD/OpenTTD/issues/11154

[Auge]

Hello

Hey, so just to update you I've gone ahead and posted an issue to GitHub requesting the change.

https://github.com/OpenTTD/OpenTTD/issues/11154

Thank you for your effort. I wrote a comment in the meantime and explained my intention.

Tschö, Auge