Multipart/Variable Palette Signal Sprites

[Dave]

From the humble user's point of view (and if I may say so, the user's opinion is surely the highest value here ... maybe):

I really don't want to have to learn the different states of 8, 9 or more types of signals. I know how the current batch of signals work, but if you start implementing crazy things like more signs and stuff to point out which signal is which, it'll appear very confuddling. Of course - that's just ONE user's opinion, but I think the signal could get very visually noisy indeed.

[JGR]

Dave:
Ultimately, how much stuff is displayed on the signal is up to the GRF author.
Not everybody wants all of the information associated with a signal to be displayed on it visually, as well as in the landinfo waindow. (I am the sort of person who would like that though).
This is more about a framework for having:
possibly dynamically composed signals (you probably couldn't tell the difference visually, but it may save GRF authors time/sprites)
type of signals varied at draw time, ie. snowy signals, different signals per different track types, signal gantries even, etc.

Michael:
You have a good point, you obviously are faster and more efficient at drawing stuff than I am. (I am not an artist).
How long it would take to code the actual feature is not that much of an issue. We are not in a hurry.
This is also future expansion for if/when things like four aspect signals, or whatever other kinds of signal visuals are thought up (snowy, gantries, etc.), are done as well.
Even if this is implemented you can still use an action5 and block define all the signal combinations.
If you are worried about overcomplicating the GRF, using single sprites possibly with somesort of choice, for example snowline, still ought to take less than a half dozen simple GRF actions extra.
(I'd rather write more code and draw less sprites, but I don't expect everyone to do it that way)
Features have been added that some people don't like or don't use, either because they don't need it, they don't work as they like/want, or they prefer to use something else. You can either turn it of in your cfg file or just ignore it.
If it turns out that when/if I implement it nobody uses it except me to have weird looking variable signals based on as few sprites as possible , then I don't mind, although that is not the idea.

Dalestan:
I've haven't started looking into the possible syntax of the GRF file, so I'll defer to your judgement...
It's probably easier to get a firm idea of exactly what needs doing first.
About recolor sprites; I think that we should try and stay away from trying to apply large numbers of recolour sprites, as its a pain to keep track of all of them, if there is one for each combination (which is one of the things I'm trying to avoid), and as eis_os says, TTD won't draw with multiple recolour sprites, and if large numbers of recolourings could be done it would probably adversely affect performance.
I haven't actually checked the possibility of this yet, but it ought to be feasible: Just use one recolour sprite, defined in memory would be easier, and set the few values which need to be changed each time, immediately prior to drawing, either by the draw code or by the GRF.
Set the other entries to identities.
This enables the 'bull's eye' signal problem to be avoided, and there are already signals with different colours in the same spot which are otherwise identical, eg. combo signal and PBS combo signal.
This would be neater than juggling recolour sprites.
Still this is only an idea, and may turn out to be hopelessly impractical.
Recolouring should definetely be made optional or off by default, if the entire sprite with the correct state is already available, and the GRF is being used only as a sprite selector.

JGR

[DaleStan]

I haven't actually checked the possibility of this yet, but it ought to be feasible: Just use one recolour sprite, defined in memory would be easier, and set the few values which need to be changed each time, immediately prior to drawing, either by the draw code or by the GRF.

Which values does the grf get asked about, and how?
If we're using recolor sprites for this, they're going to get used a lot, and it seems to me like it's better to sacrifice the memory to a table of recolor sprites than the processor time for lots of table resets.

there are already signals with different colours in the same spot which are otherwise identical, eg. combo signal and PBS combo signal.

Those should probably be done with two different real sprites. If the recolor sprite doesn't substantially reduce the number of real sprites required, it's probably not worth the effort. With the standard signals, the red->black and green->black tables halve the number of required sprites, and adding a yellow->green would remove one out of every three remaining.
Neither of these are really significant if the signals proper are split from the support posts, as that would reduce the number of sprites to 32 (4 per direction) support posts and 48 (3 per direction per aspect) signal sprites. Adding the red->black and green->black colormaps reduce this to 32+24, and adding yellow->green mappings removes an additional 8.

So, I guess what I just finished determining is that is that recoloring might not be worthwhile after all, as long as the sprites get split up in sane ways. And it's definitely not worthwhile for the semaphores, which are probably stuck with 32+48 sprites no matter how it's done.

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 ... requires that support posts, which don't vary by signal aspect, appear the same number of times as the signals proper, which do.

That particular problem can probably be fixed by assigning different IDs to the posts and and signal heads[0], but that leaves the same problem with the split of the PBS vs normal indicator light on the default signals.

Not that this is anywhere near as much of a problem, and even it can be alleviated by defining that ID 00 will be drawn first, then ID 01, then ID 02, and so on, until an IDs returns a callback result, not a sprite set.

[0] Much like canals uses different IDs for watercliffs, locks, dikes, &c.

[JGR]

An experimental commit of this feature has been made, and will subsequently be available in the next nightly.
The following is my 5-minute test GRF file.
It defines light-signals for pre-signals, PBS and restricted states, using two sprties and a recolour table to draw each signal.
It uses the windows palette (whether or not it works in DOS, I have no idea, I assule not).

The signals included in the test GRF are slightly modified versions of those in ttdpbasew.grf. Credits to the TTDPatch graphics team for the graphics, not me. (Michael Blunk in particular, unless I am sadly mistaken.)

[DaleStan]

I believe I understand var 7D, and operations 0E and 0F; in fact, I was sufficiently confident that I documented them.

However, the remainder, I'm not confident on. From what I can tell, things are as follows:
Action 0: N/A
Action 1: ??? Empty allowed?
Action 2: ??? Vehicle format? -- Is it valid to fail the signal callback? Is it valid to return Action 1 sprites, instead of the callback result?
-- Variable 0C: N/A -- always calls the sprite CB?
Action 3: Generic only, no cargo types.
Action 4: N/A
Action 5 type 0E: ??? Any order? Any number of sprites?

I also see three divide-by-0 operations in your NFO, and that concerns me slightly, because I thought that was a clearly invalid operation. Only slightly, because I didn't find them until after I adjusted my local copy of NFORenum.

[JGR]

Dalestan:
Thank you for documenting var 7D and operators 0E and 0F, your documentation is correct. I was too lazy/busy to do that so quickly.

As for the GRF actions, at the moment basically it's like this.
Action 0-1: not used.
Action 2: Callback failures valid; signal drawing code reverts to ordinary signal drawing system.
Action 3: Must be generic.
Action 4: Not used.
Action 5: Any order you like, both real and recolour. Offsets into the sprite block, are set by the action2 using operator 0E.
Other actions not used.

I have noticed that there is a major problem with using action 5s as the sprite source. Namely that only one GRF file can effectively define signal sprites at a time, which kind of defeats the object.
Example:
GRF file 1 define sprites using action five, and a callback which only returns sprites on track type 0, say.
GRF file 2 define sprites using action five, and a callback which only returns sprites on track type 1.
Drawing sprites from GRF callback 1 will use sprites from GRF 2's action 5, which is not good.

So I think that I will end up modifying the code to use action 1s instead of action 5s, as this enables multiple sets of the same type easily.
For simplicity I suspect that I will change the callback to expect/accept action 1 sprite blocks instead of a bit field, and will instead move the bit field callback return value to a operator 0E variable.
Trying to lookup an action 2 cargo id from a calculation result/variable is unfeasible codewise.

As for the divide by zero, this indicates to the code: here that no divide should occur at all, (marginally quicker than a divide by one perhaps?).

Additionally I have noticed a bug in non-PBS, non-restricted, exit presignals, in the GRF I posted above. The pre-signal bar is black not white, due to by mistake with recolour sprites. A new copy of the GRF file and components has been uploaded in place of the previous version in my preceding post.

JGR

[DaleStan]

Ah. Well, I'll see if I have the time to fix NFORenum and the docs, then; I was expecting to be leaving about five minutes ago.

[Patchman]

As for the divide by zero, this indicates to the code: here that no divide should occur at all, (marginally quicker than a divide by one perhaps?).

I don't think you should rely on implementation-specific behaviour like this. For instance, OTTD may well crash in that case. Divide-by-zero is undefined by definition.

If anything, you could change the code to not divide if the argument is 0 or 1.

[JGR]

I can guarantee you that no change will be made to any code on my part between tomorrow, when I leave on holiday and the 7th January, when I return. So you needn't rush to do anything. I suggest that you postpone changing NFORenum or writing any documentation until after the code is finalised and committed, as it may or may not bare resemblance to my design idea as outlined above. I won't try to change NFORenum, as the code looks formiddable and I honestly don't understand how the data files are supposed to work; but I intend to document the whole lot when it's done, stable and I'm happy with it.

JGR

[JGR]

*Digs up old topic*
Apologies also for the double post...

Next version of my test newsignals GRF.
Divide by zero optimisation is gone (no longer necessary since r1642).
Added sprites for programmable signals.
(They look somewhat ugly, I am not an artist...)

Once again:
The signals included in the test GRF are slightly modified versions of those in ttdpbasew.grf. Credits to the TTDPatch graphics team for the graphics, not me. Michael Blunk in particular?

JGR

[wallyweb]

I may be off base here a bit ...
Which signal corresponds with which status?

[JGR]

This GRF only does light signals, semaphores are drawn from the standard sprite block.

Light colours:
red/green - same
orange - PBS (same)
violet - restricted

Base pole:
white vertical bar - entrance
yellow vertical bar - combo
yellow horizontal bar - presignal
blue horizontal bar - programmed signal (normal or pre, treated the same)
blue vertical bar - programmed entrance signal (entrance or combo, treated the same)

Back of signal:
White stripe - PBS
Violet stripe - restricted

Hope that helps...

JGR

EDIT:

Found logic error in NFO code (relatively minor), pre and entrance pre-signals had swapped programmed signal bar sprites.
New GRF will require operator 0x11 from r1651 (made the logic much easier for me...), and is attached to this post.
Fixed error in above paragraph, getting my horizontals and verticals mixed up

EDIT 2:
Corrected error in correction of error.
Non-programmed signals were displayed wrong, (the varaction2 has becme labyrinthine... , I will have to read the GRF docs to simplify it, when it next needs to be changed, or add more operators...)

[JGR]

Test newsignals GRF updated.

Sprites for PBS through reservation one-way signals added.
Single white dot on pole in opposite direction to "normal" signal direction, (ie. the direction PBS reservations can be made straight through). I couldn't think of anything better...

Artists feel free to draw more visually appealing ones. My drawing skills are still terrible...

To notice any difference, r1768 or later, with the tsignals switch activated, must be used.

JGR

My apologies for grave-digging old topics...

[michael blunck]

Sprites for PBS through reservation one-way signals added. [..] My apologies for grave-digging old topics...

This sounds very interesting. I already noticed it on trac but from the scarce documentation there I couldn´t really understand what it´s supposed to do. Could you please write one or two sentences to enlighten me?

regards
Michael

[JGR]

It's basically a partial implementation of some of Tekky's ideas, as from here.

The idea is that a train can pass through specified one-way signals in the opposite direction for normal for a one-way signal.
Hence, as these must be PBS signals, the train reserves a route through the signal and out of the other side, such that a train can never be stopped when heading the opposite side of a signal.
This avoids two trains coming to opposite sides of a two-way signal, causing a deadlock.

A basic example is shown in the screenshot.
The train reserves its path up until the far end of the station platform, such that two trains can never try to head to the same platform from opposite sides.

(This layout is only really useful is you turn on reversing at stations...)

I will have to write some documentation eventually, but not tonight...

JGR

[Ameecher]

Sounds very interesting, I shall have to play around with this one.

[Badger]

I'll be keeping one eye on this topic for a bit....

[DaleStan]

*bump* Any progress on new graphics for inverted signals? Or did I miss the decision that they don't need them?

[JGR]

Just saw your bump...

They will get done eventually.
There are two main reasons for the delay:
1. My procrastinating laziness.
2. My not being able to think of a decent way to represent inverted signals, without it looking daft, (coloured blotch/sign on top of signals perhaps?).

[blitzkrieg]

Just saw your bump...

They will get done eventually.
There are two main reasons for the delay:
1. My procrastinating laziness.
2. My not being able to think of a decent way to represent inverted signals, without it looking daft, (coloured blotch/sign on top of signals perhaps?).

How about just interchanging the position of red & green lights in the signal?