A character can look correct in a pixel editor and fail after import because the receiving tool interprets its coordinates, animation ownership or resource budget differently.
Before replacing the artwork, write down the boundary that is failing. Here are three concrete checks for three different tools. The examples are calculated or proposed checks, not recorded engine benchmarks.
1. Roblox: keep image coordinates separate from UI dimensions
For a uniform sprite sheet, record the source dimensions, cell dimensions, useful frame count and uploaded asset ID together. Then test fixed cells before testing an animation.
For example, a 256×128 image containing 64×64 cells has four columns and two rows. Zero-based cell 5 starts at (64, 64):
local index, columns, cell = 5, 4, 64
imageLabel.ImageRectSize = Vector2.new(cell, cell)
imageLabel.ImageRectOffset = Vector2.new(
(index % columns) * cell,
math.floor(index / columns) * cell
)
Those values describe the source region. The size of the displayed ImageLabel is another decision. If the selected pose is correct but stretched, changing crop offsets tackles the wrong boundary.
Use a numbered, asymmetric control sheet in Studio and the published target clients. Keep the same asset revision in the comparison. Do not assume that a historical upload-size workaround applies to every current client.
Primary reference: Roblox ImageLabel properties.
2. SpriteKit: make appearance changes have one owner
A restore-enabled texture animation can restore the sprite's original texture when the action is removed early. That matters when a skin switch assigns a new texture while the old appearance action still owns restoration.
If the old action was started under the key appearance, an intentional transition can cancel that action before assigning the new approved texture:
sprite.removeAction(forKey: "appearance")
sprite.texture = approvedSkinTexture
Here, approvedSkinTexture is the texture your application has already selected and prepared. The snippet does not load a new asset or define the next action.
Test early cancellation as well as normal completion. Log which action session is allowed to change appearance. Removing every action can also stop unrelated movement, so give the visual property an explicit owner.
Primary reference: Apple's animate-with-resize-and-restore contract.
3. GB Studio: budget unique tiles rather than compressed PNG bytes
A more detailed background can consume shared VRAM that sprites need. In monochrome-compatible modes, the documented budget endpoints include:
| Unique background tiles, 8×8 | Sprite tile capacity, 8×16 |
|---|---|
| 128 | Up to 96 |
| 192 | Up to 64 |
The extra 64 background tiles occupy the shared space equivalent to 32 sprite tiles. This does not tell you how many complete actors fit: a composite character can use several hardware tiles, and repeated artwork may reuse them.
Inspect the actual scene allocation in the debugger. Reducing a PNG's compressed file size does not by itself reduce its unique imported tile count. Color Only has different limits and is not a monochrome compatibility option.
Primary reference: GB Studio scene limits.
Turn the symptom into a useful question
Include the tool, source contract and observed failure:
- “Which uploaded image revision does this crop manifest describe?”
- “Which action can still restore the old texture?”
- “Which unique tiles consumed the shared scene budget?”
That gives the next check a specific input and acceptance condition.
Disclosure: this is an AI-generated editorial post prepared for the FrameSprite team, with API claims checked against the linked primary documentation. We are building a question-led game-art guide library with primary references, worked examples and downloadable acceptance worksheets. The library distinguishes proposed checks from tests actually executed.
Top comments (0)