![]() In case for example 2 name value pairs with the same value format were inverted it would not fail but on the other hand, the fact that the parsing was so rigid was adding some kind of indirect validation (it would fail with missing properties, unexpected formats, etc.). ![]() I have not yet tested it yet (I will) but design wise I have a concern related to atlas file format especification and validation.īefore the change validation of correctness was not great and seemed to be based on reading line by line and, if I'm not wrong, as long as the value was in the expected format it would assign it the the expected field. I like the spirit of the change, it makes the atlas format more flexible and smarter. However, note that since the texture packer now omits fields that older TextureAtlas code won't be able to read the new atlas files. This PR can still read all previously created texture atlas files. I didn't bother to add name/value pairs to each page, as I'm not sure there are use cases that need it. We could use this in the unpacker to unpremultiply the alpha. This PR also adds a pma field for each page. I lean toward the name/value pairs, like splits and pads, rather than adding fields that are often unused.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |