Convoy length calculation bug

[TurfIt]

Did the fixes in Understanding the graphics code: vehicle positioning get undone?

[Ranran(retired)]

Thank you for making me aware of that thread.
I think I have seen the symptoms several times since then.
For example is this a problem with the drawing position of this coach?


I can't remember why I was aware of the symptom...

EDIT: The example seems to have a problem with the coach

EDIT2: I may have seen it with a deliberately reversed EMU/DMU or a Jalapagos customized pakset during patch testing. In that case, it may not be a problem. I think the former was simply caused by the fact that it didn't go through that process. I don't understand if that code does the right thing if the cars are reversed on each car.

[jamespetts]

From what I can see of that thread, reversed vehicle graphics were not implemented at the time. I cannot remember enough of the relevant detail to work out how much work that it would be to implement this, but this is likely to need to be done before convoy recombination.

[jamespetts]

I am taking some early steps to look into this. First of all, it seems that it will not be possible simply to re-use the existing offset code used when defining the vehicle graphics. This is because makeobj combines the offsets with the image dimensions and writes the product of the two into the pak file, effectively pre-calculating and combining the offset with the image itself such that there are no offset calculations performed in Simutrans itself.

Any offset functions will have to be copied from elsewhere or written from scratch. Ranran - are you able to set up a saved game where this can be tested effectively?

I am wondering whether the function used for showing the graphics of vehicles moving along tiles (get_screen_offset()) might be modified or co-opted for the purpose of imparting a new reversing offset. This is particularly relevant since the misalignment that you show in your illustration images shows that that the vehicles are only misaligned along the same axis as they travel, rather than the vertical axis and therefore it should be possible in principle to use the same basic algorithm here to impart a reversing offset of some sort which might be defined at pakset level (and which might programmatically depend on the vehicle length).

Thank you for your help with this.

[Ranran(retired)]

I made a saved game in which the vehicle was forcibly reversed. Please note that this will be restored when it arrives at the next station.
This is because the vehicle can currently be reversed only when the convoy is reversed. But once recombination is possible, such restrictions should disappear.

In the debug build, the reversed vehicle is marked like this.


The britain-pakset does not show much image shift. Certain vehicles show a position mismatch.


However, I think that the vertical direction may not have the previous correction applied.




Next, I think that the previous position correction processing is pak-britain or 128pixel size specific.
Reversing a pak256 vehicle alternatively makes it so terrible. 



saved game for testing is here:
Vehicles are alternately reversed:
https://drive.google.com/open?id=1d5gnRdQ11-WQQjikeAT7Gj8pVB26O-Ht

The vehicle is reversed once every three cars:
https://drive.google.com/open?id=1lDx0FLga7F-eQoVEfMC9kTjaTQbDc6t1

Pak256:
https://drive.google.com/open?id=18-GpZJNX67zLlvviqyYSRXNyhb7qjP0F

[Phystam]

Pak256 doesn't use the offset values for vehicles, but they are aligned only in the image files.
I've never seen such a strange alignment issue.

[Ranran(retired)]

I've never seen such a strange alignment issue.

Please read past posts in the thread.
This is possible if the recombination system is implemented with the current specifications. The experiment.

[jamespetts]

I have been looking into this and have pushed some incomplete testing code to the reversed-vehicle-graphics branch on my Github repository. I have sought to address the problem by providing for reverencing specific offsets for each vehicle direction. I have so far completed only the cardinal directions (some of the ordinal directions did not need any adjusting). For testing purposes, I have hard-coded these numbers calibrated for Pak128.Britain-Ex, but, if this proves to be a workable approach, I will set these up to be user configurable in .dat files or (preferably) simuconf.tab (if I can get these to be universal - see below) or possibly both.

Here are some screenshots of results so far using Ranran's alternate reverse saved game:





However, this approach has not worked well so far for vehicles with greatly differing lengths:





I have found that there was already code to deal with reversed vehicle graphcs:

Code Select Expand


if (veh  &&  veh->is_reversed())
{
adjusted_steps += (VEHICLE_STEPS_PER_TILE / 2 - veh->get_desc()->get_length_in_steps());
}


Here is the relevant part of the code after my adjustments:

Code Select Expand


void vehicle_base_t::get_screen_offset( int &xoff, int &yoff, const sint16 raster_width ) const
{
sint32 adjusted_steps = steps;
const vehicle_t* veh = obj_cast<vehicle_t>(this);
const int dir = ribi_t::get_dir(get_direction());
if (veh  &&  veh->is_reversed())
{
adjusted_steps += (VEHICLE_STEPS_PER_TILE / 2 - veh->get_desc()->get_length_in_steps());
adjusted_steps += reverse_base_offsets[dir][2];
}

// vehicles needs finer steps to appear smoother
sint32 display_steps = (uint32)adjusted_steps*(uint16)raster_width;

if(dx && dy) {
display_steps &= 0xFFFFFC00;
}
else {
display_steps = (display_steps*diagonal_multiplier)>>10;
}

xoff += (display_steps*dx) >> 10;
yoff += ((display_steps*dy) >> 10) + (get_hoff(raster_width)) / (4 * 16);

if (veh && veh->is_reversed())
{
xoff += tile_raster_scale_x(reverse_base_offsets[dir][0], raster_width);
yoff += tile_raster_scale_y(reverse_base_offsets[dir][1], raster_width);
}

if(  drives_on_left  ) {
xoff += tile_raster_scale_x( driveleft_base_offsets[dir][0], raster_width );
yoff += tile_raster_scale_y( driveleft_base_offsets[dir][1], raster_width );
}
}


Code Select Expand


static sint8 reverse_base_offsets[8][3] =
{
{ 4, -1, 34 },
{ -1, 0, 2 },
{ 0, 0, 0 },
{ 0, 0, 0 },
{ -1, 0, 14 },
{ -3, -2, 32 },
{ 0, 0, 0 },
{ 0, 0, 0 }
};


I have borrowed the general scheme of the code for the system for driving on the left offsets (initial attempts not using this system resulted in inconsistent results depending on the zoom level). However, I had to add a third parameter to deal with position along the length of the vehicle, as this seems to be adjusted separately.

I wonder whether this last parameter is responsible for the inconsistent spacing of much shorter vehicles, although it is hard to tell without more detailed testing.

If anyone has any insight into this graphics code that might assist with this process, this would be much appreciated.

[jamespetts]

I have been doing some more experimenting with this, and it seems that my conclusion in the previous post about vehicle length affecting the correctness of the spacing was incorrect. Having tried a number of algorithms in which the adjustment spacing was scaled with the length of the vehicle, I found that these all produced thoroughly inconsistent results, whereas the original algorithm (above) in which spacing did not scale with the length of the vehicle produced mostly consistent results, even with vehicles of differing lengths, but with a few anomalies.

I therefore investigated some of the individual anomalies. One of the most noticeable was in the container flat wagons in the freight train:



As can be seen, alternating wagons are noticeably inconsistent with one another. However, I noticed that this wagon was using older graphics and had not been re-rendered with the new transparent system. After re-rendering, the spacings are now consistent:



(I have pushed the re-rendered wagons to the master branch of the pakset as these are graphically preferable to the previous wagons in any event).

I have also looked into the LNER EM1 (the black and green electric locomotives). I found that these were significantly different in their position depending on their livery. I have re-rendered a number of these to be in a correct position, and, then finding that the length was too great, shortened this, and I now get a much more consistent appearance with these locomotives, without the large gap that previously existed.

The locomotive in the train pictured above, the BR Class 21, is unfortunately a locomotive for which .blend files are not available. I believe that this was produced by Junna some years ago; I wonder whether Junna might be able to find the graphics of this and other locomotives which were produced some time ago so that I can re-render these with the new transparent workflow?

Ranran - with the proviso that I have not yet coded the ordinal directions and that this is currently hardcoded for Pak128.Britain-Ex and not yet customisable, can you test this branch to confirm whether there is a significant improvement in the appearance of reversed graphics? If few anomalies remain, this offset system may be the solution. It would require configuring once per pakset, which might take some work to deduce the correct values, but once that has been done, that should be all the work required of a pakset author.

(You could possibly test this with Pak.256 by editing the values in reverse_base_offsets[][]).

[Ranran(retired)]

I have tested this.

First, it seems that the offset can be specified only with the pakset size specific width, not px.
Probably 64px pakset is 1, 128px pakset is 2, 256px pakset is 4. I think the specification of 4px for 256px pakset is too wide.

James didn't seem to make any adjustments for SE and NW for the Britain-Ex vehicle, but as far as I can see it is off by 9px.

Code Select Expand

{ 4, -1, 34 },
{ -1, 0, 2 },
{ 0, 0, 0 },
{ 0, 4.5, 0 },
{ -1, 0, 14 },
{ -3, -2, 32 },
{ 0, 0, 0 },
{ 0, -4.5, 0 }
So it looks like this, but of course the fractional part is ignored.
We cannot specify 9px, and specifying 4 or 5 will correct the shift, but a shift of 1px will occur.


And with 256size pakset, we can only adjust in 4px increments, so the subtle distortion that results from this will appear as greater distortion.

Pak256 seems to work with this kind of offset (step is not adjusted), but it does not completely eliminate the distortion mentioned above.

Code Select Expand

{ -12, 6, 0 },
{ -12, -6, 0 },
{ -17, 0, 0 },
{ 0, 8, 0 },
{ 12, -6, 0 },
{ 12, 6, 0 },
{ 17, 0, 0 },
{ 0, -8, 0 }


[jamespetts]

Thank you very much for calculating the correct numbers for the ordinal directions: that is very helpful. After some months' break, I have been able to return to this, and have now fully implemented this feature, configurable in simuconf.tab. This will be in to-morrow's nightly build.

Here is an example of the simuconf.tab syntax from Pak128.Britain-Ex:

Code Select Expand

# The below settings give an offset in pixels per direction for each vehicle
# when it is in a reversed state. This allows paksets whose vehicle alignments are
# not fully centered to have vehicles reversing algorithmically and allowing them
# to be properly aligned in game when they are reversed.
#
# By default, all of these values are 0.
#
reverse_base_offset_south = 4, -1, 34
reverse_base_offset_west = -1, 0, 2
reverse_base_offset_southwest = 0, 0, 0
reverse_base_offset_southeast = 0, 4, 0
reverse_base_offset_north = -1, 0, 14
reverse_base_offset_east = -3, -2, 32
reverse_base_offset_northeast = 0, 0, 0
reverse_base_offset_northwest = 0, -4, 0

I should be grateful if people could let me know how this works out, especially for other paksets (e.g. Pak.256 or Pak192.Comic-Ex).