You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...the Texture coords for each frame are generated incorrectly as "width/size.w", "height/size.h".
This is because, somewhere in the conversion process, "something.png" is re-generated (into assets_unpacked) as a 256x256 texture file. This causes the Texture coords to be incorrect. They should be calculated as "width/256", "height/256".
Changing the meta to lie about the size of the input image fixes this:
"size": {"w":256,"h":256},
...however, it should be possible to take the expanded size into account when converting the SpriteSheet (i.e., round up to a multiple of 2). If I can figure out where this is done in the code I'll file a pull request.
(Note: I'm aware that I should be generating power-of-2 size images in the first place, but I still think the tool should do the right thing with images it's changing the size of.)
The text was updated successfully, but these errors were encountered:
Hmm... it looks like what's happening here is more complicated: the spritesheet I'm using defaults to "trim: true", so empty space on the left is removed. This creates a situation where scaling to 256 "seems" to fix things. I'm closing this issue until I can track this down better.
Given the following metadata in spritesheet/something.json:
"meta": {
"image": "something.png",
"format": "RGBA8888",
"size": {"w":192,"h":192},
"scale": "1"
}
...the Texture coords for each frame are generated incorrectly as "width/size.w", "height/size.h".
This is because, somewhere in the conversion process, "something.png" is re-generated (into assets_unpacked) as a 256x256 texture file. This causes the Texture coords to be incorrect. They should be calculated as "width/256", "height/256".
Changing the meta to lie about the size of the input image fixes this:
"size": {"w":256,"h":256},
...however, it should be possible to take the expanded size into account when converting the SpriteSheet (i.e., round up to a multiple of 2). If I can figure out where this is done in the code I'll file a pull request.
(Note: I'm aware that I should be generating power-of-2 size images in the first place, but I still think the tool should do the right thing with images it's changing the size of.)
The text was updated successfully, but these errors were encountered: