News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Roadsigns(Signals) Front- / BackImage Patch

Started by THLeaderH, October 05, 2017, 01:50:36 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

This is the implementation of this topic.
http://forum.simutrans.com/index.php?topic=3725.0

This patch realizes front/back images of roadsigns and signals. I made this patch because of very strong requests by Japanese pak makers.
The patch is r8299 based and can be easily integrated to the nightly trunk. The patch file is attached. Also, the source can be seen on GitHub. https://github.com/teamhimeh/simutrans/tree/add_frontImage_to_roadsign

The new format of a roadsign dat file is as follows.

obj=roadsign
name=test_signal
intro_year=1915
intro_month=1
waytype=track
single_way=0
free_route=0
is_private=0
is_signal=1
is_presignal=0
is_longblocksignal=0
end_of_choose=0
cost=500
Icon=> foo.0.2
Cursor=foo.1.0
Image[0]=foo.6.1
Image[1]=foo.6.2
......
frontImage[0]=foo.5.1
frontImage[1]=foo.5.2
......

"Image[X]" represents back images and "frontImage[X]" represents front images.
To preserve the conventional behavior, a roadsign without frontImage behaves in the conventional way, that means the front/back is automatically set. If you want to set all images as back images, add
no_foreground=1
to the dat file. Of course, roadsigns made with an old version makeobj are drawn in the conventional way.

This patch is so simple, but the benefit of this patch is so huge for pak makers I believe.

Leartin

I know this is not what that patch is about, but what would you think about allowing more different images for signs and signals? Currently, you only have four "directions", pretty much for straight ways. I think it would be beneficial to allow additional graphics for diagonals - especially since with the current system, signals placed on the same diagonal road face different directions depending on which diagonal they are on. If additional graphics for slopes were added as well, one could use signals as markings on the ground - doing that with current signals looks derpy in curves or slopes. Seasons, at least winter, could be nice as well.

I'm not asking for too much, am I?  ??? :-X

THLeaderH

Allowing additional graphics for seasons, diagonals and slopes would be not a small amount of work in the implementation, I think. Also, the pak can be so huge because a pre-signal have 6 status per each direction. If we support the full set, 2(front/back) x 6 (maximum status of a signal) x 4 (direction of a signal) x 4 (situation of a way. normal, gradual slope, steep slope, and diagonal) x 2 (seasonal image. normal and winter) = 384 images are needed.

So currently I'm not thinking about supporting these parameters.

Ves

That is fantastic with back and front image! Thanks!

I would like to know, how difficult would it be to add animation frames to the signals? Lots of lots of signals have blinking lights that is part of their models, but which is simply not possible currently. Also flag men, like the ones in pak Britain, would wave their flag, not just hold it.
A small detail, but it would add much to the appearance!

THLeaderH

Quote from: Ves on October 05, 2017, 09:37:04 AM
I would like to know, how difficult would it be to add animation frames to the signals? Lots of lots of signals have blinking lights that is part of their models, but which is simply not possible currently. Also flag men, like the ones in pak Britain, would wave their flag, not just hold it.
A small detail, but it would add much to the appearance!
It's unknown, but I guess animation frames would be more difficult than supporting slopes and diagonals, and the latter would be a priority.
I'll consider implementing these parameters, but I cannot promise that. So, I want the great developers of this forum to do the code review and consider the integration.

Ters

Quote from: Ves on October 05, 2017, 09:37:04 AM
I would like to know, how difficult would it be to add animation frames to the signals?

It is not just adding animation frames to the signal that might be the problem, but Simutrans appears. to have some assumptions that most of the world is static. If too much is changing in the world, all the redrawing will bog down performance (not technically technically the redrawing, but close enough). That is probably why season changes happen gradually even horizontally.

jamespetts

This looks interesting. THLeaderH - would you be able to assist in integrating your patch into Extended at some point? The signal graphics code has been altered there, so I anticipate that it will not be a simple matter of copying and pasting your code into Extended to make it work; you might have a better idea of how it should work and therefore how to integrate it than I.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

Quote from: jamespetts on October 06, 2017, 12:10:27 PM
This looks interesting. THLeaderH - would you be able to assist in integrating your patch into Extended at some point? The signal graphics code has been altered there, so I anticipate that it will not be a simple matter of copying and pasting your code into Extended to make it work; you might have a better idea of how it should work and therefore how to integrate it than I.
Of course ;D

The most important point of this patch is that we have to draw 4 images since a bi-directional sign draws images of 2 directions. So, we have to override display() and display_after() so that a sign can draw 2 images in each layer.
In the perspective of a dat file, we have to distinguish a old style dat file from a new style one. In this patch, if there is no "frontImage[0]" in the dat file and "no_foreground" is not enabled, the roadsign is treated as a old style sign, that means we have to set back and front in a conventional method. Otherwise, the roadsign is treated as a new style sign, that means we have to set layer as is written in the dat file.

jamespetts

Splendid, thank you. Would you be able to produce an Extended compatible patch (either a conventional .patch or .diff file or a Github branch) once you have perfected the Standard version of this? That would be most helpful.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

Amm... I'm considering supporting diagonals and slopes and I'd like to concentrate on it.

jamespetts

Quote from: THLeaderH on October 06, 2017, 01:16:46 PM
Amm... I'm considering supporting diagonals and slopes and I'd like to concentrate on it.

Ahh, I imagine that it would make more sense to integrate this into Extended after the diagonal and slope support has been completed in any event.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

I'm implementing diagonal and slope images for a roadsign and I need a test pak of a roadsign and a signal. However, I do not have a technique to make images so I can't make a roadsign with slope and diagonal images!
Then, I write about how to write the dat file and hope someone makes the roadsign!

Private signs and traffic signals cannot have slope and diagonal images. Traffic signals can be placed only on a n intersection tile, so there is no meaning to have diagonal and slope images. Private signs have a different image direction pattern from others, so it's not supported. Of course traffic signals and private signs can be made with the conventional image definition.


obj=roadsign
name=SIS_signal
intro_year=1915
intro_month=1
waytype=track
single_way=0
free_route=0
is_private=0
is_signal=1
is_presignal=0
is_longblocksignal=0
end_of_choose=0
offset_left=0
cost=500
Icon=>
Cursor=

The first part has nothing different from the conventional definition.
However, the image definition is quite different.

#flat tile(not diagonal or slope)
#Image[state][direction][snow]
Image[0][N][0]=
Image[0][S][0]=
Image[0][W][0]=
Image[0][E][0]=
Image[1][N][0]=
Image[1][S][0]=
Image[1][W][0]=
Image[1][E][0]=

state is 0 only for signs. In the case of a railway signal, state 0 is red light and state 1 is green light. 2 and 3 is for non-electrified track. In the case of a railway pre-signal, state 0 is red light, state 1 is green light, state 2 is the situation that there is a train two blocks front of this train. 3, 4, and 5 is for non-electrified track.
The snow parameter should be 1 when the image is for winter. Otherwise, should be 0.
Direction [N] means the sign is heading to north.


#Diagonal
Diagonal[0][SW][0]=
Diagonal[0][WS][0]=
Diagonal[0][NW][0]=
Diagonal[0][WN][0]=
Diagonal[0][NE][0]=
Diagonal[0][EN][0]=
Diagonal[0][SE][0]=
Diagonal[0][ES][0]=

Diagonal[1][SW][0]=
Diagonal[1][WS][0]=
Diagonal[1][NW][0]=
Diagonal[1][WN][0]=
Diagonal[1][NE][0]=
Diagonal[1][EN][0]=
Diagonal[1][SE][0]=
Diagonal[1][ES][0]=

The state and snow parameter is same as a flat tile.
There are 8 directions. [SW] means the sign is heading to west and the way is connected to south and west. [EN] means the sign is heading to north and the way is connected to east and north.


#Slope
ImageUp[0][3][0]=
ImageUp[0][6][0]=
ImageUp[0][9][0]=
ImageUp[0][12][0]=
ImageUp[1][3][0]=
........(omitted)

ImageUp2[0][3][0]=
ImageUp2[0][6][0]=
ImageUp2[0][9][0]=
ImageUp2[0][12][0]=
ImageUp2[1][3][0]=
........(omitted)

ImageDown[0][3][0]=
ImageDown[0][6][0]=
ImageDown[0][9][0]=
ImageDown[0][12][0]=
ImageDown[1][3][0]=
........(omitted)

ImageDown2[0][3][0]=
ImageDown2[0][6][0]=
ImageDown2[0][9][0]=
ImageDown2[0][12][0]=
ImageDown2[1][3][0]=
........(omitted)

I omitted definitions for state 1. Slope has 4 directions, 3,6,9, and 12. It's same as a way and a wayobj.
If the sign is heading to the direction that the way climbs up, it's ImageUp or ImageUp2. If the sign is heading to the direction that the way goes down, it's ImageDown or ImageDown2. Half slope is considered.

When you use front images, Image, Diagonal, and ImageDown become frontImage, frontDiagonal, frontImageDown.

I hope someone makes  a test roadsign pak that has winter images and diagonal and slope images!

Leartin

Is it fine if it's done in the 192-size I'm accustomed to, or do you need it in 128? Is it fine if different signs/signals use different things, or is one sign that does all required?



And by the way, since you do both two-lane roads and signals: Would it make sense to you if a two-lane monodirectional road would show each sign on both sides of the road, making use of the code used for signals on left?

THLeaderH

If it's made in the 192-size, I'd appreciate and use it. It's OK if different signs/signals use different things.
I do not think that it makes sense to show each sign on both sides of the road on oneway mode road, since the example of that in the real world is not so many, as far as I know.

THLeaderH

I suggest that the first version should be integrated to the trunk once. There are some reasons to do so.

  • 3 weeks have passed since I asked everyone to provide a roadsign for testing but no one did so. This shows that roadsigns with diagonal, slope and seasonal images are too complicated for most pak authors. It seems that there are not so big demand for the roadsign with slope and diagonal images.
  • The diff file that supports diagonal and slope images is longer and more complicated compared to the file that supports only front and back images. Also it contains some tricky codes. Integrating the first version makes the code review much easier and simpler.
Although I don't give up to implement diagonal and slope images for roadsigns, IMO, the first version, that supports only front and back images, should be integrated once to give pak authors the benefit of this patch as soon as possible. It's not too late to support diagonal and slope images after the stable version that supports only front and back images is distributed. I have to say that when the patch with slope and diagonal images is completed is completely unknown. Please note that the branch on GitHub has some new commits since I released the first version.

prissi

Sorry, why changing this? Which bug or issue is addressed with this patch? Does this handle the automatic swapping of signs and signal any better?

I am not against changing stuff, but some arguments why it should be included would be nice. (I mean beyond strong requests by somebody). Especially when it breaks the documentation and need manual intervention when building the next paksets (which are the slowest part to update for Simutrans.)

So if there are good enough reason (and the latest patch file), yes it can be integrated. But as it stands now, it is just breaking a decently working system without a reason to do so.

THLeaderH

#16
Current simutrans sets front or back of a image automatically and this cause the problem that is described by the attached image. This patch solve the problem by supporting front and back images by pak authors. This patch enables accurate graphic expression of a roadsign.

Also there are some tweets that describes the problem of the current simutrans.
https://twitter.com/Ebi_Simu/status/915552863882960896
https://twitter.com/Ebi_Simu/status/915563658205216770

prissi

But all these are illegal roadsigns by Simutrans standards, since the cannot change to left side driving automatically. This is better done with a special way with front and backimage, since these would not change between left and right side driving.

Hmm, at least I see the motivation.

THLeaderH

Quote from: prissi on November 01, 2017, 12:54:38 PM
But all these are illegal roadsigns by Simutrans standards, since the cannot change to left side driving automatically. This is better done with a special way with front and backimage, since these would not change between left and right side driving.

The current roadsign system cannot draw the roadsign like this image correctly. This type of roadsign has an architecture like arch and with no doubt requires front and back images to draw accurately. It's odd for this road sign to be treated as a "way" in a game, isn't it?

Leartin

Sorry, I completely forgot to provide graphics for diagonals and slopes.

The issue prissi mentions is that there is an option in the game to automatically reposition signs for driving on the left lane. This would not be possible with overhead signs, so you get two 'competing' features, that don't play well with each other.

But these overhead type of signs are pretty much only seen in roads with multiple lanes in one direction, since signs to the side could be covered by cars on the other lanes.

Instead of using frontimage and backimage, define "drive_on_left" and "drive_on_right" versions of signs. Since this does not clash with any other feature, it would have high chances to be accepted.
With that, all you need to do is having a road with two lanes in the same direction use both signs. This would not require side-specific signs, since the offset-signs could be used as well (and yes, if it's not overhead signs, they often appear on both sides of the road simultanously).

So when you build a two-lane-road with your other patch, both the left sign and the right sign will be combined to form the full arch - no matter if you drive on the left lane or the right lane. You'd achieve the arches, while the game code would not 'contradict' itself. You can't exactly get them for normal roads, but at least overhanging would be less of an issue.


This is just a suggestion, since both patches on their own are innocent enough that there probably would not be a veto against them, and are useful beside what you try to achieve.

HyperSim

Quote from: prissi on November 01, 2017, 12:54:38 PM
But all these are illegal roadsigns by Simutrans standards, since the cannot change to left side driving automatically. This is better done with a special way with front and backimage, since these would not change between left and right side driving.

I give another example.
See the picture attached.  This is the official oneway road sign in pak128 with right-side driving.  The bus runs over the road sign!
Other one way signs in pak128 have these kind of image problem.
I checked other paksets and it seems that only pak128 has these problem.
But it is enough to motivate us to implement front/back image for road sign.

prissi

Sorry, also that sign is illegal for a one way sign as it would not survive conversion to left hand driving. Pak128 has done a lot of stuff, and is badly maintained and balanced and thus is not an official set by far. (never mind its popularity.)

I will look at that patch, and if it can be properly done with left and right side driving then it can go in.

THLeaderH

I'm sorry for not understanding well how the goal be achieved by the "drive_on_left and drive_on_right concept".
Yes, using front/back images and conversion to left hand driving at the same time brings a odd result. Setting front images means that the author of the roadsign defines the relation of front and back, so is it enough that roadsigns with front images set offset_left=0 ?

prissi

I think, such non convertible sings should get a new flag, since we anyway overhaul the signs. (no_conversion_to_left or so). That would solve also the hack with private signs.

Ters

Wouldn't that deprive those who drive on the other side of the road of a whole bunch of signs? They would at the very least need a complimentary flag that says that a particular sign is for drive-on-left only with no conversion to right so that they can make their own replacements.

Leartin

Quote from: Ters on November 06, 2017, 06:51:09 AM
Wouldn't that deprive those who drive on the other side of the road of a whole bunch of signs?

Not quite, the idea is not that the sign can't be used with drive_on_left, but that it does not change position. In case of something like the one-way road sign in p128, where the sign is on both sides of the road already, no conversion is needed, since the left-version would/should look exactly the same. The same is true for an arch over the road with overhead signs.

What you are thinking of is having an additional version of the same sign for use in drive_on_left. Like, a semaphore which is not only placed on the left side of the track, but also 'stretches' to the left side, kind of mirrored, like (at least some) british signals do. Which I'd prefer too, but does not solve everything either.

The example THLeaderH gave earlier was an highway exit to the left, which makes sense in drive_on_left. If you play drive_on_right, you'd naturally want an highway exit to the right. But no matter how smart the game was, this could not be automated. Whoever created the highway exit to the left would have to actually create a highway exit to the right in some way or another. And vice versa. That's not something the game could do for you, that would need to happen in the minds of the artists. Though then again, the same issue is seen in a lot more objects, where there is no solution either.

Ves

Ok, I have now made a signal which will would test the following parameters:

* 8 rotations
* Slope up/down, both shallow and steep hill
* Backimage and Frontimage
* Need to be able to swap between drive-on-right and drive-on-left.

The signal represents a standard stopsignal, with ERTMS-balliser between the rails. The signal should be frontimage/backimage dependent on where it is located, but the balliser should be permanently backimage.
When looking at the image, you will find four (very long) rows. The topmost row consist the STOP state of the signal, the second row holds the CLEAR state of the signal. The third row is to be ignored for now, but the fourth row consist the balliser to be put between the rails.
Looking in the image with the comments, I have put example-track underneath the signal, and also painted the balliser on the tracks, so you can see how the signal is intended to look.

Since the signals need to be on the left side, the last test point is crucial: I was told that the signals need to be painted on the right side of the track, in order to make them in the right position when signals-on-left is checked. Since I dont plan these signals to ever be placed on the right side of the track, I dont mind if they are locked to be left side signals, we only need to be told how to make it properly.
It would, however, be quite a nice implementation if they could swap sides.

For the 4 new rotations (the diagonals) I did not know where to put the signals, so I decided to put them at the centre of the tile, but still with the correct distance to, and on the right side of the rail. See the screenshoot with the comments.

I hope that this is usefull in the further development of the patch. I have not provided any dat-file, since I have not had any time to look into it and create one. Hopefully you can use the image anyway, and dechiffer how I have placed the signals.

Two suggestions how to make this signal work with left-right hand version, but I dont know if it would work for all kinds of signals:
1) - Specify in the dat wether an image is supposed to change position or not. Specify it as a [ 1 ] directly in the image definition. In my signal, the image definitions that shows the signal would have [ 1 ], while the balliser would have [ 0 ], since the balliser is already at the center between left and right.

2) - The advanced version: In combination with the above, also specify in pixels, the amount of pixels that this image currently is offset from the center of the track. To make it a bit easier, the "vehicle_step" mechanism could be used, which groups pixels in steps of 4. Alternatively, and preferably, a step of 2 makes for better finetuning. A negative value could principally be used to put signs painted on the left side, go to the right side if "signals_on_left" is ticked.
To use the highway sign that has been presented in this thread as an example:
The pole and overhead would be painted on different images.
The pole would have a "signal_step" of, say, 12, but the overhang would only have a signal_step value of, say 5. This would mean that, when the signals_on_left is ticked, the pole would move 12 steps on the other side of the road, but the overhang would only move 5 steps on the other side, hopefully connecting to the pole and looking good in both conditions.
If raized track or road is a problem, a new simuconf parameter for each waytype: track_height= 0/default (center of track=center of tile), 1/raized 1 pixel, etc..

The png-file to use:

The same png-file, but with comments and visualisation:

Leartin

Quote from: Ves on November 07, 2017, 12:43:23 AM
For the 4 new rotations (the diagonals) I did not know where to put the signals, so I decided to put them at the centre of the tile, but still with the correct distance to, and on the right side of the rail. See the screenshoot with the comments.

I'd leave the position where it was before, just turned 45° to be seen from "front" and "side". Also, I think you forgot that each of the diagonals goes both ways - north-east as well as east-north, south-west as well as west-south. Though it would use the same graphics with a different offset.

Ves

But then you will have to paint the diagonal signals twice? As they are in my png there is one of each direction of diagonal.
But maybe you are right that they should be placed on an edge like before, then the same coda as the "signals_on_left"- code could do the offsets.
I have not considered corners in this png, as I did not intend to make corner signals out of these. Someone else maybe have an idea for corner signs/signals to be put in a png?

Leartin

Quote from: Ves on November 07, 2017, 01:37:26 PM
But then you will have to paint the diagonal signals twice? As they are in my png there is one of each direction of diagonal.
Yes, exactly. Each tile needs each signal twice, since you are supposed to be able to place each signal on both sides of the way. Think about it this way: If you look at your 6th column - what would happen if you clicked with the signal tool again? Shouldn't the same signal as in the 7th column appear?

The Idea is to allow additional graphics. Eg. all your slopes are the exact same signal, just in a slightly different position. The game code currently knows how to position signals on slopes, so there should be no need for them - not counting different states, this signal should only need 8 graphics for the 8 directions, while the game code should position it (as it already does)
The slopes would only be needed if you want a signal with markings on the ground, such that those can follow the same steepness.

Ves

The slope graphics are indeed different to each other. Remember that the signal is composited by the ballisers and the signal, and it is the balliser that are changing appearance dependent on slope.
If THLeaderH need a testsignal with balliser and signal in one image (as a test, without considering front and backimage), I will correct the png to do that.

Hmm, yes I see your point about the placement, but maybe THLeaderH had a solution in mind to help minimize the duplication of signals?
Anyway, I will change it if it is needed :)

OrangeSkin325

I just pass through here. I think it is a great idea. May I ask is there any changes for the nightly version using this concept?
I love Hong Kong very much!
我真係好撚中意香港!
http://graphics.simutrans.com/displayimage.php?pid=635