Trying to use TILE LAYER PRO

Hello...

I'm trying to use this programs, but its restrictiveness confuses me a bit with the way of having to choose an specific palette to allow you to see the graphics.

Can somebody tell me some topics to learn how to achieve to know what is the correct palette, and how to obtain from every rom?.


Thank you.

This is just the nature of working with old console graphics formats. Char data is stored raw, without any kind of attached data such as palette assignments or size. This is because that information is supplied by other data formats: palettes, tilemaps, and OAM entries, which are going to be game-specific in terms of where they're stored and possibly how they're formatted within the ROM. Knowledge of where the palettes are will require knowledge of the game itself.

And since we're talking about about the SNES here, there aren't even any guarantees that the tiles themselves will be visible in a tile editor, since they could very well be compressed, and each game may use a different compression scheme, much like different games store palette data and tile layouts differently. There's no universal way to handle this, you have to know how each individual game does things in order to gather all the graphical data you want.

BSNES Debugger allows you to view CGRAM, so you can copy the palettes from there. However, whatever palette you want has to currently be onscreen. As has been stated earlier, there's no real easy way to do this.

THAT is the info i expected (where to get what palettes is using every game). I don't use bsnes to keep an eye to debugging, so i was a little bit lost.

Thank you to all!

The more I read the more I get lost...

It seems tile molester is a more advanced program to edit tiles, but there is not any executable, Am I missing something?

If there is a "jar" file, then that is the executable. You just need a jar player installed, and the most common is Java by Oracle.

Last time I tried to use tile molester, it gave me a security warning, can't run, unknown publisher.

I just used something else, rather than try to deal with this issue. I haven't thought about it since.

Java warns about this for all applications whose publisher hasn't paid the code signing certificate authority racket. Unlike HTTPS (TLS on websites), which allows a certificate to be domain-validated (and therefore obtainable without charge from an automated CA), code signing requires all certificates to be at least organization-validated.


"Last time I tried to use vigilante ninja 2, it gave me a security warning, can't run, unknown publisher. [The power light just blinked.] I just used something else, rather than try to deal with this issue. I haven't thought about it since."

Ok, thank you, i was starting to desperate xD

Sorry for upping the thread.

I'm trying to use the No$sns debug, but all the information color that i get of every palette is incorrect, giving always a black color in every slot of every palette.

I've done some improvements, but totally blinded cause i can't get the real color information... so, the question is, what debugger can i use to try it from another side?.





P.D: Snes9X1.51.ep10r2 gives me an error and it can't initialize.
"The application could not be started; the parallel configuration is not correct. Check the application's event log or use the sxstrace.exe tool on the command line to get more details".

Any advice?.


Greetings.

The SNES9x error you get is because the program requires a **very** specific version of Visual C++ Runtimes, and for x86 (not x64). Without it, you get an incredibly nebulous and weird error. Attached is a .zip of the vceredit_x86.exe needed.

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:

Palette:
000000 060101 1e1300 1a0500 000000 101010 1c1c1c 181818 000000 100c00 1c1814 000000 000000 050812 0e1619 1b1f1f 0b0412 040b01 000800 010400 0b0412 0b0903 070603 050301 0b0412 0b0a08 080706 050503 000000 000800 070806 050503 001217 1f1e1e 1a1a18 111110 0a0907 060503 1e1a09 130500 141415 0f0e0e 0a0906 060502 130901 0e1700 030b00 000000 0b0412 010401 0a0601 0b0905 030201 050902 030700 000800 020601 17130f 14100d 110c07 0d0a06 090604 050402 000000 0b0412 151515 131312 0f0e0e 0c0b0b 080804 060503 030201 191919 1c140c 160d06 0e0602 0a0300 130700 0c0300 000000 150c13 161614 131311 10100b 0c0c08 080807 050505 030303 060100 090201 0b0502 0b0601 0b0703 080503 060301 000000 0a0a00 000a14 000e18 001418 141a1a 1e1e1e 1a1812 14100a 0e0c00 0c0c0c 121210 1e1600 1a1000 160000 100000 020202 0b0412 000000 060300 090300 010401 030b00 091000 0e1700 141e00 1c1f07 030100 1c1510 1c140c 160d06 0e0602 020600 000000 0a0c10 0e1014 121418 14161a 1e1e1e 181812 14140e 0e0a00 100c00 16120e 1c1814 000c16 180c00 100000 020202 000000 0a0c10 0e1014 121418 14161a 1e1e1e 1a1a0e 16160a 101000 0c0c00 061f12 00160c 001008 1e1200 180a00 010101 000000 00000e 000012 000618 00101e 1e1c1b 1e1e10 18180e 101008 0c0c04 18140e 100c00 0e0a00 1a0600 140400 010101 000000 0e0200 140600 180a00 1a0e00 1c1c1c 151515 0f0f0f 080808 1e1000 1c1406 0c161e 0a121a 060e18 020a10 010101 000000 0f0800 110a07 130f09 18130e 120e0a 17130f 1c1a16 190000 0f0000 000000 000000 191919 121212 0e0e0e 020202 000000 000a15 000e19 001519 161d1d 1f1f1f 17191c 111315 0d0f10 0a0a0a 151513 1e1600 1a0c00 160600 110100 010101 000000 030305 050508 0d0c12 15161c 1f1f1f 040902 070c04 0d1107 1c1f07 000000 000000 000000 000000 000000 020202 000000 16120e 1c1814 000000 000000 000000 1c1e1e 141a1e 0e161a 000e16 151300 1c140c 150c05 0b0400 070200 020202


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

SNES palettes are 5 bits per element, so you probably have to scale them to 8 bits, remapping the $00..$1F range into $00..$FF.

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?

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.

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.)

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.

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:


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:


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:


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.

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 ^^



Yes, sorry, i meaned that 5 bit are some less hexadecimal positions (5 bits for 10, and 8 bits for 16).



The .zst files doesn't seems to work, i will try again tomorrow.



Thank you for responding, i have much to read, but i keep your message... all that you can say is valuable for me.

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.


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.


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:

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! :-)

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.

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.

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.