## Trying to use TILE LAYER PRO

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
• For making cartridges of your Super NES games, see Reproduction.
tepples
Posts: 22093
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

### Re: Trying to use TILE LAYER PRO

Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.

Nicole
Posts: 218
Joined: Sun Mar 27, 2016 7:56 pm

### Re: Trying to use TILE LAYER PRO

Señor Ventura wrote:You mean these directions are in base 10, and i have to interpret it like base 16?.
No. What they're saying is that, on the SNES, each color channel ranges from 0 to 31 (\$00 to \$1f in hex), instead of 0 to 255 (\$00 to \$ff in hex). You need to scale those numbers to the correct range or they'll look too dark, which is why they all look black to you.

This problem doesn't have anything to do with base 10 vs. base 16. It sounds like you don't really understand what those terms mean, but "base 10" just means the normal decimal numbers we use every day, that use digits from 0 to 9. Because of that, you should know that "1c 14 0c" can't possibly be base 10 numbers, since "c" isn't a decimal digit. (Also, no, converting between base 10 and base 16 isn't that simple.)

qwertymodo
Posts: 774
Joined: Mon Jul 02, 2012 7:46 am

### Re: Trying to use TILE LAYER PRO

Señor Ventura wrote:Thank you very much, it works perfectly, but for now i don't know if this debugger gives what i need.

I have no much time until this night, but i've seen this:

How is supossed to be used with YY-CHR editor? (link). If i divide every group of number in three section for RGB, all i have are black colors, so, i've don't doing it well.

But i don't see any other option in SNES9X that can help me to obtain the correct color info (i only have 5 minutes to have a look).

Thank you again
YY-CHR can't use palette data from Snes9x, for whatever crazy reason they chose ZSNES save state files (*.zst files) as the format they chose to support. In order to use them, open the game in ZSNES and play to the point where the palette you want is shown on screen (usually meaning going to the same place in-game where the tiles you want to view are actually used), and take a save state. Then in YY-CHR you can import the .zst file. As far as the data you posted, I guess you could probably enter all of those numbers in by hand if you wanted to go that route though.

koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm

### Re: Trying to use TILE LAYER PRO

Señor Ventura wrote:You mean these directions are in base 10, and i have to interpret it like base 16?.

I don't know in what form "1c 14 0c" from base 10 are increased to base 16... adding up by 6 positions?, is so simple like that? :?:
No, decimal vs. hexadecimal (base conversion) has nothing to do with it.

Some education is below. It helps to understand a little bit about how the SNES works, and then what SNES9x is showing you. I'll explain both.

For most graphics modes on the SNES, the SNES stores its R/G/B values for CGRAM (palette RAM) in a single 16-bit number. The top bit (bit 15) is 0, and the remaining bits are in the order of B/G/R. Taken from my old SNES docs:

Code: Select all

`````` ----------------------------------------------------------------------------
|The SNES has some interesting colour characteristics. The colour, theoret-  |
|ically is 15 bit; each RGB value (Red, Green, and Blue) has 5 bits for each |
|colour.                                                                     |
|                                                                            |
|When it comes to putting the colour data into \$2122, the format (in binary) |
|is the following:                                                           |
|  b: Blue                   ?bbbbbgg gggrrrrr                               |
|  g: Green                                                                  |
|  r: Red                                                                    |
|  ?: The infamous bit-of-confusion. :-)                                     |
|                                                                            |
|A quick colour chart could be the following:                                |
|  \$7FFF [0111 1111 1111 1111]: White.                                       |
|  \$001F [0000 0000 0001 1111]: Red.                                         |
|  \$03E0 [0000 0011 1110 0000]: Green.                                       |
|  \$7C00 [0111 1100 0000 0000]: Blue.                                        |
|  \$7C1F [0111 1100 0001 1111]: Purple.                                      |
|  \$7FE0 [0111 1111 1110 0000]: Aqua.                                        |
|  \$03FF [0000 0011 1111 1111]: Yellow.                                      |
----------------------------------------------------------------------------
``````
What this tells you is that each red, green, and blue value can range from \$00 to \$1F (hexadecimal), or 0 to 31 (decimal).

What SNES9x does is take each of those 5-bit numbers and give them each their own byte. It also puts them in R/G/B order, instead of B/G/R order like on the SNES. So now you have the a single colour in the SNES shown using a 24-bit number, in R/G/B order. Let's decode the first row you pastes:

Code: Select all

``````rrggbb
------
000000 -- red = \$00, blue = \$00, green = \$00
060101 -- red = \$06, blue = \$01, green = \$01
1e1300 -- red = \$1e, blue = \$13, green = \$00
1a0500 -- red = \$1a, blue = \$05, green = \$00
000000 -- red = \$00, blue = \$00, green = \$00
101010 -- red = \$10, blue = \$10, green = \$10
1c1c1c -- red = \$1c, blue = \$1c, green = \$1c
181818 -- red = \$18, blue = \$18, green = \$18
...
``````
You're almost done.

One of the tricky parts of the SNES is that the colours only range from 0 to 31, as shown. If you used these values directly, you'd find they're way, WAY too dark -- that's because the SNES's PPU or video circuitry amplifies the colour in some way (don't worry about this).

On a PC usually red, green, and blue range from 0 to 255 each. This is why tepples told you to take each red/green/blue number and multiply them by 8 to get a larger value. So, for example, let's do the math:

Code: Select all

``````rrggbb
------
000000 -- red = \$00, blue = \$00, green = \$00.  Multiplied by 8 each: red = \$00, blue = \$00, green = \$00
060101 -- red = \$06, blue = \$01, green = \$01.  Multiplied by 8 each: red = \$30, blue = \$08, green = \$08
1e1300 -- red = \$1e, blue = \$13, green = \$00.  Multiplied by 8 each: red = \$f0, blue = \$98, green = \$00
1a0500 -- red = \$1a, blue = \$05, green = \$00.  Multiplied by 8 each: red = \$d0, blue = \$28, green = \$00
000000 -- red = \$00, blue = \$00, green = \$00.  Multiplied by 8 each: red = \$00, blue = \$00, green = \$00
101010 -- red = \$10, blue = \$10, green = \$10.  Multiplied by 8 each: red = \$80, blue = \$80, green = \$80
1c1c1c -- red = \$1c, blue = \$1c, green = \$1c.  Multiplied by 8 each: red = \$e0, blue = \$e0, green = \$e0
181818 -- red = \$18, blue = \$18, green = \$18.  Multiplied by 8 each: red = \$c0, blue = \$c0, green = \$c0
...
``````
Make sense?

In general, SNES emulators -- for whatever stupid reason -- do not generally let you "save" or "export" a .pal file that correlates with that of, say, PC graphics or a JPG/GIF/PNG/whatever. If you want that, the easiest way to get it is to do a Screenshot and then work off of that palette. Though, this might not contain all of the colours in the SNES CGRAM at the time.

In general, "helpful" tools like this do not tend to exist in common SNES emulators today. Don't ask me why -- we had MS-DOS tools in the early 90s that did this when converting PC and Amiga graphics to/from SNES and vice-versa (particularly using the PCX file format), but today nothing bothers to implement them. As Trump would say: SAD!

Everyone else's explanations are correct/true as well. Use whatever method you can to get what you want. But as you're learning, the tool situation is not good.

Señor Ventura
Posts: 152
Joined: Sat Aug 20, 2016 3:58 am

### Re: Trying to use TILE LAYER PRO

tepples wrote:Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.
6 - 2 - 6 -
1 C 1 4 0 C
x 8
__________
E 0 B 0 6 0

Why B and not A? (8x1=8 + 2= 10= A).

I need to sleep something ^^
Nicole wrote: No. What they're saying is that, on the SNES, each color channel ranges from 0 to 31 (\$00 to \$1f in hex), instead of 0 to 255 (\$00 to \$ff in hex). You need to scale those numbers to the correct range or they'll look too dark, which is why they all look black to you.

This problem doesn't have anything to do with base 10 vs. base 16. It sounds like you don't really understand what those terms mean, but "base 10" just means the normal decimal numbers we use every day, that use digits from 0 to 9. Because of that, you should know that "1c 14 0c" can't possibly be base 10 numbers, since "c" isn't a decimal digit. (Also, no, converting between base 10 and base 16 isn't that simple.)
Yes, sorry, i meaned that 5 bit are some less hexadecimal positions (5 bits for 10, and 8 bits for 16).
qwertymodo wrote:YY-CHR can't use palette data from Snes9x, for whatever crazy reason they chose ZSNES save state files (*.zst files) as the format they chose to support. In order to use them, open the game in ZSNES and play to the point where the palette you want is shown on screen (usually meaning going to the same place in-game where the tiles you want to view are actually used), and take a save state. Then in YY-CHR you can import the .zst file. As far as the data you posted, I guess you could probably enter all of those numbers in by hand if you wanted to go that route though.
The .zst files doesn't seems to work, i will try again tomorrow.
koitsu wrote:...
Thank you for responding, i have much to read, but i keep your message... all that you can say is valuable for me.

creaothceann
Posts: 266
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

### Re: Trying to use TILE LAYER PRO

qwertymodo wrote:open the game in ZSNES and play to the point where the palette you want is shown on screen (usually meaning going to the same place in-game where the tiles you want to view are actually used), and take a save state. Then in YY-CHR you can import the .zst file. As far as the data you posted, I guess you could probably enter all of those numbers in by hand if you wanted to go that route though.
vSNES can be used as a palette editor / converter; it supports both ZSNES and SNES9x (v1.43 iirc) savestates and can input/output palette files in various formats.
koitsu wrote:One of the tricky parts of the SNES is that the colours only range from 0 to 31, as shown. If you used these values directly, you'd find they're way, WAY too dark -- that's because the SNES's PPU or video circuitry amplifies the colour in some way (don't worry about this).

On a PC usually red, green, and blue range from 0 to 255 each. This is why tepples told you to take each red/green/blue number and multiply them by 8 to get a larger value.
A slightly better way is to shift all bits 3 times to the left (i.e. multiply the value by 8) and fill the lowest 3 bits with the highest 3 bits.
koitsu wrote:In general, SNES emulators -- for whatever stupid reason -- do not generally let you "save" or "export" a .pal file that correlates with that of, say, PC graphics or a JPG/GIF/PNG/whatever.
Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm

### Re: Trying to use TILE LAYER PRO

creaothceann wrote:Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.
1. Yes, but the majority of titles do not do this, nor do they use direct colour mode. Let's be practical here, not pedantic.
2. Yes, and? That's exactly what's being done above. Every algorithm is going to be different based on a multitude of variables that aren't worth going into here (for the OP's sake).

For #2, usually the painstaking efforts have to fall onto the responsibility of the graphics editing tool, since palette/colour-wise what it shows visually on screen during editing, RGB-wise, *are not* the literal values that end up in CGRAM. So a tool like YY-CHR, etc. has to deal with all of this.

The added complication lies in the fact that emulators and what they potentially can export, palette-wise, are not necessarily a format that YY-CHR and other utilities can support. People think the .pal extension is some kind of "standard" -- it isn't.

So these two complications are almost certainly why things resorted to reading from ZST (ZSNES save state) files instead -- because the format was known/documented. (It also helps to know that things like YY-CHR were created around the heyday of ZSNES).

But my point stands: we had tools that did this in the early 90s. We generally do not now, despite having emulators. "Integration" (not the right/accurate word but whatever) between tools and emulators was somehow lost in the early 2000s. I suspect this is because people were *substantially* more focused on emulating games and not on snesdev -- and that's still generally the case today (even tools like NO\$SNS don't allow it). The end result is, well, things like this thread. :-)

Here are some of the MS-DOS tools used back in the day:

Code: Select all

``````1996-11-16  07:16            18,960 GFXCONV.EXE
1993-07-12  16:30            37,845 GIF2SNES.EXE
1993-11-24  12:05            47,630 GIF2SOPT.EXE
``````
There's equivalent for PCX files and SNES, but I can't seem to find them currently (NES yes, SNES no). I remember this because the toolset came with binaries for PCX and GIF, and I chose to keep the GIF tools because I didn't have a PCX graphics editor at the time.

And oh look, *another* utility by Norman Yen of x816 fame! :-)

tepples
Posts: 22093
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

### Re: Trying to use TILE LAYER PRO

koitsu wrote:
creaothceann wrote:Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.
1. Yes, but the majority of titles do not do this, nor do they use direct colour mode. Let's be practical here, not pedantic.
That's news to me. I thought more games used HDMA to CGRAM[0] or to COLDATA to make the sky a nice gradient.

For converting PC-friendly image formats to Super NES tile format, I ended up writing my own tools in Python. But then I wrote them from the perspective of someone making an original game, not someone trying to hack someone else's ROM.

93143
Posts: 1242
Joined: Fri Jul 04, 2014 9:31 pm

### Re: Trying to use TILE LAYER PRO

Regarding colour math, was it really that rare? I was under the impression that it was used early and often, though I admit my experience is mainly with a focused selection of games...

F-Zero, for example, uses it to make your health bar partly transparent, as well as to produce an HDMA-driven distance effect on the upper part of the Mode 7 area, and to draw the shadow under the player's machine. All of these can and do produce colours that aren't in the palette. The title screen alone displays 259 unique colours, and it's not like it tries very hard.

Trying to do a palette rip from a screenshot of a ghost house in SMW or a misty cave in DKC isn't going to go well.

koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm