Transport Tycoon Forums

Posted: **27 Mar 2010 07:08**

Since OpenTTD r18959 and TTDPatch 2.6 r2312, "layered" ground sprites are possible. This is especially useful in connection with OTTD´s new feature of "track types", and for preserving compatibility with TTDPatch lacking that "track type" feature.

However, the spec for the layered ground sprites feature is flawed. In fact, OTTD´s implementation has nothing to do with "ground sprites". Instead, it allows adding "building sprites" to the usual ground sprite, although the appropriate entry in the TTDPatch Wiki suggests otherwise:

TTDPatch Wiki wrote:Since OpenTTD r18959 you can draw multiple ground sprites for a tile, which is useful if you want to use the usual rail/grass/concrete groundtile, but still need to add features to it without using a new bounding box. [...] http://wiki.ttdpatch.net/tiki-index.php ... _layout_09_

Since a long time, TTDPatch (and OTTD) allow to have custom ground tiles in an action1 block. Determining if a ground tile is a TTD sprite or a custom ground tile is done by checking var10. In this way, it´s easily possible to get custom ground tiles accessible from multiple areas in the station code, without real sprite duplication.

Now, with the flawed OTTD spec, this is not possible. Inside the framework of this spec, one has to have the sprites for ground tile layers inside the building sprites action1 block.

The drawback of this scheme is that one has to provide the real sprites of those ground tile layers multiple times, or, if all sprites are put into a large action1 block, to use CB14 for sprite selection. Although this being the method of choice for large or complicated station structures, it is not suitable for smaller ones or for "fixed" station structures, for which the same layout will be re-used with different real sprites mapped to them.

I´ve discussed this with Csaboka and we came up with three possible solutions:

- we could use different specs in TTDPatch and OTTD with regards to that "layered ground sprites" feature,
- we could add a new flag to select between the two behaviours on a per-station basis,
- we could change the OTTD spec accordingly, i.e. all ground sprites should follow the "ground sprite rules" and not the "building sprite rules". The needed changes to TTDPatch would be easy.

From our discussion, the first two proposals don´t make sense at all. Especially the last one would complicate things for both developers and newgrf authors, and, in addition, it would need implementation in OTTD as well for compatibility reasons.

From our opinion, the third proposal would allow the most straighforward, flexible and efficient handling of layered ground tiles for stations, for use with all known "techniques" of station coding.

Are there any objections from OTTD developers against the third proposal?

regards
Michael

Posted: **27 Mar 2010 12:29**

Sorry, your description is just as imprecise, fuzzy and misusing names as it can only be.
So I am going to rephrase what you maybe wanted to suggest. Next time I suggest Csaboka to write the specification.

Current situation:
For stations property 13 bit 0 allows to choose a different sprite set when drawing the (first) ground sprite of a spritelayout (in case the spritelayout specifies to use an Action1 sprite).
Industries and houses have no similar feature.

Maybe mb suggests: (numbering independant of above post)
Option 1: If property 13 bit 0 is set, use the seperate ground sprite set also for drawing secondary ground sprites.
Option 2: Add a new bit to property 13 to cause secondary ground sprites being drawn with the same spriteset as the first ground sprite.
Option 3: Add a new bit to property 13 to cause secondary ground sprites being drawn with a spriteset on their own. (E.g. var 10 = 2 or even incrementing per sprite?)

Remains the question:
What is the actual use of this? You mention custom track types. Can you please show an example usage in more detail. Especially in the interaction with the ground sprites and overlays of the custom track type, which are drawn if the first groundsprite is the non-custom original X/Y rail sprite.

Edit: Forgot to answer the question

Option 1 and 2 would be easy for OTTD as well, just it would likely not hit 1.0.0. And as I said I doubt the usefulness of using the same spriteset for all groundsprites, as that would again not allow to properly draw sprites below the train from the normal spriteset (so I prefer option 2 if at all). I am not aware of an released station set using that feature (the main target were industries and houses), so it would likely not be that troublesome if newer station sets would need a nightly.

Posted: **27 Mar 2010 13:09**

frosch wrote:Maybe mb suggests: (numbering independant of above post)
Option 1: If property 13 bit 0 is set, use the seperate ground sprite set also for drawing secondary ground sprites.
Option 2: Add a new bit to property 13 to cause secondary ground sprites being drawn with the same spriteset as the first ground sprite.
Option 3: Add a new bit to property 13 to cause secondary ground sprites being drawn with a spriteset on their own. (E.g. var 10 = 2 or even incrementing per sprite?)

I think Michael (and myself) would prefer option 1. Options 2 and 3 would complicate the already complex station spec even further IMO. (They would also complicate the TTDPatch code somewhat, but I could live with that.)

Posted: **27 Mar 2010 15:41**

Ok, agreed, option 1 is the easiest for specification. Maybe there indeed no need for drawing sprites without bounding box and using a separate spriteset for the first groundsprite at the same time, esp. since the first ground sprite got a special meaning with custom track types.

So, I am fine with option 1, but I do not know a lot of stationsets, and what other grfs might need.

Posted: **27 Mar 2010 16:24**

frosch wrote: Sorry, your description is just as imprecise, fuzzy and misusing names as it can only be.

Well, I´m really sorry that you don´t understand my post, even though I put some extra effort into articulatedness and detailedness for readers not familiar with station coding and those particular problems arising with OTTDs novel ground tile/sprite handling.

frosch wrote: Remains the question:
What is the actual use of this? You mention custom track types. Can you please show an example usage in more detail. Especially in the interaction with the ground sprites and overlays of the custom track type, which are drawn if the first groundsprite is the non-custom original X/Y rail sprite.

As already written above: the actual use would be to keep ground tiles/sprites and building sprites separated. Only then it´s possible to "recycle" real sprites in various ways.

E.g., this is part of a station action0 property9:

Code: Select all

(*)
   2D 04 00 80 // a reference to a custom ground tile in a special action1 sprite block 
   00 00 00 10 05 0A 2D 04 00 00 // references to building sprites in an action1 sprite 
   00 00 10 10 10 0A 2F 04 00 00 // block for building sprites
   80

In this case referencing those sprites is done in this way:

Code: Select all

02 04 <cid> 81 10 00 FF 01 
	<ref0> 01 01 // ground tile
	<ref1> // building sprites

where <ref0> references the action1 sprite block for ground tiles, and <ref1> references the action1 sprite block for building sprites (via an action2).

In this way, many varaction2 chains may reference the same station structure, if (*) would be part of multiple station-IDs action0 (copied by prop0A). Thus, e.g., 0x42D is mapped to whatever sprite is contained first in the sprite block addressed by the action2 last in the chain of <ref1>, etc. pp. Same for the custom ground tiles addressed by <ref0>.

Now, with something like this

Code: Select all

   F4 03 00 00 // "TTD" ground tile, replaced by a custom track "tile" (track types)
   00 00 80 00 00 00 2x 04 00 00 // "OTTD-type" ground sprite overlay 
   00 00 00 10 05 0A 2D 04 00 00 // building sprite
   00 00 10 10 10 0A 2F 04 00 00 // building sprite
   80

we don´t have any special action1 sprite block for ground tiles/sprites, but only one action1 sprite block for building sprites. In this sprite block we need the sprite addressed by 0x42x multiple times [*], simply because of the mapping of action2s.

This problem would not occur if OTTD would handle ground sprites separately from building sprites:

Code: Select all

   F4 03 00 00 // "TTD" ground tile, replaced by a custom track "tile" (track types)
   00 00 80 00 00 00 2D 04 00 80 // ground sprite overlay, in special action1 block 
   00 00 00 10 05 0A 2D 04 00 00 // building sprite
   00 00 10 10 10 0A 2F 04 00 00 // building sprite
   80

then, again,

Code: Select all

02 04 <cid> 81 10 00 FF 01 
	<ref0> 01 01 // ground sprites
	<ref1> // building sprites

would work for any custom "track types" as in the example above (*) without being forced to introduce multiple ground sprites for track overlays.

[*] useless multiple sprites are a real problem in station coding, see e.g. here. We don´t need any more of it.

HTH
Michael

Posted: **27 Mar 2010 16:32**

frosch wrote:Ok, agreed, option 1 is the easiest for specification. Maybe there indeed no need for drawing sprites without bounding box and using a separate spriteset for the first groundsprite at the same time, esp. since the first ground sprite got a special meaning with custom track types.

Is it only the first ground sprite that gets special treatment? That might be a problem, since Michael's use case is having a custom ground sprite (e.g. customized grass) and adding whatever rail track sprite is appropriate for the current track type.

EDIT: Michael's code above seems to suggest that you indeed must have the track as the first ground sprite. Does that mean that you cannot have your own ground under the track?

frosch wrote:So, I am fine with option 1, but I do not know a lot of stationsets, and what other grfs might need.

I'm not really familiar with station coding strategies either, but in our e-mail discussion with Michael before this topic, he told me he cannot think a use case that would benefit the current rules. This seems to make sense to me intuitively, since you either
a) have your ground sprites in a separate action1; then you want to access that action1 for extra ground sprites too
b) have your ground sprites in the same action1 as building sprites; then you don't use bit0 in property 13, and you don't care about the behavior we are discussing.

Posted: **27 Mar 2010 18:03**

Csaboka wrote: Is it only the first ground sprite that gets special treatment? That might be a problem, since Michael's use case is having a custom ground sprite (e.g. customized grass) and adding whatever rail track sprite is appropriate for the current track type.

EDIT: Michael's code above seems to suggest that you indeed must have the track as the first ground sprite. Does that mean that you cannot have your own ground under the track?

Currently the special treatment applies to only the X/Y track tiles with grass. Adding special treatment also for the junction overlay sprites to put railtype-aware track on top of a custom groundsprite might be worth a suggestion for petern. Even more, it puts this topic in a different context. Maybe you just gave an example where the current behaviour is more useful:

Csaboka wrote:I'm not really familiar with station coding strategies either, but in our e-mail discussion with Michael before this topic, he told me he cannot think a use case that would benefit the current rules.

I guess you discussed the case of a default rail ground sprite and then adding e.g. dirt to it.

Now imagine you reuse a general ground tile (e.g. some concrete), and then add the rail overlay (with the special railtype-awareness you just suggested) and then want to add stationtype specific additions to the groundsprite (e.g. shadows). Then you need the first sprite from a different set, the second one is a non-Action1 sprite, and the third is station specific.

So considering the railtype overlays, using the separate spriteset for only the first groundsprite might be actually more useful. Then you start with a custom dirt sprite, add a railtype-aware track-overlay to it, and then add the stationtype specific stuff.

Posted: **27 Mar 2010 18:33**

You seem to complicate the problem.

Until now, every station tile (composed of sprites) uses a ground tile which has to be first in a prop09 structure. You may use every TTD or a custom tile as a ground tile. ATM, for stations we´re using a track tile (custom or TTD) for this ground tile, o/c.

The idea is to enhance this scheme by allowing stacked/layered ground tiles. In this way you may have, e.g.

- a custom or a TTD track ground tile (flat),
- additional custom ground tiles (TTDPatch) resp sprites (OTTD) (flat),
- building sprites (with height)

Step1 will add TTD or custom track tiles automatically (this already works). Step3 could be empty (no building tiles, this works too), and in general, step2 could allow TTD sprites as well, but I don´t see any real application for this. But for sake of completeness, this could be allowed as well.

Talking about junction sprites is outside the context of stations.

regards
Michael

Posted: **27 Mar 2010 19:09**

Michael, do you mean that there would be no need to assemble the ground of a station by starting with an empty ground sprite and adding a rail sprite onto that? I was thinking that would come in handy in some cases.

Posted: **27 Mar 2010 19:25**

I don´t really see a need for that:

- if a station set wants to be compatible with custom track type sets it may not use custom track ground tiles at all. Custom track tiles are composed in a track type set.
- if a station set wants to use its own custom track it may compose it from custom ground tiles or from TTD ground tiles with custom overlays (tiles in TTDPatch).
- a landscape set will also contain own track tiles which could be used or overriden.

IMO, it´s irrelevant what comes first, the overlay or the (empty) ground tile. The only important thing is to have a means of composing flat tiles, because for station track tiles you cannot fool around with overlays of zero height, this will always give issues with the sorter. Exactly that´s the reason why we always have to use custom track tiles in stations if we want to have some overlay to the track section of a groundtile itself. Having overlays on the non-track sections of a ground tile was never a problem.

regards
Michael

Posted: **27 Mar 2010 20:03**

Oh, well.

For railtypes there is already a discussion topic. If you prefer to reinvent track types instead of understanding how it works currently, that is not my problem. It also has nothing to do with the initial feature of drawing sprites without zero sized bounding boxes.

In case you still want to understand how it currently works, you might start discovering in which cases TTD composes rail sprites from grass/underlay and single tracksprites, and when it does not. And then when OTTD's custom railtypes do it. Next you might encounter "Track overlays for junctions", and maybe understand what drawing of tracks on custom groundtiles shares with drawing junctions. And finally you might discover in which cases currently custom railtypes draw their sprites instead of original TTD sprites with grass and track.

I will try to ignore this topic now.

Posted: **27 Mar 2010 20:30**

frosch wrote:Oh, well. For railtypes there is already a discussion topic. If you prefer to reinvent track types instead of understanding how it works currently, that is not my problem. It also has nothing to do with the initial feature of drawing sprites without zero sized bounding boxes.

In case you still want to understand how it currently works, you might start discovering in which cases TTD composes rail sprites from grass/underlay and single tracksprites, and when it does not. And then when OTTD's custom railtypes do it. Next you might encounter "Track overlays for junctions", and maybe understand what drawing of tracks on custom groundtiles shares with drawing junctions. And finally you might discover in which cases currently custom railtypes draw their sprites instead of original TTD sprites with grass and track.

I will try to ignore this topic now.

May I ask to whom you are talking?

regards
Michael

Posted: **29 Mar 2010 18:38**

To be honest, I didn't really follow what has been written so far, so maybe I have the wrong end of the stick. Would an extra station flag that causes the track overlay sprite to be drawn regardless of which ground sprite is used be sufficient?

Transport Tycoon Forums

Layered ground tiles for stations, buildings and ind. tiles

Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles

Re: Layered ground tiles for stations, buildings and ind. tiles