Re: Trying to use TILE LAYER PRO
Posted: Tue Nov 06, 2018 4:21 pm
Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.
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.Señor Ventura wrote:You mean these directions are in base 10, and i have to interpret it like base 16?.
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.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
No, decimal vs. hexadecimal (base conversion) has nothing to do with it.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? :?:
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. |
----------------------------------------------------------------------------
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
...
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
...
6 - 2 - 6 -tepples wrote:Multiply each pair of hex digits by eight to get a reasonable approximation. For example, 1C 14 0C becomes E0 A0 60.
Yes, sorry, i meaned that 5 bit are some less hexadecimal positions (5 bits for 10, and 8 bits for 16).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.)
The .zst files doesn't seems to work, i will try again tomorrow.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.
Thank you for responding, i have much to read, but i keep your message... all that you can say is valuable for me.koitsu wrote:...
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.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.
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: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.
Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.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.
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.creaothceann wrote:Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.
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
That's news to me. I thought more games used HDMA to CGRAM[0] or to COLDATA to make the sky a nice gradient.koitsu wrote: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.creaothceann wrote:Well, CGRAM can be changed per line and screenshots often contain pixels that were created with color math.
I pretend to edit some sprites, and in general to check some things more to do.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?
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: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