Fix unconditional insertion of zero-filled tile at start of tileset without map

[Fralacticus]

Objective

Change tileset generation with maps to avoid unconditional zero-filled tiles at tileset start.

Reason for change

When generating a tileset with a map, Grit always prepends a zero-filled tile (tile index 0) to the tileset, even when the source image does not contain any zero-filled tile.

This implicit tile does not correspond to any data in the input image.

Why this is a problem

• It artificially increases the tileset size by one tile.
• It breaks the expectation that tilesets generated from images strictly reflect the source data.
• It can cause unexpected tile count overflows, most critically for affine_bg (hard 256-tile limit), but also for any workflow relying on precise tile counts.
• It introduces inconsistent behavior compared to tileset generation without a map, where no implicit zero-filled tile is added.

Testing

Tested with various sizes, including the 256-tile affine_bg limit case.

[WinterMute]

The zero filled tile is added to ensure that a blank, transparent tile is available as index 0 in the tileset. This is useful for games/applications that generate multilayer maps and some other cases I've long forgotten. It allows maps to be cleared using a simple zero fill rather than worrying about where the transparent tile (assuming it exists) occurs in the tileset. Rather than unconditionally removing this feature it would probably be better to add an option to the command line asking grit to not add this tile for your use case.

[Fralacticus]

Thanks for the explanation. I’ll take a look at whether adding a command-line option to control the zero-filled tile would cleanly fit into your existing codebase, let me know if you’d prefer to handle it yourself.

If you have any guidance or suggestions, I’m happy to take them.