It is currently Tue Nov 20, 2018 8:27 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Nov 06, 2018 4:21 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20791
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.


Top
 Profile  
 
PostPosted: Tue Nov 06, 2018 5:04 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 172
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
 Profile  
 
PostPosted: Tue Nov 06, 2018 5:51 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 770
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
 Profile  
 
PostPosted: Tue Nov 06, 2018 8:03 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3694
Location: Mountain View, CA
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
 Profile  
 
PostPosted: Tue Nov 06, 2018 8:33 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 76
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
 Profile  
 
PostPosted: Wed Nov 07, 2018 10:43 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 144
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.


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 1:26 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3694
Location: Mountain View, CA
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
Capture.PNG [ 14.34 KiB | Viewed 641 times ]


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 5:35 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20791
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.


Top
 Profile  
 
PostPosted: Wed Nov 07, 2018 9:41 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 974
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
 Profile  
 
PostPosted: Wed Nov 07, 2018 9:47 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3694
Location: Mountain View, CA
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
 Profile  
 
PostPosted: Thu Nov 08, 2018 5:15 pm 
Offline
User avatar

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 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 3 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group