joeyr/tts-games
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

hanabi: emit each card face as its own image, for a UI build #14

Merged
joeyr merged 1 commit from hanabi/ui-assets into main 2026-08-16 23:17:00 -05:00
Conversation 0 Commits 1 Files changed 32 +26
joeyr commented 2026-08-16 23:16:27 -05:00
Owner
Copy link

TTS XML UI addresses an <Image> by asset name, one URL per asset, with no way to offset into a spritesheet. A 2D board needs the same thirty faces again as separate files.

They are rendered by the same render_card() that builds the sheet rather than cropped out of it. Cropping works today and drifts the first time a card design changes and only one path is regenerated — and the failure would be a card that looks subtly different depending on whether you see it as an object or as UI.

Behind --split, so default output is unchanged. Both builds can coexist; nothing here removes the spritesheet or the physical table.

TTS XML UI addresses an `<Image>` by asset name, one URL per asset, with no way to offset into a spritesheet. A 2D board needs the same thirty faces again as separate files. They are rendered by the same `render_card()` that builds the sheet rather than cropped out of it. Cropping works today and drifts the first time a card design changes and only one path is regenerated — and the failure would be a card that looks subtly different depending on whether you see it as an object or as UI. Behind `--split`, so default output is unchanged. Both builds can coexist; nothing here removes the spritesheet or the physical table.
hanabi: emit each card face as its own image, for a UI build
All checks were successful
lint / lua (pull_request) Successful in 17s
Details
376a3912e3 
TTS's XML UI addresses an <Image> by asset name, one URL per asset, with no way
to offset into a spritesheet. A 2D board therefore needs the same thirty faces
again as separate files.

They are rendered by the same render_card() that builds the sheet rather than
cropped out of it. Cropping would work today and drift the first time a card
design changes and only one of the two paths is regenerated -- and the failure
would be a card that looks subtly different depending on whether you are seeing
it as an object or as UI.

Behind --split, so the default output is unchanged for the object-based build.
Both can coexist: nothing here removes the spritesheet or the physical table.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
joeyr merged commit b8164c1ea1 into main 2026-08-16 23:17:00 -05:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
joeyr/tts-games!14
No description provided.