About tile editing...

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

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

Re: Trying to use TILE LAYER PRO

Post by tepples »

Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.
niconii
Posts: 219
Joined: Sun Mar 27, 2016 7:56 pm

Re: Trying to use TILE LAYER PRO

Post by niconii »

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: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: Trying to use TILE LAYER PRO

Post by qwertymodo »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Trying to use TILE LAYER PRO

Post by koitsu »

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.
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: Trying to use TILE LAYER PRO

Post by Señor Ventura »

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: 610
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Trying to use TILE LAYER PRO

Post by creaothceann »

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
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Trying to use TILE LAYER PRO

Post by koitsu »

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! :-)
Capture.PNG
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Trying to use TILE LAYER PRO

Post by tepples »

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: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Trying to use TILE LAYER PRO

Post by 93143 »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Trying to use TILE LAYER PRO

Post by koitsu »

None of us in this thread knows what the OP is trying to do with his work. We don't know if he just wants colours from sprites or tiles to use on a web page, if he's trying to make graphics to display on the SNES natively, if he's trying to reproduce them for another console or to something on PC, if it's just for screenshots in general, or if to understand how something works. Whether or not screenshots vs. native CGRAM values vs. whatever is irrelevant we simply don't know. All of this probably confuses the fellow even more. Are we having fun yet?
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: Trying to use TILE LAYER PRO

Post by Señor Ventura »

koitsu wrote:None of us in this thread knows what the OP is trying to do with his work. We don't know if he just wants colours from sprites or tiles to use on a web page, if he's trying to make graphics to display on the SNES natively, if he's trying to reproduce them for another console or to something on PC, if it's just for screenshots in general, or if to understand how something works. Whether or not screenshots vs. native CGRAM values vs. whatever is irrelevant we simply don't know. All of this probably confuses the fellow even more. Are we having fun yet?
I pretend to edit some sprites, and in general to check some things more to do.

Image
Image
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: About tile editing...

Post by Señor Ventura »

Greetings to all, glad to see nesdev online again :)


I would like to ask something about "snes tiles kitten" (i don't know if someone knows that program)... i'm trying to find out where to get the color palette location to put in the program to avoid to have doing it color to color, and so i could save to a preset.

Image
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: About tile editing...

Post by Oziphantom »

put a brake point on the memory address in CG ram that holds one of the 16 values you need for the pallete.
Then when it breaks, you will probably have a DMA to CGRAM so you can look at the address the DMA started at, you might need to add 32 to it for each pallete you need to skip if they are DMAing more than one, and you don't want the first one.

Or you will have code that manually writes to the CGRAM port, so you will have to look at what value they read from, probably a LDA [address],y command. where the contents of the 24 bits at address or maybe only 16bits if its in bank so you will need to add the current bank to it, so say it was bank 87 and the address is $B830 then the source address will be 87B830.

All of the above addresses will be in SNES location
User avatar
Señor Ventura
Posts: 233
Joined: Sat Aug 20, 2016 3:58 am

Re: About tile editing...

Post by Señor Ventura »

Oziphantom wrote: Mon Jan 03, 2022 4:00 am put a brake point on the memory address in CG ram that holds one of the 16 values you need for the pallete.
Then when it breaks, you will probably have a DMA to CGRAM so you can look at the address the DMA started at, you might need to add 32 to it for each pallete you need to skip if they are DMAing more than one, and you don't want the first one.

Or you will have code that manually writes to the CGRAM port, so you will have to look at what value they read from, probably a LDA [address],y command. where the contents of the 24 bits at address or maybe only 16bits if its in bank so you will need to add the current bank to it, so say it was bank 87 and the address is $B830 then the source address will be 87B830.

All of the above addresses will be in SNES location
mmm... let's see... i entered in the memory editor of bsnes (selecting "SPPU CGRAM" in it), and i put a brake before the first stage got begun, updating this line in the list:

Image



in "properties viewer" i see this:

Image



I will edit the message later, for now i have to stop for a while...
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: About tile editing...

Post by Oziphantom »

you don't want the CGRAM address, although it shouldn't be 0, unless this is after it has written the last byte. You need to look at the code and work out if it using DMA or a manual copy loop and then find the starting address given to the DMA code or the manual copy loop.
Post Reply