To defend authors against mixing Windows / DOS palettes in the same grf, nmlc will open all sprite files from the filesystem and validate their palette. This is a separate step to sprite encoding.
For certain cases, this is of no benefit, and just increases compile times. For example, with Iron Horse:
sprites are generated via a separate PIL compile step prior to nmlc
the DOS palette is set during that sprite generation step as a necessary part of creating paletted image files
therefore the subsequent nmlc check is redundant
The nmlc palette check adds 1s to 2s to every Iron Horse compile for me, which is 5% to 10% of total compile time.
I previously tried to solve this in #254, by inferring when the sprites might not need processed, but that route was not viable, as it depended too much on assuming that we don't want validation if we're outputting nfo.
This route provides an explicit arg flag for authors to suppress validation.
The names of the flag and option probably are too long and not the best choice.
To defend authors against mixing Windows / DOS palettes in the same grf, nmlc will open all sprite files from the filesystem and validate their palette. This is a separate step to sprite encoding.
For certain cases, this is of no benefit, and just increases compile times. For example, with Iron Horse:
The nmlc palette check adds 1s to 2s to every Iron Horse compile for me, which is 5% to 10% of total compile time.
I previously tried to solve this in #254, by inferring when the sprites might not need processed, but that route was not viable, as it depended too much on assuming that we don't want validation if we're outputting nfo.
This route provides an explicit arg flag for authors to suppress validation.
The names of the flag and option probably are too long and not the best choice.