Maybe like what the Game Boy would have been if it had had a framebuffer. It's a little bit sad, actually, that WASM-4, like the Pico-8, is a framebuffer console - there's less cool tricks you can do with raster interrupts and the like.
Were you thinking of changing the 4-color palette for every scanline, like the Atari 8-bits and the Amiga could do? Impose arbitrary limitations so you can find clever ways to circumvent them - sounds like fun!
The Game Boy has less memory than would be required for a full frame buffer, so its “just in time rendering” of sprites and tiles is one way to support its full display resolution and still leave some space for game state in the RAM.
> The Game Boy has less memory than would be required for a full frame buffer
This isn't quite true—you need 160 * 144 pixels at 2 bits-per-pixel. This weighs in at 5760 bytes. There are many other reasons why a framebuffer wasn't ideal for the hardware of the time, though.
Ah, sorry, I think I mixed that up with the opposite practical limitation then – IIRC you can't actually display a fullscreen bitmap on the original GameBoy without some hacks, as the full screen fits 360 tiles, but there's a limit of 256.
But in any case a frame buffer would use up almost the entire available VRAM of 8 KB and would have probably also been more expensive since it would have to be dual-port RAM (I believe the Game Boy's VRAM isn't).
I thought it was clear that arbitrary here refers to any modern reimagining of said limitations, which obviously don’t have to be identical constraints either.
