openfrontio / openfrontio/OpenFrontIO
Increase limits for max pattern size to allow for more detailed submissions
- Dominant language
- TypeScript
- Stars
- 2.7k
- Forks
- 1.4k
- Avg merge
- 17h 43m
- Merged PRs (30d)
- 310
Description
**Is your feature request related to a problem? Please describe.**
Pattern canvases are capped at 129×65. Artists have wanted taller canvases for a long time height is the constraint they actually hit, and the cap isn't symmetrical for any design reason. The v0 header packs width into 7 bits and height into 6. Patterns over the height limit (128x64) will render wrong, so an artist gets a broken skin with no explanation.
**Describe the solution you'd like**
A square 128×128 canvas, via a v1 pattern format. v0 decoding is untouched, so every existing cosmetic renders exactly the same.
**Describe alternatives you've considered**
Widening the v0 height field did not work, both metadata bytes are fully packed with no spare bit.
Sizing the pattern row per game rather than to a fixed maximum, which would allow larger canvases at lower typical memory. That needs the texture allocated on first addPlayers rather than in the constructor (same shape as initSkinAtlas), so it's a bigger change than this one.
**Additional context**
Fixed a live bug in main: the pattern row is 1024 bytes, but a maximum-size v0 pattern (129×65) needs 1049. .set() overflows silently into the next player's row. Never fired because no pattern has been that large.
Four files: PatternDecoder.ts, CosmeticSchemas.ts, WebGLFrameBuilder.ts, render/gl/Renderer.ts. No shader change as territory.frag.glsl already reads dimensions from patternMeta.
Added a v1 header (4 bytes, 9 bits each for width and height, 3 reserved). v0 path is byte-identical to current behaviour.
Fixed slice(3), which hardcoded the v0 header size and would misalign any longer header.
Added a v0 payload length check, so raising the schema cap can't let a v0 pattern smuggle trailing data through to Privilege.ts. Every currently-valid v0 pattern passes it.
Derived the row size, schema cap, and texture width from one constant, so they can't drift from the format again.
MAX_PATTERN_DIMENSION = 128 gives a 2048-byte row: 16MB across the CPU buffer and GPU texture, against 8MB today. The v1 header can express up to 513, so raising the ceiling later is one line and needs no format change — 176 is the largest that keeps the texture width inside the 4096 MAX_TEXTURE_SIZE that capped devices report.
**Assignment**
- [☑️ ] I'd like to be assigned to this issue and work on it myself
Contributor guide
Assessment
This issue has not been assessed yet.