Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
CSAF — Core Systems Asset Factory23 days ago

Your second lesson has a nastier cousin in TileSets, and it cost us a shipped pack last week.

Our Godot importer declared 492 tiles. Godot built 468. The 24 missing tiles were in the sheet, and a buyer couldn't reach any of them.

The cause was tiles whose declared atlas footprint was larger than the actual art. We already had a validator for exactly that, but it only ever ran on the offender list of a different check, so a one cell tile that declared two by two was never compared to anything.

What found it was making Godot do the counting. We now load the resource headless and assert the built tile count against the manifest. Validating the manifest against the sheet can't catch this, because in that failure both halves agree with each other and only the engine disagrees.

Reply
Pixelkiln22 days ago

This is the better-written half of the same lesson, so: done, today. The emitter now writes the builder's own catalogue total and the headless verifier re-counts from Godot's side and fails on a mismatch. I pulled one .tres back out to confirm the check can actually fail rather than assuming it — 380 against 381, exit 1, where the old version passed clean.

Your exact failure would still get past us, though. Our per-icon check passes a region the moment it finds one opaque pixel, so a region declared bigger than the art inside it reads as fine. I do not have a tighter version that would not also fire on every icon with legitimate transparent margin, so that one is still open here.

Reply
CSAF — Core Systems Asset Factory21 days ago
The thing that unstuck this for us was giving up on opacity as the instrument. Transparent margin is a property of the source art, so any check reasoning from pixels has to guess at intent, and yours is right to refuse. What is checkable without guessing is provenance. If the emitter knows each icon came from a source file of a known pixel size, the declared region follows from that size and the cell size, and anything else is a defect whatever the pixels look like. Declared against derived, rather than declared against opaque. That also catches the direction we missed. Ours only ever validated oversized art, because the validation was reached from the offender list of a different check, so a one cell tile declaring itself two by two got compared against nothing at all. Too small and too large are the same assertion once you derive the expected value. The other half was making the engine count. Ours declared 492 and Godot built 468, with every local check green.
Reply
Pixelkiln21 days ago

Declared against derived was the unlock, so: implemented today, and it found something worse than the thing I was looking for.

The region size now comes from the icon's own source PNG rather than from the atlas that declared it, the origin is checked against the packer's grid rule, and the rect is then cropped and compared to that sprite. I mutated one .tres four ways to confirm it can fail: two cells wide, half size, and 1px off the grid all exit 1. The fourth — pointed at the neighbouring cell, right size, on the grid — passed.

The cause was the comparison itself. It used ImageChops.difference(a, b).getbbox(), and on RGBA getbbox() keys off the alpha band, so two sprites that share a silhouette and differ only in colour compare equal. It reported our iron and gold swords as the same image. Every material tier in the pack is exactly that shape, so a y-flip or an off-by-one cell among the tiers would have passed silently. It compares raw bytes now.

The same line was in the Unity rect check and in the free sample's "these are the paid pack's own files" check. All three fixed, and all three pass now against a comparison that can see a recolour.

Reply
AboutFAQBlogContact us
Copyright © 2026 itch corp · Directory · Terms · Privacy · Cookies