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
merged 2 commits into from Jun 12, 2021

Conversation

PeterN
Copy link
Member

@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.

Description

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.

Limitations

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

…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.
@michicc
Copy link
Member

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.

@PeterN
Copy link
Member Author

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
@PeterN PeterN deleted the eat-real-sprite-group branch June 12, 2021 07:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants