Make it possible for ways to draw stuff right in front of the vehicle (not tile)

[Nazalassa]

As of now ways can draw their images in two locations: behind the vehicle (backImage) and in front of everything on the tile. Both can find uses (be it specific or general).

However, I think there should be a third location available: right in front of the vehicles, but behind the other frontImages of the tile (i.e right after the vehicles in the drawing order). Such an "image location" could be useful in the following situations:

• In the pak48.bitlit, the tunnels are tube-shaped, and use the way's frontImage to draw the part of the tube that is in front of the vehicles. However, since the way's frontImage is drawn above everything on the tile, including any building's frontImage, this may lead to ugly graphics. In the example below, the station does not give too bad a result, but the depot does - the tunnel's frontImage gets drawn above its frontImage whereas it would be better if it did not.
  
  
  
  Thus I think in this situation it would be better if the tube's front was drawn at the new location I suggest, right in front of the vehicle, but behind any building's frontImage.
• I have made some sort of "experimental" way which has a "wall" on both sides (to avoid the vehicles getting off the track). Thus the front wall hides part of the vehicle. This means it has (with the current system) to be a frontImage, which gives the following result when a building is added:
  
  
  
  The front wall would go better at the new location I suggest, right in front of the vehicle, but behind any building's frontImage.

Such an "image location" would thus be used e.g for whatever part of the way that is supposed to hide only (part of) the vehicles.

[prissi]

A thrid position is very difficult to realise. One could however tweak the order so than stations' and depots' forntimages are drawn before the ways' frontimages. That would apply to all ways and all graphic sets. However, I thing it should make more sense this way as it is like real stations and depots appear.

Please test it in r11402

[Leartin]

it should make more sense this way as it is like real stations and depots appear.

I don't think that can be generalized. In the given examples, the station is broader than the way, so the frontimage of the way should be behind the stations frontimage. But you could have ways that are as broad as the tile, with narrower stations, then it makes more sense for the wall to cover the station. And there are more dimensions - some frontimages are meant to be "above" the way, while stations are often "in front, but rather flat on the ground".

Same is true for backimages, to be honest. In the second example above, if you turn it to see the opening, you'd probably want the wall to continue into the depot. But if the way is all flat on the ground, but reaches the tile borders, you want the depots backimg to cover the ways backimg.

That being said, I suppose I can finally add the snowpoles to my roads that I dropped due to exactly this issue...

[prissi]

One could have this configurable per way or per pakset as it needed only one change in recalculating the image after construction or season changes.

[Nazalassa]

One could have this configurable per way or per pakset as it needed only one change in recalculating the image after construction or season changes.

Or configurable per building? Then perhaps it would also be good to have an option not to display the way's FrontImage for some buildings, such as this "station":

[prissi]

Actually, I was hiding the front image on stations and depots in r11402 not changing the drawing order. That was too complex.. Did you checked it?

[Nazalassa]

Here is what I get with r11402:



I also tested the pak48.bitlit tunnels; the FrontImage is still here in both cases. But perhaps I missed something.


When I suggested per-building "way-FrontImage-display-mode", I was thinking of maybe something like this in the code that renders a tile (assuming it is implemented by sequencially blitting images on the screen; I could not find where in the source code it is, so I am just guessing it is like this; I hope it is not too un-understandable):

Code Select Expand

(render BackImages)
if (way on tile has a FrontImage && (station on tile)->(way FrontImage display mode) == 1)  /* Assuming "(way FrontImage display mode)" is ) 0, 1 or 2 depeding on station setting */
   (render way FrontImage)
(render station FrontImage)
(render other front stuff)
if (way on tile has a FrontImage && (station on tile)->(way FrontImage display mode) == 2)
   (render way FrontImage)

or:

Code Select Expand

(render BackImages)
if (way on tile has a FrontImage && (station on tile)->(way FrontImage display mode) == 2)
   (render station FrontImage)
if (way on tile has a FrontImage && (station on tile)->(way FrontImage display mode) != 0)
   (render way FrontImage)
(render other front stuff)
if (way on tile has a FrontImage && (station on tile)->(way FrontImage display mode) == 1)
   (render station FrontImage)

In these cases, "way FrontImage display mode" works as follows:
* 0 = No way FrontImage
* 1 = station FrontImage is rendered above way FrontImage
* 2 = way FrontImage is rendered above station FrontImage (default)

[prissi]

Change the render order will cost a lot of memory and speed. The list are sorted for background drawing once when the objects are cerated and then are drawn backwards. Any deviation from that order needs lengthy tests for every tile with a straight way to look for a depot.

Hiding the frontimage costs almost nothing. But the hiding seems not to work. Can I get your pak or dat and graphics for more tests, please? (Or are they in your repo?

[Nazalassa]

Attached is a "pakset" which has a way with a FrontImage and a depot. (I did not include the 16 boxes with other colors.)
Note: the depot is in the "uniflow" menu and the tracks can be accessed with "t".

[prissi]

That is broken, the uniflow way is just some triangles looking like diagonals. Can you send me the pak files for just the way and the depot you used for your screenshots? Then I can put them into an addon folder.

[Nazalassa]

They are pak32 size so pak32 is required (I do not know any other pak32); the depot was the one from pak32 anyway, so I did not include it.

[prissi]

It works now in r11405 but it requires some more tweaks to the depots as the previous tile may overlap too.