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

Change: Reduce real sprite groups if possible. #9344

merged 2 commits into from Jun 12, 2021


Copy link

@PeterN PeterN commented Jun 9, 2021

Motivation / Problem

Many NewGRF features using Act 3/2/1 chains don't require loading/loaded stages (which are determined by the RealSpriteGroup), however by spec they are still created, and evaluated on every chain resolve.

For features that do use loading/loaded stages, it is also fairly common for the same sprite or callback result to be returned.


This change skips creating a RealSpriteGroup if there is only one result, or if all results are the same.
It also deduplicates the different ResolveReal() resolver function for resolvers which don't care about loading/loaded stages.


The deduplication does not take account of the order of checking loading/loaded results which was previously inconsistent, therefore it's possible that if loading/loaded stages were supplied for a feature that does not expect it, a different result will now be used. But if this is the case then I think NewGRF is out-of-spec anyway.

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')

PeterN added 2 commits Jun 9, 2021
…al sprite groups.

This may change behaviour when multiple loading/loaded stages are provided, as the various copies checked in different orders, however only one result is expected in these cases anyway.
This avoids checking RSG for empty sets every time they are evaluated.
This might alter behaviour in cases of a malformed NewGRF file.
Copy link

@michicc michicc commented Jun 10, 2021

Different result means at worst a different real sprite, right? A different CB chain would be worse, but we never promised bug-for-bug compatibility, so I'd consider a wrong sprite for an out-of-spec GRF quite acceptable.

Copy link
Member Author

@PeterN PeterN commented Jun 11, 2021

In theory this can also affect callback results as a plain action 2 can return callback results (at least our code supports it, whether the spec intends that is another matter)... but:

In fact after checking the NewGRF spec it seems we did it wrong for railtypes and roadtypes (which is fun, because it is our spec) as the code tested loading first then loaded, when the spec says loaded must be 1 and loading must be 0.

@PeterN PeterN merged commit 40cec34 into OpenTTD:master Jun 12, 2021
12 checks passed
@PeterN PeterN deleted the eat-real-sprite-group branch Jun 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants