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.