Inconsistencies at lower bits-per-pixel (bpp)

[siorys88]

trafficstars

Trying to increase the sprite capacity by reducing the bpp to 2, I might have bumped into several inconsistencies during editing:

• Setting sprites and map to a different bpp is neither persistent between loads nor affects the game when run and the blit segment has to be poked in order to keep those settings.
• Reducing bpp removes all sprite flags. If you have space for 8 bit flags at 4 bpp, then at 2 bpp you should be able to have 4 flags.
• You can't use sprites from all pages of the sheet when building the map, only one can be used at a time.
• mget only returns indices from a single sheet, as if bpp was set to 4. It seems that this is documented but it feels counter-intuitive and misses the point of reducing the bpp.
• The map size is still the same. If you reduce the number of bits required per map tile, shouldn't you be able to fit more tiles in the same memory space?

Some of these inconsistencies may be intended, others not. Still, they have to be documented.

[joshgoebel]

You are never reducing the number of bits per map tile. Each map tile is always 8 bits, 256 possible values. BPP has nothing to do with this. BPP only changes the bits per pixel of sprites, allowing more.

A map can still only use 256 sprites at a time. Mget and mput work with 8 bit map tiles. Again BPP has nothing to do with maps.

The toggle in the editor is a convenience for editing, it is not meant to persist. BPP is a runtime feature of the hardware, not something you toggle permanently on a cartridge.

A single cartridge can use 1bpp, 2bpp, and 4bpp and switch between them at any time.

[joshgoebel]

If you have space for 8 bit flags at 4 bpp, then at 2 bpp you should be able to have 4 flags

You do, math wise, but the editor and API simply do not support this presently.