Player Photos: An Tale of Discovering a Dead End, or, Help Wanted: Apply Within

[von Ozbourne]

Okay. After spending some time on this, I appear to be at the end of my capabilities. I don't know if this is even an question that can be answered in the affirmative, but I figured I would purge my notes and see if this might prove helpful to others or just be an interesting story about how to listen to the clues that you may be wasting your time.

The quest? Can player photos be adapted in some way to use more than the per-requisite 8 colours.

It's already been established that as long as the first white and black photo palette colours aren't changed, the remaining six colours can be changed to anything you want in order to introduce colour to the photos.

First player card photo offset is at:
30 & 32 Team  = 120294

OG game = C6402 [default unused guy]
            or = C6838 [default players]
            or = C75E0 [first starting lineup player photo]

Colour palette offset = 120294 [decimal]
Uses same #1 white and #2 black as menu screen assets and #3 to #8 are grey-scale colours by default, but can be changed to any colours as they are independent of any other asset.
This is part of a larger colour palette that starts at offset C6762
Space is allotted for standard arrangement of 4 x 16 colour palettes
Photos actually use colours #6 to #14 of palette #2.

If using 120294 [decimal] on 3bpp linear as a basis, Palette #1 is the default colours,
#2 is blank, #3 is a copy of #1, #4 is blank, #5 is a copy of #1 & #3.
Using these settings, there is actually space for two preceding palettes, starting at colour #6 on palette #1, but it is not known if these can be incorporated.

Every player photo, in both the default and 30 team version, is preceded by the hex code: 0000 0000 0000 0000 0024
Not sure why the four groups of 0s are required, but best guess on the "0024" is that each player photo is 6x6=36 tiles in decimal, aka 24 tiles in hex
This appears confirmed by the fact that the first default player photo to reuse tiles was Doug Weight [offset CE9F4] whose photo leader code is:
0000 033A 0000 03BA 0022
Not sure about the "0000 033A 0000 03BA" yet, but clearly the "0022" points to the fact that Weight's image only uses 22 hex [34 dec] tiles instead of the normal 24 hex [36 dec].
I am guessing that "033A" and "03BA" are overrides for the new colour palette and tile ordering offsets respectively because...

Following Weight's image tiles it appears that the "saved" space is just used threefold by additional colour and tile arrangement data anyway. [wonder why they bothered...]
At offset CED24:
0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6
0EE6 0EE6 0EE6 0EE6 0EE6 0EEE 0000 0CCC 0AAA 0888 0666 0444 0222 0EE6 0EE6 0EE6
0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6
0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6 0EE6
Colour data follows previous pattern of using latter half of 2nd palette, although 3rd and 4th are left blank

Immediately followed by:
0006 0006
Photos are six across by six down

Immediately followed by:
2000 2001 2002 2003 2004 2005
2006 2007 2008 2009 200A 200B
200C 200D 200E 200F 2010 2011
2012 2013 2014 2015 2016 2017
2018 2019 201A 201B 201C 201D
201E 201E 201F 2020 2021 201E
Normal image tile numbered ordering with colour instruction [2000 meaning 2nd palette as noted above]
[Unfortunately my copy of the original unedited game doesn't load up when I make edits, probably something to do with checksum info or something... whatever]

Used SmozROM tool to make a new "OG - checksum" version. That was the problem. Yay.
Changed top half of Weight's image to use "4000" colour option and it came up with the top half using different colours.

It appears that palettes might stick to the 8-colour model though so rather than jump to #6 to #14 of #3 palette, possibly they use the colours directly after the adapted "#2" palette and uses colours #1 to #8 of #3 palette. Although now I think they are referencing a palette in a completely different location.
It is possible that "0000" colour will be #14 of palette #1 to #5 of palette #2.
Or, in testing Winnipeg's Teppo Numminen, who uses 23 instead of 24 tiles, changing the tiles from colour "2000" to colours "4000" and "6000" appear to shift the colours in the image to instead use the colour palettes attached to the background on which the image is viewed [main menu, pre-game screen, player card screen]

Top third is "2000", middle is "4000" bottom is "6000".
From previous notes, I know that the main menu has no 3rd [6000] palette, for the Pre-Game screen, its 3rd palette is used for Ron Barr's colour photo and the Player Card screen, has a 3rd palette for the NHL and NHLPA logos

Final image, default, Winnipeg's Alexei Zhamnov, offset E62D2
image is followed by hex code:
0000 2B0A 0000 2B8A
The fact that the difference between the two offsets being "0080", matching that of the Weight example is not a coincidence
On further investigation, jumping ahead an offset of 2B0A from this point arrives at the colour palette and tile arrangement data for the Player Cards screen background. Makes sense.

30 Team not as helpful as immediately after the final player image [offset 1C6622] [32 Team = 1D17AA] is the colour palette data for the main menu team banners

Tried changing the "0000 0000" on the last couple players to "0000 033A" but it seems that whatever control override for colours was allowed in the original, is not accommodated when the additional teams and photos were programmed in.

Soooo.... that's what I got. [sorry for the junk loads of bold, it just helped as I would skim along]
Absolutely no idea if there is even anywhere to go with this idea, but I figured why not put it here and see. And if anything, even a failed experiment can be informative, because that's just science.

Edited August 16, 2023 by von Ozbourne

[kingraph]

On 8/11/2023 at 9:14 PM, von Ozbourne said:

Every player photo, in both the default and 30 team version, is preceded by the hex code: 0000 0000 0000 0000 0024
Not sure why the four groups of 0s are required, but best guess on the "0024" is that each player photo is 6x6=24 tiles
This appears confirmed by the fact that the first default player photo to reuse tiles was Doug Weight [offset CE9F4] whose photo leader code is:
0000 033A 0000 03BA 0022
Not sure about the "0000 033A 0000 03BA" yet, but clearly the "0022" points to the fact that Weight's image only uses 22 tiles instead of the normal 24.
I am guessing that "033A" and "03BA" are overrides for the new colour palette and tile ordering offsets respectively because...

 

Reference for some more in depth reading: HOW TO "Decompress" Graphics in Sega Genesis

The header for most graphics is

* First 4 bytes are usually the data length of graphic in Hex, including the header 10 bytes.  So in this case "0000 033A" is 826 bytes.  
* The next 4 bytes usually lead to the end of the palette location, or another 128 bytes more.  "0000 03BA" is 954 (128 more).  
* The last 2 bytes represent the number of tiles in the graphic.  In this case, I believe it's 22, which means the number of tiles used in the graphic is 34.

Normally each tile uses 32 bytes of data.  Tiles are 8x8 pixels and each 2 bytes represents a color.  Because the player photos are coded in 3bpp, the size of each tile is only 24 bytes.  So the total for this graphic is 34 tiles x 24 bytes = 816, plus 10 for the header and we get to 826 (033A).  Then there is 128 bytes for the second section.  

What I actually THINK is happening is that the first part of the header gives the number of bytes to jump to the next offset where the palette starts.  The next set of bytes jumps to the start of the layout (0006 0006) or 6x6.  For player cards, the 0000 0000 0000 0000 in the headers would suggest that the game just uses the same palette and/or size.  I notice the same with header logos that share a palette, the first and second parts of the header are the same as they share a palette.  But the size is still included.  My guess is in case there are shared tiles and the actual sizes are different.

Having said all of that, to address your original question, if you wanted to increase the number of colors in player portraits you will first have to change the coding from 3bpp to 4bpp.  Meaning, the game is coded to know that the player cards are graphics that use 3 bytes per pixel, which saves space.  First you'd have to find and understand how that function in the game works, change it to 4bpp if possible, and then recode the player graphics to 4bpp format.  I have no idea if it's possible, but this will be a pretty technical exercise.

 

 

[von Ozbourne]

5 hours ago, kingraph said:

* The last 2 bytes represent the number of tiles in the graphic.  In this case, I believe it's 22, which means the number of tiles used in the graphic is 34.

Ah yes. I should have clarified that since (6x6)-2 is obviously 34 and not 22, but it either slipped my mind or I've spent so much time counting in base-16 that it's second nature.

I'll just edit that in.

5 hours ago, kingraph said:

if you wanted to increase the number of colors in player portraits you will first have to change the coding from 3bpp to 4bpp. 

This was also a concern given that the player photos would end up taking up a lot more space. [guessing rather than a "4 is 25% more than 3" thing its a "2³ vs 2⁴" thing] My initial thought was that instead of increasing the bit depth of each photo to use 16 colours, [which would admittedly make things look a lot nicer and be a lot cooler once all the potential heavy lifting is out of the way] but perhaps relocating only the used palette to another location so as to free up the mandatory white and and black used by the other menu assets or allow for the use of multiple palettes. Which in light of the Doug Weight thing, would be pretty inefficient and take a lot of time and extra effort to set up and work with, which is why I wasn't married to the idea beyond general curiosity... I think I'm talking myself out of pursuing this matter any further.

[kingraph]

2 hours ago, von Ozbourne said:

 

This was also a concern given that the player photos would end up taking up a lot more space. [guessing rather than a "4 is 25% more than 3" thing its a "2³ vs 2⁴" thing] 

It's be 33% more data for each player photo.  So a 3bpp player photo takes up 864 bytes of data (36 tiles x 24 bytes/tile) whereas a 4bpp would be 36x32 or 1,152.  

There would still be room for the player cards, but I'm not sure if enough for 700+ or whatever some of the modern roster ROMs did.

This is cool though...if I tinker around this more I'll post here to share.

[kingraph]

In my other tutorial referenced above, I explain that in the 4bpp format, each byte represents 2 pixels.  Each of the digits in the byte represents what palette color the pixel will show.  So to show 8 pixels, you would need 4 bytes.

In the 3bpp format, the code to show 8 pixels is found in just 3 bytes, saving space! 

I wanted to see how this was done in the code and share in case anyone was curious.  

Every 4 pixels is represented by 1.5 bytes (3 hex numbers).  This chart shows the value of each of the 4 pixels across the 8 colors (0-7):

Depending on which palette colors are chosen for the 4 pixels, you just add up the values in the above chart to get your 3 digit hex number.  

So let's say the first four pixels were

palette color 3 (600)
palette color 7 (1C0)
palette color 5 (028)
palette color 2 (002)

You would add those up to get 7EA (8+2=A, C+2=E, 6+1=7).  

So this does save a tremendous amount of space in something like player cards, as we mentioned above.  To full flesh out the math on a single player card:

There are 64 pixels in each tile, each player card is 6x6 tiles, so that's 2,304 pixels of information needed for every player card (6*6*64).  In 3bpp format, you need 3 bytes for every 8 pixels, so that requires 864 bytes (2304/8*3).  The same image in 4bpp would need 1,152 bytes (2,304/8*4), or 33% more bytes!

[Drezz]

The other big issue you may encounter is limitations in RAM. The pics probably won't render in 16 colours as there's too much going on. I had this issue when working on the background tiles. I was hoping to make it full screen, but it would crash. The shared palettes thing is very tricky indeed.

[AdamCatalyst]

I *think* I might have encountered this when editing the rink. Initially I thought that certain tiles were "no go" zones that were breaking things, but later those tiles worked just fine. I eventually hypothesized that it was the number of unique tiles I was pulling in at once. Of course, this is just a theory.

[smozoma]

number of tiles can definitely be an issue. there are emulators that will show you the graphics buffer and you'll see that your extended graphics get overwritten. I had to deal with that in the NHLPA 93 extra teams hack on SNES.

 

https://forum.nhl94.com/index.php?/topic/11734-nhlpa-hockey-93-64-team-rom-snes/

Quote

Banners are made of 18 tiles, arranged in 2 rows of 9. Each tile is 8x8 pixels.

The banner tiles are pulled from one big graphic in the ROM, but the graphic's size is limited to 585 tiles -- only enough for 32.5 banners. In order to get more than 32 banners, tiles are repeated/shared between banners.

 

[kingraph]

4 hours ago, Drezz said:

The other big issue you may encounter is limitations in RAM. The pics probably won't render in 16 colours as there's too much going on. I had this issue when working on the background tiles. I was hoping to make it full screen, but it would crash. The shared palettes thing is very tricky indeed.

I think the number of colors will be okay as the game displays 64 colors (4 palettes of 16).  The trick, as you mention will be that the cards would have to share at least 8 colors with another part of the screen.  And since the cards are displayed in multiple areas (start screen, matchups, player profile), I haven't even checked if those areas also have the same palette that can be used.  

3 hours ago, AdamCatalyst said:

I *think* I might have encountered this when editing the rink. Initially I thought that certain tiles were "no go" zones that were breaking things, but later those tiles worked just fine. I eventually hypothesized that it was the number of unique tiles I was pulling in at once. Of course, this is just a theory.

Yes, and as Smoz said, it seems to be the size of the picture (i.e. number of unique tiles) rather than the layout.  Sometimes I have found that a picture is actually loading more tiles than are actually used in the game.  For example, you can see a picture that loads with 30 tiles, but the layout only references 28 of them.  The other 2 are actually loaded, but never used.  It sounds like that is what happened in your case.

Now, if you were to load up a new picture with 31 tiles, that's where the RAM limitations may come into play.  That's what I ran into on the banners in my '95 expansion hack.  The banners, although only 2x16 displayed, is actually loading the entire 28 teams banner picture!  Adding to that caused the RAM limits to hit.

[von Ozbourne]

On 8/16/2023 at 4:37 PM, kingraph said:

It's be 33% more data for each player photo.  So a 3bpp player photo takes up 864 bytes of data (36 tiles x 24 bytes/tile) whereas a 4bpp would be 36x32 or 1,152.  

There would still be room for the player cards, but I'm not sure if enough for 700+ or whatever some of the modern roster ROMs did.

This is cool though...if I tinker around this more I'll post here to share.

This could still be interesting actually. Quick math would indicate that even if there is no additional space allocated for player photos, once converting from 3bpp to 4bpp, that would still leave enough space for 17.3333 photos per team as opposed to the full 26. But that just happens to be exactly the same number as the starting lineup when counting the three full strength lines and starting goaltender with one spare for a logo or "generic shadow" to represent the rest of the team.

16 hours ago, Drezz said:

The other big issue you may encounter is limitations in RAM. The pics probably won't render in 16 colours as there's too much going on. I had this issue when working on the background tiles. I was hoping to make it full screen, but it would crash. The shared palettes thing is very tricky indeed.

Based on the assumption that this is also not going to be a problem.

[von Ozbourne]

11 hours ago, kingraph said:

I think the number of colors will be okay as the game displays 64 colors (4 palettes of 16).  The trick, as you mention will be that the cards would have to share at least 8 colors with another part of the screen.  And since the cards are displayed in multiple areas (start screen, matchups, player profile), I haven't even checked if those areas also have the same palette that can be used.  

Hold up, if this were to work, is it possible that the 6000 palette might help out here?

On 8/11/2023 at 7:14 PM, von Ozbourne said:

Top third is "2000", middle is "4000" bottom is "6000".

I'm wondering if even if the photos still reference the different palettes in the three different locations, could that just not be changed to the same colours? The menu doesn't have a third palette, so it's referencing a blank one. Might just be a matter of checking which instance of the "default rink colours" that the screen uses. i should really search that out later... But on the pre-game screen, it's just a matter of making your Ron Barr or replacement announcer image use the same colours as the players. As for the Player Cards screen, since the logos use that 3rd palette, and since the first palette has grey shades anyway, they can just share the first or second one with the rest of the background. Just need to remember which one dictates what parts change colours with the switch in teams. Have that in notes somewhere...

This is all based on the premise that the photos can be converted to 4bpp of course, but if RAM limitations does pose an issue, wonder if commandeering the 3rd [or possibly even 4th] palette might be a possible workaround.

[kingraph]

@wboy's Player Card Tutorial confirms some answers to questions we had.  When a graphic has the "0000 0000 0000 0000" in the header, this "instructs the game to use the standard palette and tile layout as seen in the first player card template".  I believe the same for other graphics.  Nice to know we had these answers nearly 19 years ago, lol, from the GOAT of '94 hacking!

 

––– PLAYER CARD DATA STRUCTURE –––

The first 10 bytes of every player card contains 4 bytes which store the offset (plus) value of the palette data, the next 4 bytes which store the offset (plus) value for the tile layout data, and finally the last 2 bytes that store the amount of tiles used by the player card. Immediately after (and also the offset used to correctly see the player card in TM) is the "3bpp linear" tile data. Its length is determined by the amount of tiles used by the player cards.

The first player card in both year's ROMs is effectively the template used by the majority of player cards, all of which do not have any shared tiles. These player cards are easily identified as their header value always 00000000 00000000 0024. Setting the value 00000000 to either the palette offset (plus), or the tile layout offset (plus) instructs the game to use that standard palette and tile layout as seen in the first player card template. As these player cards use the template, they do not store any palette and tile layout data after the "3bpp linear" tile data.

For the minimal amount of player cards with shared tiles, you will notice they each player card carries their own repeat of the palette data, and also their individual configuration for the tile layout data, as it needs to instruct the ROM which shared tile is repeated else where. This data is similar to the format used by the rink layout data, with values from 2000 though 2023 used to map out the layout of the tiles. The first 4 bytes of the tile layout data is always 0006 0006, most probably instructing ROM the player card is 6x6 tiles.

[von Ozbourne]

Just realized that while I was looking into something else, I seem to have stumbled onto something tangentially related, if possibly no more helpful.
I was playing around with transparent team banners on the Game Setup screen with a net result of trying to get more colours into the banners. Then I noticed this happening.

For context, what we're looking at here is a screen that is using four colour palettes. #1 [0xxx] is the default rink colours and the one used by the overlaying bits. [Also the background in the default game, but in this example I'm using the @Drezz background hack] #2 [2xxx] is The Home Team colours. Which is the most interesting, so more on that later. #3 [4000] is the Away Team colours and basically consists of the nine colours, plus black and white, used by the Away team logo. The remaining first five are basically unused. And #4 [6000] is an extra palette not used in the original game, but I use it with the background image to allow for the greatest option of colours that don't conflict with any other assets.

Now, in the above image, I made the middle portion of the Home/Away banners fully transparent and put a gradient banner directly on to the background image that will peak through allowing for essentially four colour gradient banners not including the anti-aliased text. By changing the background hex code for those areas to 4000 [away] and 2000] [home] this allows me to borrow from the team logos' colours to create this effect. I tried this with the Banners themselves, but I recall this not working out so well. Turns out, it doesn't completely work this way either. [unless you disable player photos... hmm...] Anyway, finally getting around to testing it, I had to check all of the colours and I noticed that the 2000 palette on this screen it a real hodge podge of colours. Of the 16 colours used in that palette, #1 is the default background, #2&3 are taken from the Home Team banner colours, [the tutorial for such is included in wboy's original modding reference] #4&5 are what the Away team's banner uses, despite being a separate palette [in the same tutorial] #9-16 are taken from the Home Team's logo, but only when the logo is on the screen. Turns out that when the player photos are being displayed on this screen, those final eleven colours are replaced by the eight player photo colours and the blank black spaces that follow it. I haven't tried setting those extra black shades to something brighter, but seeing as they would be universal to every team, it doesn't really address the thing I was attempting to do anyway.

Going to abandon the banners at this stage, but it did make me think about how the colours may be available to the player photos [once the 3 vs 4 bpp issue is taken care of and they can access those extra colours]

[AdamCatalyst]

I cannot recall the last time I was this confused.

[Sedge]

I know this is beside the point of the post but the coloration behind the Panthers logo makes it look pretty sharp. I take it you're mimicking the jerseys' layouts with logos here?

[von Ozbourne]

On 9/24/2023 at 11:30 AM, AdamCatalyst said:

I cannot recall the last time I was this confused.

Sorry man, hmm ...not sure if that is an indictment on how the coders build the game or my explanation of my testing....

21 hours ago, Sedge said:

I take it you're mimicking the jerseys' layouts with logos here?

To be honest, I was just testing this with the colours that I already had in the #9 and #10 spots. I was planning on doing something with gradients and/or striping if this worked, but Florida just turned out to be a Bob Ross moment.

[von Ozbourne]

I don't know how useful this will ultimately be as the options are limited, but I figured I might as well add a hypothesis turned discovery on this topic.

I found the code that determines the player photos layout and changed the bottom row from 20XX to 60XX. This meant that it would now use the fourth palette option when displayed on a screen. The drawback is that it uses a different palette depending on what screen it is on. Main menu is easy. That palette is open and unused [unless you are using Drezz's menu bg hack, in which case it is also a spare, unless you are like me and set your entire background to use palette 6000 in order to separate it from the overlay assets] The colours are used universally though, so after accounting for white, black, grey and a light skin tone, that only left four colours remaining. I suppose if one when with a comic book style shading and put a shadow or over the neck area, or maybe just gave everyone crew necks, the grey and single minded skin could be removed in favour of six total colours. For this test my only colours were red, orange, green an blue.

The wrinkles however show up when you get to other screens, like the pregame, where palette 6000 is subbed in with what the host and overlays are already using. Some rearranging of colours, while staying true to what the windows and text to stay put, meant that the Ron Barr's substitute needed some rearranging, but it can work. I haven't yet fixed the Hot/Cold things, but that could have been made to work well enough in the new confines.

The Player Cards screen uses yet another set of background colours, with 6000 normally being reserved for the NHL/PA logos. But the odd part is that the photos actually borrow palette 0000 from the background. I actually added an extra bit of mess here in making the background different so some parts are affected more than others. I was able to have some of the background share palette 6000 with the NHL/PA logos, and I suppose if the whole background were changed to do that, it would make it so the colours can be changed without having the other bits get messed up.

The only problem now is that while it is interesting to have some colours, I'm finding it a bit constraining to have so few to work with anyway.

[77]

why havent you put advertising on the boards yet

[von Ozbourne]

Because that's not what this topic is about.

But on the topic of player images, after sleeping on it, I realized that I can address a bit of the colours issue by adjusting the collar of the sweater. By centring the neck in a way where the middle two tiles only have neck and the sides only have sweater, and maybe using some creative greying to blend the two, the middle can be kept at the default colours leaving one more colour available for the shoulders. Probably yellow, although that still means that there are only five universal tones available for all 32 teams.

 

Might as well share this option as well even though it is a bit half baked at the moment.
Regarding the Player Cards screen, the colour sharing issue could be addressed by setting some of the tiles behind the photos to overlay the photo layer. This is in the hex code for the background of this screen and can be done by changing the 36 "00E5" tiles that make the background of the photo/logo area [shared by the top row of the coloured team name line] to "A0E5". The "A" meaning both that the tile will adopt the #2000 palette colour used by the team banner as well well be displayed on the top layer.

Although you will also want to change the "0E0" part to the numbers of different tiles as well. Probably two that will be commandeered to make a mirrored shoulder shape with a transparent background.

The stipulation here though is that those tiles will also overlay the team logo, so unless you are like me and like to have uniform coloured backgrounds behind your team logos, and position the logo in a way that doesn't interfere with the space allocated to the player shoulders, and also don't mind having the same shoulder shape for every single player, [something that I suppose isn't as much of a problem if you are using a more artistic style for the photos] then maybe this is an easier option that also provides more versatility in colour.

But only on this screen.

 

Edited June 17 by von Ozbourne

[Sedge]

Nice, I've been wondering for a while if there was a way to make this kind of thing work. Don't really have time to experiment with it myself right now but I'm filing it away for future reference.

[Jkline3]

Your journeys down the rabbit hole never cease to amaze me 🤣

[von Ozbourne]

Figure I'll just dump my notes here to the open source since I actually jotted them down this time in a manner that could possibly be followed by other people.

GO TO: C67E2 = Tile layout order for player photos.
0006 0006 = 6x6 layout of photos.
2000...2023 = Order of tiles for photos. Used universally for all.

Change last 6 numbers [201E 201F 2020 2021 2022 2023] to 601E...6023 to set to fourth palette.
Or change to [601E 601F 2020 2021 6022 6023] to leave the neck area as the default tones.

GO TO: C678C[HEX] or import 812940[DEC] = Palette 2000 colours used by default for photos. Note that the 3bpp Linear codec as used by the player photos, only uses the 6th through 14th colours in a palette that is referenced by the 4bpp Linear codec setting used by everything else.

GO TO: 4D614[Hex] or import 316948[DEC] = Palette 6000 colours for default main menu background.
This is not normally used and is conveniently left blank. Change the following eight colours to White, Black an an array of basic uniform and neck tone colours.

GO TO: 11CE02[HEX] or import 1166854[DEC] = Palette 6000 colours used by coloured Ron Barr photo plus Overlays and HOT/COLD graphics.
Change the following eight colours to THE SAME colours used in the previous location. Coordinate this with Ron Barr and HOT/COLD sprites, noting that those assets are also able to use the remaining eight colours to get the desired look. Advised to leave white as the first colour as this is also shared with the "window frames" and the "MATCHUPS" title.

GO TO: E9146[HEX] or imprt 954694[DEC] = Palette 0000 colours used by Player Card screen text and background.
Change the following eight colours to THE SAME colours used in the previous TWO locations. Note that for some reason this change uses screen palette 0000 instead of 6000 so it will affect the background and overlaying text on the this screen. Leaving white alone is a good idea. 
On a side note, changing the entire Player Card background to use palette 6000, will make the background share the same palette at the NHL/PA logos. As the logos are only greyscale anyway, the default background colours can be shifted here without being much of a problem for the logos. Just be sure to edit the logos to use the proper colours.

And for the banner colour overlay method.

Player Card Screen
Locations of tiles for bottom row of player photos.
E95D2-E95DC

Change 00E5 to A0E5 to change tile to use variable team colour palette as well as be moved to top layer over player photos.

Will need to borrow a couple of tiles from elsewhere in the background image to make shoulder shapes that can be layered over the player photo.
Remember to locate hex numbers for other instances of those tiles and replace them with the number of a different tile that may be close enough to not notice the change. Using the blank background blue 0000 tile in place of an almost blank background blue tile would be a good start.

Borrowed tile can now use dynamic team banner colours to make an overlay that will add jersey colour, however this overlay will also affect the team logo when viewing the team rating/starting line. If logo background is the same colour as the uniform, then this is not noticable. As long as the team logo does not overlap the area designated for the coloured shoulders.

[AdamCatalyst]

I’m trying to see if I can advance vonOz’s work here, and while I am still confused by aspects of this, there is one component that completely eludes me… how do we change “the system” to expect a 4bpp encoded image instead of a 3bpp encoded image? 

Does anyone out there have any thoughts they could share on how that may be done?

[AdamCatalyst]

Could it really be this "easy"?

Going to look over Wboy's old notes on this, see if there is an answer hidden therein.

[Drezz]

I actually tried that. It didn't work for me, but I didn't really use a lot of brainmeat on pursuing it much further than an initial look.

[AdamCatalyst]

I've got a beautiful set of 16-colour photos all ready to go, optimized palette, a structure for where to store them in the ROM, etc. but alas I cannot figure out the simple act of telling the ROM to expect images in a 4bpp format. I've pretty much given up, unless someone else can crack this detail for us.

[Drezz]

It might be a memory related thing. When I was doing the tests for the background tile and the main menu BG image, I ran into a lot of issues with memory errors.