The International Simutrans Forum

 

Author Topic: Convoy length calculation bug  (Read 2781 times)

0 Members and 1 Guest are viewing this topic.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1347
Re: Convoy length calculation bug
« Reply #35 on: May 13, 2020, 11:31:52 PM »

Offline Ranran

  • Devotee
  • *
  • Posts: 997
  • Languages: ja
Re: Convoy length calculation bug
« Reply #36 on: May 14, 2020, 12:21:08 AM »
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.
« Last Edit: May 14, 2020, 12:47:02 AM by Ranran »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy length calculation bug
« Reply #37 on: May 14, 2020, 04:02:04 PM »
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy length calculation bug
« Reply #38 on: May 30, 2020, 12:46:39 AM »
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.

Offline Ranran

  • Devotee
  • *
  • Posts: 997
  • Languages: ja
Re: Convoy length calculation bug
« Reply #39 on: May 30, 2020, 06:03:11 AM »
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
« Last Edit: May 30, 2020, 06:18:33 AM by Ranran »

Offline Phystam

  • Devotee
  • *
  • Posts: 431
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Convoy length calculation bug
« Reply #40 on: May 31, 2020, 11:08:54 PM »
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.

Offline Ranran

  • Devotee
  • *
  • Posts: 997
  • Languages: ja
Re: Convoy length calculation bug
« Reply #41 on: June 01, 2020, 03:09:08 AM »
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy length calculation bug
« Reply #42 on: June 08, 2020, 09:42:43 PM »
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]
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]
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]
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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Convoy length calculation bug
« Reply #43 on: June 10, 2020, 01:14:04 AM »
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[][]).

Offline Ranran

  • Devotee
  • *
  • Posts: 997
  • Languages: ja
Re: Convoy length calculation bug
« Reply #44 on: June 16, 2020, 09:41:13 AM »
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]
{ 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]
{ -12, 6, 0 },
{ -12, -6, 0 },
{ -17, 0, 0 },
{ 0, 8, 0 },
{ 12, -6, 0 },
{ 12, 6, 0 },
{ 17, 0, 0 },
{ 0, -8, 0 }