The Sprite Editor’s drawing tools will also enforce the colors per sprite limitation you set in the data.json file. If you attempt to select a color and the sprite currently has the maximum colors it can display, you’ll see a warning at the bottom of the screen and the sprite editor will be disabled until you delete a color from the sprite.
If you select a sprite that has more colors than are supported, the CPS preview are will expand but additional colors will be greyed out.
While this preview is useful for seeing how many colors are in a sprite, it may not be accurate at runtime. Also, when you change the size of the sprite selection, the CPS preview will treat the entire group of sprites as one.
Some classic game systems limited you to a set number of colors per 8 x 8 sprite, there were times where background tiles may have been limited to the same color per sprite count as an 8 x 8 sprite for every 16 x 16 tiles. The NES, for example, has this limitation where only a single background palette could be applied to a 16 x 16 set of tile sprites.
You can modify the CPS Chip Editor Tool by selecting the GPU chip and looking at the renderer panel.
Changing this value forces the importer to parse the
sprite.png with the new CPS value. This doesn’t immediately change the actual file itself. This allows you to go back into the Sprite Tool a preview the changes on each sprite. Here is an example of what happens when you change the CPS value from 8 to 4.
As you can see, the player’s feet are no longer displayed. The importer keeps track of each color as it parses a sprite from the
sprite.png file and ignores additional colors beyond the CPS cap. Any color over the CPS value is made transparent. This setting could have drastic effects on how Pixel Vision 8 imports your sprites. If you make any changes in the Color or Sprite Tools, the
sprites.png file will be saved using the current project’s CPS value, overwriting any previous versions.