It is currently Wed May 22, 2019 9:55 am

 All times are UTC - 7 hours

### Forum rules

• For making cartridges of your Super NES games, see Reproduction.

 Page 2 of 2 [ 26 posts ] Go to page Previous  1, 2
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: Trying to use TILE LAYER PROPosted: Tue Nov 06, 2018 4:21 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21392
Location: NE Indiana, USA (NTSC)
Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.

_________________
Pin Eight | Twitter | GitHub | Patreon

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Tue Nov 06, 2018 5:04 pm

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 214
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.)

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Tue Nov 06, 2018 5:51 pm

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

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Tue Nov 06, 2018 8:03 pm

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4073
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:
----------------------------------------------------------------------------
|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:
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:
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.

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Tue Nov 06, 2018 8:33 pm

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
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.

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Wed Nov 07, 2018 10:43 am

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

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Wed Nov 07, 2018 1:26 pm

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4073
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:
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! :-)
Attachment:

Capture.PNG [ 14.34 KiB | Viewed 3404 times ]

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Wed Nov 07, 2018 5:35 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21392
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Wed Nov 07, 2018 9:41 pm

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

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Wed Nov 07, 2018 9:47 pm

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4073
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?

Top

 Post subject: Re: Trying to use TILE LAYER PROPosted: Thu Nov 08, 2018 5:15 pm

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
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.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 2 of 2 [ 26 posts ] Go to page Previous  1, 2

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 6 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki