Multipart/Variable Palette Signal Sprites

[JGR]

Currently TTDPatch uses one sprite per signal type, consequently as the number of possible types of signals increases, the number of necessary signal sprites increases exponetially.
There are currently 480 signal sprites in ttdpbase(w).grf
The combinations currently available:
Presignals: none,exit,entrance,combo
Path-based or ordinary.
Light or semaphore.
Drive on left or right (for semaphores).
Red or green.
Eight directions.

Totalling: 512 (some of which are the same, notably left and right hand side light signals, and 32 of which are in original TTD (16 sprites)).

It is inevitable that more lights and symbols will be stuck on signals. Currently restricted signals need somesort of visual differentiation from ordinary ones. (I was thinking of a blue light in place of/underneath the orange PBS light.)

I suggest that signals be seperated into their component parts such that the number of sprites can be reduced.
The 'head' of the signal can be relatively easily seperated from the pole, which would still have the presignal bar drawn onto it.
Light signal heads could be implemented as a series of differently sized (heightwise) sprites to accomodate between 2 and however many required lights, 4,5,6?,7!?.
The light dots could be drawn on by either using a variable sprite palette in the draw function, (ie. the sprite in the GRF file has the dot areas in a specific variable colour), or the GRF could simply specify the sprite offsets where to draw the dots and/or the dot sprites/colour.
For semaphores, one sprite would be needed for each state: red or green, in addition to for each number of coloured lights displayed on it.
The GRF file could specify the offsets for where the post and head sprites should be displayed relative to each other. (Perhaps with the xrel and yrel sprite parameters).
The GRF file could specify this with some sort of Action 5 pseudosprite.

This would make GRF artists lives' easier (hopefully), as they wouldn't have to draw so many almost identical sprites, to support all of the signal types available.

Codewise, it would probably be fairly easy to branch the draw signal code in patches/presigna.asm

If you have any thoughts on the matter please post your opinion. GRF artists/coders, TTDPatch devs and anybody else.
I have already mentioned this to Patchman, and he approves.
I am quite happy to do all of the coding, once a plan has been decided/agreed upon.

JGR

[minime]

Hmm, this is an interesting idea. You're absolutely right about the issue with the number of signal sprites, and it would definitely be worth creating a more sophisticated implementation to reduce it and allow future extensions.

However, it's important to allow a degree of flexibility, especially in the number of lights and the colours used. For example, the CSD signal set contains the following styles of signals:

Where:

• 1. Normal signal
  2. Entry Pre-signal
  3. Exit Pre-signal
  4. Combo Pre-Signal
  5. PBS
  6. Entry Pre-signal + PBS
  7. Exit Pre-signal + PBS
  8. Combo Pre-Signal + PBS

So, looking at the standard and CSD signals, i can think of the following requirements:
For each light signal type define:

• a) A spriteset to use for the pole.
  b) A spriteset to use for the top of the head.
  c) Number of lights.
  d) A spriteset to use for each light.
  e) A spriteset to use for the bottom of the head.

For each signal state (per signal type) define:

• f) The colour of each light.

For semaphores, it would be necessary to define a spriteset for each aspect/state combination in place of requirements d and f.

Furthermore it should be possible to:

• define multiple pole spritesets
  define different shapes of lights
  use any colour for each light (at least red, green, yellow, blue/violet, white, off...)

This is what I can come up with at the moment. Take it more as brainstorming than a request or a solid requirement. However, I think that whatever you do, you should take into account the various styles of railway signaling used around the world and try to retain (at least to some degree) the flexibility allowed by the current, albeit inefficient, system.

Regards,
minime

[stevenh]

*ahem* Signal gantry *ahem*

[minime]

Would you mind being a little more verbose, please? The few results that I get by searching for that yield only an implementation of signal gantry as a waypoint.

I do admit I have not considered implementing signal gantries in my list. As I said, it's no final list. However, aren't those mostly meant for spanning multiple tracks?

[Patchman]

Yes, I think steven_h was suggesting that signal gantries should be supported, if signal graphics are going to be reworked anyway.

I believe however that they'll have the same problem as the electric catenary, namely that it'll simply look strange because the tracks are too far apart.

[WWTBAM]

i dont think it would be that bad if it was drawn properly, as stations with roofs and stairs look fine.

[BobDendry]

station with roofs and stairs are completely different to gantries.

[michael blunck]

It is inevitable that more lights and symbols will be stuck on signals.

Well, that´s the question. From an "ergonomical" point of view even the current load seems to be too much at least for the novice user. I don´t think that adding only a couple of new info bits to signal representations would be a good thing. Let alone the needed graphics for it.

> Currently restricted signals need somesort of visual differentiation from ordinary ones.

Yes, that´s true.

However, I think that whatever you do, you should take into account the various styles of railway signaling used around the world and try to retain (at least to some degree) the flexibility allowed by the current, albeit inefficient, system.

This is a very important point.

regards
Michael

[eis_os]

Consindering the different styles for signals I am not sure. Actually if you create an action based system then you need to do a lot internally to create a signal. So for the a signal change you have to call the internal chain.

How will overwriteing work? As TTDPatch Base GRF should have the signals and other Signal grfs should be able to overwrite it.

While I do like the idea in generally I am not quite sure if it's actually that good in sense of handling internally and perfomance wise.

Ohh and an Action5 based special data sprite system isn't that good. I had to do that decision already with canals, was useing action5 aswell. And reprogrammed that beast to use Action3 then.

So if you really want to have flexibility - I want snow covered signals in the alpine set then! - you will surely need an action 321 based one.

[michael blunck]

> So if you really want to have flexibility [...] you will surely need an action 321 based one.

How would such a system work - performance-wise? Wouldn´t it be much slower than the current one?

regards
Michael

[Patchman]

It would be a little slower, but since it's only used for signals that are on the screen, and only if that section of the screen is updated, the performance impact will be minial, compared to vehicles where this sort of calculation is done for every vehicle on every tick.

[JGR]

Signal gantries and snow covered signals, etc. would require either for the GRF file to define additional sprites for those, and for the drawing code to decide which sprites to use when drawing the signal, or for the GRF to be called when drawing a signal using a varaction 2/callback, along with actions 1&3 as eis_os suggested; some or all of the data could be cached in the landscape array (or elsewhere) to minimise the number of GRF calls required. Bits 0-2 in L6 are unused, as is L7 (although it is planned to eventually be used for abandoned rails).

How will overwriteing work? As TTDPatch Base GRF should have the signals and other Signal grfs should be able to overwrite it.

If the feature is turned off, and/or no GRF file is activated which defines the necessary sprites, etc., then just display the ordinary signals using the existing code.
If the feature is turned on, and a GRF file defines the sprites, etc. required, use that method to display the signal.

For the flexibility aspect it should be fairly easy to simply allow the GRf file to specify for each signal: one or more sprites, which can then be stacked on top of each other (or it could be done by coordinate offsets), and which colours in the palette used should be changed for lights.
The GRF file could first specify the light colour for each 'feature', ie. go=green, stop=red, PBS=orange, etc., such that a colour per light type is specified.
Alternatively, it is probably easier if the GRF file is simply passed the bitmap of which features (lights) should be on, the properties of the signal and landscape properties, (using a var 6x/8x ?), and it selects the appropriate sprites and a recolour pseudosprite (or it modifies an existing one via a variable modification action), or someother mechanism of specifying variable colours. Specifying a sprite for each dot seems unnecessary to me, and a pain due to things like offsets, particularly with variable size signals.
I've notived that the signal sprites in ttdpbase.grf use up to 4 similar colours for the light dots, but this should not be a problem as either 4 colours can be modified per light, or it can be changed to just one colour, as in the CSD set lights shown above, (whose lights look the same).

This is only my ideas on feasible possibilities.

Thanks for your feedback and suggestions on this idea.

JGR

[Patchman]

some or all of the data could be cached in the landscape array (or elsewhere) to minimise the number of GRF calls required.

I don't think caching will be needed. So long as none of the 40+x variables are expensive to compute, the performance impact will be minimal.

Bits 0-2 in L6 are unused

Please don't use those, I plan to implement a mix of PBS/non-PBS signals on a tile using them.

The GRF file could first specify the light colour for each 'feature', ie. go=green, stop=red, PBS=orange, etc., such that a colour per light type is specified.

Don't forget to plan for future multi-aspect signals, at least four aspects should be supported to allow distance signals.

[JGR]

Don't forget to plan for future multi-aspect signals, at least four aspects should be supported to allow distance signals.

I was planning to leave room to support this anyway because it is one of the things which I suspected might be implemented in the future.
As it appears that the general consensus is converging on: 'use GRF callbacks in the draw code, and pass the various signal parameters straight to the GRF so that it can decide on sprites etc.', distant signal states can be passed to the GRF parameters along with all of the other signal states. A bit could be defined for it along with the currently available states, to make it easier when it is implemented.
Other things which I was planning on supporting are different signals for different track types (this is no longer an issue if the GRF specifies sprites), and eventually, as stevenh pointed out, some kind of signal gantry array.

I won't touch bits 0-2 in L6 then.
In fact I'll try and avoid needing to use any of the landscape arrays unless caching is really necessary due to poor performance.

JGR

[minime]

I've just realised there's a slight problem with the demo picture I've posted above (which also explains why our lights use only a single colour) - a few of those lights use the special flashing colour. Specifically, it's the yellow light in entry presignal and the top yellow light in the combo presignal. It would be nice if it would be still possible to use those colours as well.
Although being able to animate the signals would be wonderful (and allow us to get for example flashing green or white), that would problably be an overkill.

I think that if feasible (and from what Josef says it seems to be, at least performance-wise), an action 123 scheme would be preferrable, since it could allow for easier future extension (as opposed to a rather rigid scheme mandated by action 5).

EDIT: In what manner should it be possible to compose multiple sprites? Similar to how sprite layouts are defined for stations or buildings?

[michael blunck]

@JGR

> As it appears that the general consensus is converging on: 'use GRF callbacks [...]

Please, hold on for a moment.

I´m not a patch developer in the sense that I don´t write code for TTDPatch, I´m only a .grf developer.

This would make GRF artists lives' easier (hopefully), as they wouldn't have to draw so many almost identical sprites, to support all of the signal types available.

Because I´m involved in .grf developing since a rather long time, I don´t think I´ll have severe problems with any new scheme regarding the signals. But please bear in mind that for every .grf author it would be very much easier to copy & paste the various signals together than to use a fairly complex system as you´re approaching right now:

The GRF file could first specify the light colour for each 'feature', ie. go=green, stop=red, PBS=orange, etc., such that a colour per light type is specified.
Alternatively, it is probably easier if the GRF file is simply passed the bitmap of which features (lights) should be on, the properties of the signal and landscape properties, (using a var 6x/8x ?), and it selects the appropriate sprites and a recolour pseudosprite (or it modifies an existing one via a variable modification action), or someother mechanism of specifying variable colours. Specifying a sprite for each dot seems unnecessary to me, and a pain due to things like offsets, particularly with variable size signals.

I don´t think this would be "easier" than to do simple copy&paste work in the .grf authors drawing program. The question is, does the new system have any advantages that the old system, based on action05, does not have? And are these advantages so serious that it outweighs the massive overhead you´re proposing? From what I´ve heard so far, I don´t think so.

These are just questions, I´m not against any new development ...

regards
Michael

[JGR]

minime:

The GRF file can define whatever colour it wants in a sprite, and subsequently ought to be able to specify any colour in a sprite recolour palette (or whatever is eventually implemented).
As for in what manner can multiple sprites be used, I think that it could work like this.
Signal needs drawing.
GRF code is called, the appropriate variables are set to the signal properties and status.
The GRF code checks these variables and defines any number of sprites based upon it.

For example:
GRF code is passed parameter that signal is a South-facing, PBS combo-signal.
GRF file says use sprite X (south-facing post with combo markings) and sprite Y (head with three light spaces on it).
GRF file sets palette to display one green at the top and one orange at the bottom light (for example).

This ought to enable suitable flexibility for GRF authors, practical things like sprite offsets shouldn't be too difficult. The easiest thing in my opinion is simply stack sprites on on top of the other as default behaviour, and for the GRF to set variables for different behaviour.

JGR

EDIT:
Michael:

These changes are not 'serious' in that sense, as they are effectively 'eye-candy'.
Additionally whatever is implemented won't be compulsary, and the old system will still be usable, even for more signal combinations.
Copying and pasting the signals together is fine, but if more combinations of signals, or more types of signals are added, for example: signal gantries as suggested by stevenh and snow signals as suggested by eis_os, then more signal combination then someone (I for one) wants to draw are needed, and some system of applying them differently is needed.
Also, you could still use the new system and pass single sprite signals to the code by simply adding the state flags to the signal sprite list which is appropriate, and returning the value, such that you could have have three sets of single sprite signals for the three track types for example.

As for massive overhead, I will try to keep that to a minimum.

JGR

[DaleStan]

JGR has already covered some of this, but what I was thinking for recolor sprites runs as follows:
Use a single sprite with all lights lit, and then the appropriate recolor map to turn off the unwanted lights. The standard signals (being those found in trg1[r].grf and ttdpbase[w].grf) only require the maps red->black and green->black, but yellow->black should also be supported, and maybe blue->black.
I'm not aware of any particularly good way to draw with multiple recolor sprites, so any combination of the above should also be available, except for the uninteresting cases of no-changes and all->black. (6 maps if three colors are supported, 14 if four are supported.) Some signals (such as "bulls-eye" signals) show multiple colors through the same aperature, so maybe one or two colors should should be allocated for recoloring to "appropriate", whatever that happens to be. This makes for an rather large mess of recolor-maps, though.

As for getting multiple sprites out of a grf file, the vehicle action 2 format could work pretty well, using <num-ent1> as <num-sprites> and ignoring <num-ent2>. Possibly better would be to use both, where the sprites corresponding to <num-ent1> get the above mentioned recoloring and those corresponding to <num-ent2> do not. Another option would be to set variable 10 to FF, and use the callback return as the number of sprites. Then set 10 to each value from 00 up to the returned value, and draw each sprite as it is returned.

The commonly used recolor sprites should probably be included in ttdpbase[w].grf, and there should be a decent way of adding new ones. One solution for colormap selection would be to set var 10 to FE and call. If a action 1 sprite is returned, it is to be interpreted as the recolor map to use, but if a callback result is returned, it is interpreted as an instruction to use a certain sprite for recoloring. If it is necessary to have more control over which sprites get recolored (or how) than the above vehicle action 2 system provides, then a variant of the house/industry tile action 2 should probably be used instead.

Action1's <num-ent> could be used to select according to aspect -- if <num-ent> is 2 or more, the first is used when the signal is red and the second when the signal is green. This provides guaranteed graceful degradation for future additional aspects[0], but it also requires that support posts, which don't vary by signal aspect, appear the same number of times as the signals proper, which do.


[0] Varaction 2 based solutions require a more thought to make the same guarantee, but this should not be a major issue.

[eis_os]

TTD(Patch) can't draw with multiply recoloring, for two CC we have additional recoloring tables (that include both)

[michael blunck]

@JGR

Copying and pasting the signals together is fine, but if more combinations of signals, or more types of signals are added, for example: signal gantries as suggested by stevenh and snow signals as suggested by eis_os, then more signal combination then someone (I for one) wants to draw are needed, and some system of applying them differently is needed.

Maybe you don´t get me right, so let me recall that I don´t think an "expontial explosion" (aka "more signal combination then someone (I for one) wants to draw") could or should happen with TTDPatch´s signal scheme. Simply because there´s no good reason to complicate signals even further than it is now (combinations of three layers) [O/c, "restricted signals have still to be dealt with].

Adding more layers than - say four - would begin to turn into a nightmare for users. Is there any reason to make signalling in TTD at least as complicated as in real life? Some people here occasionally point out that it´s still a game, not a simulator where you´ll have to have engineer´s knowledge to get the signalling right.

And after all, either by the old system or by a fancy multi-sprite systen: you´ll have difficulties to put all those many new layers on such a very small area as a signal graphics in TTD is. So much for the "expontial explosion" argument.

So anyway, there´s no use in talking about "more signal combination then someone (I for one) wants to draw": you´re grossly overestimating time for simple copy&paste, graphicswise. Coding the very same thing under any of the new schemes discussed here ATM, would need much more time, than just put it sequentially under action05.

To have alternative representations (snow, gantries, ...) is a totally different kettle of fish, though.

regards
Michael