Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 3d7ab09: stopped trains not updating viewport hash when reversed for a second time #9165

merged 1 commit into from
May 1, 2021


Copy link

@mattkimber mattkimber commented May 1, 2021

Motivation / Problem

peter1138 found a problem while investigating a pathfinder issue, which is that stopped/stuck trains do not correctly update their viewport hash and thus partial sprite problems occur. Example image attached.



The viewport hash calculation is set up to use the sprite cache from before the most recent bounding box update. This was done to fix a specific problem:

  • When the vehicle is first placed on the map, it has no valid sprite cache.
  • A valid sprite cache is needed as a starting point, so in this case it is set to the current coordinates.
  • Because this will result in a new vehicle having "no updates" (current position = cached position) and thus not getting a viewport hash calculated, the coordinates from before this update are used.
  • In most situations the coordinates being one vehicle movement step out of date is not noticeable, all that happens is the dirty rectangle is slightly larger than necessary.
  • However, when a vehicle is reversed twice without otherwise moving, the co-ordinates of the train's current position will match the co-ordinates of its position from 2 moves ago, not 1 move ago. This causes the viewport hash to become out of sync with the actual position of the vehicle, and thus vehicles to not be drawn when a region becomes dirty.

This fix corrects the problem by only using the "old" position in the one case it is actually needed, when it contains an invalid coordinate.


I've run my usual series of checks - against the game demonstrating the issue, against some Timberwolf's Trains games from the original PR, against the abuse.grf size-changing train, and against ships doing traversing through rotations of >180 degrees on the spot.

No regressions observed, although these are only visual checks against currently known scenarios.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

  • The bug fix is important enough to be backported? (label: 'backport requested')
  • This PR affects the save game format? (label 'savegame upgrade')
  • This PR affects the GS/AI API? (label 'needs review: Script API')
    • ai_changelog.hpp, gs_changelog.hpp need updating.
    • The compatibility wrappers (compat_*.nut) need updating.
  • This PR affects the NewGRF API? (label 'needs review: NewGRF')

@LordAro LordAro added the backport requested This PR should be backport to current release (RC / stable) label May 1, 2021
@LordAro LordAro requested a review from PeterN May 1, 2021 14:44
Copy link

PeterN commented May 1, 2021

This resolves the issue I experienced.

Copy link

@LordAro LordAro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks fine, no point leaving it lying around waiting

@LordAro LordAro merged commit 67063ce into OpenTTD:master May 1, 2021
rubidium42 pushed a commit to rubidium42/OpenTTD that referenced this pull request May 1, 2021
@LordAro LordAro added backported This PR is backported to a current release (RC / stable) and removed backport requested This PR should be backport to current release (RC / stable) labels May 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
backported This PR is backported to a current release (RC / stable)
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants