Add FilenamePattern support to sequences.#21136
Conversation
pchote
force-pushed
the
sequence-patterns
branch
from
b51c7d3 to
221dd86
Compare
|
Thank you for your contribution! |
|
Note that this feature is dealing with filenames before loading the sprite. It doesn't know or care anything about the format of the sprites to be loaded. The testcase could equally well have been loading a set of shp files (if a sprite contains multiple frames it will use the first).
No, this would need to be implemented as its own sprite format rather than as a sequence key, unless the |
RoosterDragon
left a comment
RoosterDragon
left a comment
There was a problem hiding this comment.
One fixup, otherwise LGTM.
pchote
force-pushed
the
sequence-patterns
branch
from
221dd86 to
4706226
Compare
|
Fixed, rebased, and dropped testcase (after verifying the fixes do work). |
|
|
||
| var loadFrames = CalculateFrameIndices(start, length, stride ?? length ?? 0, facings, frames, transpose, reverseFacings, shadowStart); | ||
| yield return new ReservationInfo(filename, loadFrames, frames, location); | ||
| return new[] { new ReservationInfo(filename, loadFrames, frames, location) }; |
There was a problem hiding this comment.
Why did this change? I don't think I like it 🧐
There was a problem hiding this comment.
The old code made the function a generator, which wasn't compatible with the new code added above (which would otherwise have to explicitly loop over the results and yield them). The subclasses already returned explicit enumerables so this allows the same code patterns to be used in all three places.
There was a problem hiding this comment.
Ah, right, the code above. Derp. Still not ideal but ok.
|
Sadly this only covers about 1/3 of my concerns from the discussion that spawned the PR 🙁 (but is fine as a standalone PR) |
pchote
force-pushed
the
sequence-patterns
branch
from
4706226 to
8e04118
Compare
|
Rebased. |
3 participants
Backported from TDHD, this gives modders/mappers a simpler solution for multi-frame pngs.