Determine what palette limitations will be for new Pokémon sprites

[andiemmadavieswilcox]

Overview

The most practical way to do this will be to analyse a typical battle scene and deconstruct it, while cross-referencing with GBC colour palette restrictions, in order to define what limits we will be working to when designing the new Pokémon sprite graphics.

Purpose

Without this information, it's not realistic to ask @JackalOfTime to start designing the new pixel artwork for the Pokémon battle sprites, as the number of colours (and range of colour choices) will directly affect her design decisions.

Tasks

• [x] Find-out how palettes are applied to each tile (i.e. how many colours each tile can have).
• [x] Use an emulator to isolate which graphics are on each layer.
• [x] Inform @JackalOfTime that she can start her design work.
• [x] Annotate (a) screenshot(s) of a deconstructed battle scene to illustrate findings.
• [x] Start a wiki for the repository.
• [x] Document findings and add them to the wiki.
• [x] Update the repo's README to reference the wiki.
• [x] File new issues for follow-up work.

Resources

• https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Game_Boy_Color
• https://www.tvtropes.org/pmwiki/pmwiki.php/UsefulNotes/GameboyColor
• https://www.nintendo.co.uk/Support/Game-Boy-Pocket-Color/Product-information/Technical-data/Technical-data-619585.html
• https://bgb.bircd.org/pandocs.htm (note: this one looks the most informative)

Future

• #2 – Initial repository-tidying refactors
• #3 – Define and document a workflow for creating and adding new front-facing Pokémon assets
• #4 – Create and add new assets for all front-facing Pokémon graphics
• #5 – Investigate whether GH Actions can be used for build verification and automatic releases

[andiemmadavieswilcox]

Keep in mind that souped-up graphics data will use more RAM and storage, so that may mean that limitations have to be stricter than what the raw hardware is capable of rendering.

If there's room left in RAM and ROM at the end of development, then it may be possible to use other tricks like changing palettes during hblank to increase the number of colours for Pokémon character graphics further during battles.

[andiemmadavieswilcox]

This MVG video seems to confirm what I believed to be the case regarding colour palettes for the background and sprite layers, whereby the following limitations exist:

• Up to 8 four-colour palettes can be attributed to background tiles.
• Up to 8 four-colour palettes can be attributed to sprite tiles (although in practice this is more like 3 colours, as at least one "colour" is always used to indicate transparent pixels).
• Each background tile can use one of its 8 four-colour palettes.
• Each sprite tile can use one of its 8 four-colour palettes.

[andiemmadavieswilcox]

According to this Wikipedia article, the colour space available for the palettes includes a total of 32,768 colours (15-bit RGB, i.e. 5 bits per colour). Of these colours, up to 56 can be displayed on screen at any one time using standard display methods, but colours like black and white are often used in multiple palettes, due to many tiles needing them, so the total number of colours displayed at any one time (without clever coding trickery) is often less than 56 due to the repeated colours. These findings tally with MVG's video above.

[andiemmadavieswilcox]

All this is also corroborated by this specification document: https://bgb.bircd.org/pandocs.htm#lcdcolorpalettescgbonly

[andiemmadavieswilcox]

While conducting this research, I stumbled across a forum post reply which contained an excellent, concise overview of all the display limitations of the GBC. Within the reply was also a recommendation for further reading on the Pan Docs project. Links to all of these resources can be found below:

• Forum post reply: https://forums.nesdev.com/viewtopic.php?t=17319#p217915
• Legacy Pan Docs wiki: https://gbdev.gg8.se/wiki/articles/Pan_Docs
• Current living Pan Docs document: https://www.gbdev.io/pandocs
• Pan Docs GitHub repo: gbdev/pandocs

[andiemmadavieswilcox]

@gbdev in general appear to have a lot of great resources!

[andiemmadavieswilcox]

Wow, ngl, this looks like a pretty fantastic community: https://www.gbdev.io/

[andiemmadavieswilcox]

@andidavies92: _"According to this Wikipedia article, the colour space available for the palettes includes a total of 32,768 colours (15-bit RGB, i.e. 5 bits per colour). Of these colours, up to 56 can be displayed on screen at any one time using standard display methods, but colours like black and white are often used in multiple palettes, due to many tiles needing them, so the total number of colours displayed at any one time (without clever coding trickery) is often less than 56 due to the repeated colours. These findings tally with MVG's video above."_

When it comes to designing the new artwork, I'd say the best approach would be to set Photoshop to use a 16-bit colour space – as only 8, 16 and 32 are available for RGB – and then we alter the existing tooling to take the PNG output from Photoshop and extract the 2-bit tile data and down-sample the palette rounding to the nearest neighbour. This gives the greatest flexibility to the artists while not risking too many colour accuracy issues.

[andiemmadavieswilcox]

I was pretty sure already that this was the case, but I've now confirmed through an emulator by disabling each layer in turn, that all battle graphics other than attack and item animations (which are done using sprites) are displayed as background graphics, which makes life much simpler.

[andiemmadavieswilcox]

@andidavies92: "When it comes to designing the new artwork, I'd say the best approach would be to set Photoshop to use a 16-bit colour space – as only 8, 16 and 32 are available for RGB – and then we alter the existing tooling to take the PNG output from Photoshop and extract the 2-bit tile data and down-sample the palette rounding to the nearest neighbour. This gives the greatest flexibility to the artists while not risking too many colour accuracy issues."

Actually, thinking about it, it might make more sense to use a specially-designed tool to do the artwork which enforces the limitations of the platform, such as the correct colour-depth, palette definitions and only allowing the four colours from one of the 8 palettes in each tile (for which there's a handy tile grid overlay as well), such as the Tilemap GB GIMP plugin or the much older (and possibly no longer working) GBTD.

Once we have a design that matches the requirements, we can create a full mockup of a battle scene still, to see how the finished product could foreseeably look, and then work on the tooling and modifications needed to incorporate the new designs and colours into the game.

[andiemmadavieswilcox]

Note: Just while I think of it, I'd recommend that the new designs for the enemy graphics leave at least a one-pixel line of empty space at the bottom of the graphic, so that the bottom of this graphic and the top of the player's Pokémon's name text don't touch.

[andiemmadavieswilcox]

I now have sufficient information to be able to define how the palettes will be divvied-up:

#	Purpose	Colour 1	Colour 2	Colour 3	Colour 4
1	Playfield and details (i.e. tufts of grass, sea waves, cave rocks, etc.)	Playfield base colour	Playfield highlight colour	Playfield shade colour	Additional highlight or shade colour
2	Primary menu colours	Black	White	Red (for Pokéball)	Grey (for shading)
3	Health bar colours (smoothly transition from green, through yellow and orange, to red)	Black	Playfield base colour	Enemy Pokémon's health bar colour	Player's Pokémon's health bar colour
4	Used for enemy Pokémon's outline and HUD	Black	Playfield base colour	Pokémon colour 1	Pokémon colour 2 or playfield shade colour (e.g. for Pokémon's shadow or glow)
5	Used for player's Pokémon outline and HUD	Black	Playfield base colour	Pokémon colour 1	Pokémon colour 2 or playfield shade colour (e.g. for Pokémon's shadow or glow)
6	Enemy Pokémon's primary palette	Anything	Anything	Anything	Anything
7	Enemy Pokémon's secondary palette	Anything	Anything	Anything	Anything
8	Player's Pokémon's palette	Anything	Anything	Anything	Anything

@JackalOfTime, could you review this table when you get a chance to make sure it: 1, makes sense; 2, is practical to work with; and 3, isn't going to stifle your creativity too much? If it is too limiting, then one thing we could do would be to abandon the different types of playfield (grass, water, cave, etc.) to free-up colours for the Pokémon themselves, but I think that'd be a unique nicety to keep if possible. I think this plan gives a nice balance of lots of different elements, rather than giving the Pokémon graphics all the love, and instead enhancing the whole experience, if that makes sense?

Once we have a spec for the palettes agreed on, I'll formalise them and document them properly on the wiki, so you can refer to them in a more accessible manner when designing the new graphics. Each 8 × 8 pixel tile can have any one of these 8 four-colour palettes attributed to them by the way.

P.s. You might want to read through all my comments on this issue to get a feel for what research was behind these decisions. Some of it will be too technical, but you should be able to get the gist of things.

[JackalOfTime]

This all looks doable to me - I agree with most of it, I don't view it as stifling the creativity as it is giving me way more to work with than before technically :3 All good my end!

[andiemmadavieswilcox]

@JackalOfTime "This all looks doable to me - I agree with most of it, I don't view it as stifling the creativity as it is giving me way more to work with than before technically :3 All good my end!"

Okay, sweet! If you crack-on with initial work on one of the three starter Pokémon's artwork then and I'll write all this up into a proper wiki article for reference.

[JackalOfTime]

Okay so I need some thoughts on the lineart that I have going, whether to do some light lineart or just leave it all black? I personally prefer the coloured line work, but I'm open to ideas, the coloured pieces just feel more polished!

Take a look at these images and see:

[JackalOfTime]

[andiemmadavieswilcox]

Loving the direction. I don't think the edges need to necessarily be black outlines, so the ones where the outline colour can differ are preferred. These look fantastic by the way!!

Unfortunately, however, they both have waaay too many colours for the GBC to handle haha. Based on the allocation table in my previous comment, these enemy sprites have three lots of four-colour palettes available, which have to be carefully chosen and allocated to each tile in order to make best use of the limited total colours and colours per tile. I had a play around with your Charmander sprite in Photoshop to demonstrate how we might go about manually downsampling your high-colour artwork into faithful, still-colourful versions that we can get the GBC to display.

This GIF shows a screen capture of my Photoshop session's output where I've decided what the most important colours are and allocated them into the three palettes, where the tile boundaries should be in order to maximise key colour/feature retention, which palette gets allocated to each tile, made any adjustments to the base graphics in order to get the most out of each tile (e.g. nudging/expanding/shrinking elements to line them up to the grid more), and assigned palette colours to each pixel. I flick between your original and my downsampled version to illustrate the difference and how it had to be changed to meet the system's technical requirements:

I hope this makes sense? One way we could approach this, so you don't have to get overly bogged-down in the technical limitations, could be for you to do the artwork as you have done above, then I'll process them by hand to meet the system requirements, and get you to review/tweak the processed version, before we sign it off?

Let me know your thoughts on all this either way.

[andiemmadavieswilcox]

And here's how it might look on an original monochrome DMC Game Boy (if we decided to maintain backwards compatibility with it):

[andiemmadavieswilcox]

I had a go at adding the graphics to the ROM and running in DMG mode in an emulator, and it really doesn't look great in the original palette, so I definitely think we should still ditch DMG compat, otherwise we risk compromising on the quality of what we could do with the graphics on the GBC, which is the main point of this project after all.

[andiemmadavieswilcox]

I made this annotated image a while ago (and forgot to post it here) which illustrates how the new palette allocations would/could be applied to the background tiles in a typical battle scene:

The colours in the image pertain to the palette table palette numbers as follows:

• Palette 1 – pink.
• Palette 2 – red.
• Palette 3 – orange.
• Palette 4 – yellow.
• Palette 5 – green.
• Palette 6 – blue.
• Palette 7 – violet.
• Palette 8 – indigo.

[andiemmadavieswilcox]

I've started a wiki for the repo: https://www.github.com/AmateurPanda92/pokemon-rby-dx/wiki

[andiemmadavieswilcox]

I've updated the repo's README with links to the new wiki and its various sections.

[andiemmadavieswilcox]

I've filed new issues #2, #3, #4 and #5 for follow-up work relating to this issue, so this one can now be closed.