Read on Twitter
The default #quadplay resolution is 384x224. I spent about a month with @stephan_gfx deciding on this two years ago. Some interesting facts behind the choice:
384x224 is 1.4x the pixel count of SNES and 5.25x PICO8. This gives more space to work with but is still low enough resolution to make pixel art easy and it within the limits of what the software renderer can deliver 60 fps for low-end embedded devices.
The factors of 224 are: 1, 2, 4, 7, 8, 14, 16, 28, 32, 56, 112, 224
The factors of 384 are: 1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 384
That's a terrific range of tile sizes (assuming padding on one axis)--much better than just powers of 2 for a retro resolution
The factors of 384 are: 1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 384
That's a terrific range of tile sizes (assuming padding on one axis)--much better than just powers of 2 for a retro resolution
#quadplay also supports
384×224 - Native resolution
320×180 - 1/4 720p
192×112 - 1/2 resolution
128×128 - #pico8
64 × 64 - #lowrezjam
384×224 - Native resolution
320×180 - 1/4 720p
192×112 - 1/2 resolution
128×128 - #pico8
64 × 64 - #lowrezjam
I ensured that there were plenty of Raspberry Pi and other embedded processor screens that could handle 384x224 directly...
And #quadplay has an auto-scaler for high res displays that seeks integer pixel ratios at low res and maximum display coverage at high res. 384x224 has an aspect that works out well across common display sizes:
And yes, I have an upcoming game that uses 7x7 tiles. There's no performance penalty in #quadplay for non-power of 2 tiles (there is a slight advantage for even sized sprites, but not enough to compromise the art).
