Image definition syntax renewal for road signs, traffic lights and signals

[THLeaderH]

This topic is derived from https://forum.simutrans.com/index.php/topic,21202.msg197772.html#msg197772

Summary
The image definition syntax should be changed from `Image[1]=...` style to `Image[E][0]=...` style to make the meanings clear.

Motivation
Images for road signs are defined with number, but this is not a friendly way to define the images. For example, a priority signal can have 24 images and the definition is given with `Image[0]` - `Image[23]` set. However, the meaning of the image number is not so clear for addon authors.

So, Splitting the definitoin into state and direction makes the meaning more clearer. Also, this is a preparation for the implementation of diagonal images, since we will define the diagonal images with `Diagonal[NE][0]` syntax.

Expected Behavior
Generally, the syntax should be `Image[direction][state number]`. The state number of direction format is different for each category of the sign/signal addon. The conventional syntax with number only should be preserved for the compatibility and we can implement a conversion logic.

1) Generic road signs
- direction ... {N|S|E|W}
- state number ... 0 only.
Generic road signs does not have a variation of state. The image definition should be like this.

Code Select Expand


Image[N][0]=...
Image[S][0]=...
Image[E][0]=...
Image[W][0]=...


2) Normal and choose signal (railway)
- direction ... {N|S|E|W}
- state number ... 0=red state, 1=green state, 2=red state for non-electrified truck (optional), 3=green state for non-electrified truck (optional)
The image definition should be like this.

Code Select Expand


Image[N][0]=...
Image[S][0]=...
Image[E][0]=...
Image[W][0]=...
Image[N][1]=...
Image[S][1]=...
Image[E][1]=...
Image[W][1]=...


3) Pre signal and priority signal (railway)
- direction ... {N|S|E|W}
- state number ... 0=red state, 1=green state, 2=yellow state, 3=red state for non-electrified truck (optional), 4=green state for non-electrified truck (optional), 5=yellow state for non-electrified truck (optional)

4) road traffic light
- direction ... {N|S|E|W|NE|NW|SE|SW}
- state number ... 0=red state, 1=green state, 2=yellow state.

5) private sign
- direction ... {NS|EW}
- state number ... 0=closed, 1=open.
The image definition should be like this.

Code Select Expand


Image[NS][0]=...
Image[EW][0]=...
Image[NS][1]=...
Image[EW][1]=...


[prissi]

I think traffic lights could also have the same definition, i.e. image[0][N] for red [1] for green and 2 for yellow/amber.  And image[NE|NW|SE|SW] for the double directions. That allows easy switching to left side traffic while keeping the code the same.

Personally, I feel the direction is most important, so order like [N][0]; on the other hand, the state entry list is likely shorter, so lookup in the order of [ 0][N] might be faster.

Finally, I would not worry about compatibility. One can always use an older makeobj to build old files.

EDIT:
Traffic lights could do with N|S|E|W with front and images only. But these would need special drawing routines to draw more than one font/back images per obj_t.

[THLeaderH]

Writing the direction first sounds good, since a way defines the images in `Image[direction][snow or not]` syntax. I edited the original proposal to put the direction letter first.

As for traffic lights, I think we should continue to require Image[NE|NW|SE|SW]. If we compose a traffic light image only with Image[N|E|S|W], since each direction will have two (front and back) images, we may have to draw 8 layers and that may affect drawing performance.

Finally, I would not worry about compatibility. One can always use an older makeobj to build old files.

So can I remove the code for parsing the image definitons in the old syntax with only numbers?

[prissi]

If the new name is just a translation, I would keep them. However, if proper fore- and background images are needed or the traffic light system is changed, then I would remove it. Since the traffic light is kept the same, I would say to leave them for now.

[THLeaderH]

I think the image definition for a traffic light shoud be kept the same, which means the author still has to specify images for [NE|NW|SE|SW] directions.
Therefore, the new syntax is just a translation of old syntax. I will keep the old parsing logic.

EDIT: I edited the original proposal post to add the definition for a private signal.

[prissi]

The traffic lights can also have a yellow state to clear the crossing. So there could be state 2 as well.

I think this is very good, so now makeobj can meaningful warn: "No image[NE][1] found!" instead producing a broken pak.

[THLeaderH]

Sorry for making you wait for a long time. Please download the diff file from the link below.
https://github.com/aburch/simutrans/compare/master...teamhimeh:dev/21217.diff

The diff can be seen on a browser from the following link.
https://github.com/aburch/simutrans/compare/master...teamhimeh:dev/21217

This patch does not contain a warning for lacking images.

[prissi]

Sorry, I took my time to look at it.

I found a lot of conversions of const char * into std::string just to test if the first char is zero. Also, in simutrans, we do not use using std or similar stuff. I tried also to generate fatal errors on missing definitions.

Thank you for your work, that will make it much easier for the dat file writers. Incorporated in r10263.

[THLeaderH]

Thank you for incorporation and cleaning up.

[prissi]

Fix in r10538: Order of sign directions in makeobj was wrong