Feature Request #4046
Reuse real sprites in container 2 GRFs
| Status: | New | Start date: | 2012-06-30 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
With GRF container version 2, one real sprite stored in the sprite section can be referenced multiple times from the data section. Exposing this mechanism to NML could reduce GRF size and cut down on encoding time in cases where identical real sprites are used more than once.
A simple implementation would allow manually referencing a real sprite already defined elsewhere. A more complex implementation could have nmlc track all already encoded sprites (e.g. by source file/image rect/offset) which it could then use to insert a reference if the identical sprite is provided a second time.
History
#1 Updated by Hirundo over 8 years ago
Since real sprites are now cached, the encoding-time is a non-issue.
A comment by michi_cc on IRC:
Under the assumption that "finished" GRFs usually don't contain many duplicate sprites there's probably not much use for it. I can think of a minor use case though, if, for whatever reason, you want the same sprites in a spriteset and a replace(new) block (maybe e.g. a railtype GRF, change signals just for this railtype or change the default signals).
It would still be nice to have, but not really a high priority. Easiest implementation is probably to implement hash and eq for RealSprite and/or RealSpriteAction and maintain a dictionary of encoded sprites {list_of_sprites (for various bit depths/zoom levels): sprite_number}