News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

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

Started by THLeaderH, November 15, 2021, 03:03:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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.

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.

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.

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.

QuoteFinally, 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


prissi