SNES, where to start?

[psycopathicteen]

There's also bass, xkas, and asar, for those who want to be able to move the direct page around.

[DoNotWant]

bass is a great assembler by byuu, and has an active support forum here: http://board.byuu.org/phpbb3/viewforum.php?f=20

[Optiroc]

There's also bass, xkas, and asar, for those who want to be able to move the direct page around.

Not the slightest impossible with ca65. Just use the z:-modifier and you're set. Here (in the SFX_INIT_mmio function) I do the canonical PPU initalization using direct page addressing with some helper macros.

[nicklausw]

Digging up my old questions thread because there's no need for a new one.

Does anyone know if there's a good way to make SNES graphics other than the combination of aseprite and pcx2snes?

I've been thinking about making my own little snes paint program. I'd just need to know how the system's palette works, and iirc it's 15-bit bgr? And I saw a page on wiki.superfamicom.org that teaches conversion between that and 24 bit color.

Also are SNES tiles 4bpp, 8bpp...?

[lidnariq]

SNES sprites are always 4bpp.

SNES background tiles are selectably 2bpp, 4bpp, or 8bpp, and each background tile is selected from one of eight different palettes.

[freem]

Does anyone know if there's a good way to make SNES graphics other than the combination of aseprite and pcx2snes?

I use YY-CHR for all my console tile editing needs (which includes SNES support)... dunno if it'll be the right fit for you, but it's an alternative.

[Drew Sebastino]

Does anyone know if there's a good way to make SNES graphics other than the combination of aseprite and pcx2snes?

I don't know what aseprite is, but I just use Gimp (it can create indexed images, and you can sort around the colors) and pcx2snes. It works fine, but the color converting can be annoying. (I don't think there's a way to make Gimp work in 15 bit color.)

it's 15-bit bgr?

Yes. I'm pretty sure the unused bit is the highest one, so it looks like

0bbbbbgg gggrrrrr

Also are SNES tiles 4bpp, 8bpp...?

2bpp, 4bpp, and 8bpp. Sprites are always 4bpp, while BG layers can be any of these color depths.

If you want to know the graphics format (it would probably be useful for this program of yours) I think it's like this:

Code: Select all

2bpp 00 00 00 00
4bpp 00 00 00 00
     00 00 00 00
8bpp 00 00 00 00

Basically, 4 4bpp pixels are set up like 8 2bpp pixels, if that makes sense. The space between the 0's (which are the bits) are the boundaries of where a pixel ends and a new one starts. Does that make sense to you? I don't really know how to explain it.

Luckily though, with mode 7, it's a much easier to understand format in that 1 pixel is just 8 bits across. Map data is interweaved with the tile data, byte per byte, although I'm not sure the order.

Anyway, I think that's about it. I'm probably accidentally giving you false information...



Wow, lidnariq beat me while I was writing this...

[Kannagi]

I've been thinking about making my own little snes paint program.

Why ? Gimp or Photoshop is not enough?

Does anyone know if there's a good way to make SNES graphics other than the combination of aseprite and pcx2snes?

I do'nt know these tools, allows aseprite to do what?
I find it strange to make pcx2snes, I find the png more convenient.
I use a png / snes conversion tools, with option for pallete.

it's 15-bit bgr?

yes, the conversion is so easy to do.

[nicklausw]

Alright, thanks, it looks like YY-CHR's C# version suits my needs. Thanks to tepples' tutorial I've got the palette loaded, now the 4bpp font...

[93143]

The tile format is weird to someone used to the NES. (Actually, it's weird regardless.)

It's a 16-bit format, probably because of the way VRAM is set up. The first byte is the first bitplane of the first 8x1 sliver of a tile. The second byte is the second bitplane of the same sliver. Then the third byte is the first bitplane of the second sliver, and the fourth byte is the second bitplane of the second sliver, on to the end of the tile (16 bytes). If the BG layer in question is 2bpp, you're done. If not, the whole pattern repeats from the top of the tile for the third and fourth bitplanes, for another 16 bytes. For sprites and 4bpp BG layers, that's the whole story, but for 8bpp backgrounds that whole story repeats to provide the last four bitplanes. So a 4bpp tile is two 2bpp tiles in a row, and an 8bpp tile is four 2bpp tiles in a row.

Also, obviously 8bpp graphics can't select subpalettes. Unless you're using direct colour, which uses the palette selector bits to add colour depth.

[dougeff]

8bpp, is that modes 3-4 (256 color BG)? And maybe mode 7?
What's direct colour?

Also, I said it earlier, and I'll say it again. It would be great of someone made a NES screen tool style tile arranger tool for the SNES.

[93143]

Yes, BG1 is 8bpp in Modes 3, 4, and 7.

Direct colour mode can be set via $2130, and only works on 8bpp backgrounds. It uses what would have been the 8-bit index into CGRAM as RGB332 (well, strictly BB000GGG00RRR00), and the palette selector bits are used to expand that to RGB443 (BBb00GGGg0RRRr0, but the 'bgr' is per-tile instead of per-pixel). Note that the Mode 7 tilemap doesn't have palette selector bits, so you're stuck with RGB332 if you're using direct colour in Mode 7.

http://problemkaputt.de/fullsnes.htm#sn ... rectcolors
http://wiki.superfamicom.org/snes/show/Backgrounds
http://wiki.superfamicom.org/snes/show/Registers

[dougeff]

Ok. I had to read your explanation 4 times, but I think I get it. In 256 color modes, each pixel uses 8 bits to define a color. Rather than indexing from the palette, those 8 bits defines the color itself. But, with fewer color options, since it only defines 2,3,3 (8 bits) for a color rather than a full palette entry 5,5,5 (15 bits) for a color.

And this sounds like something that I would not want to do, because 256 seems like enough colors to choose from.


Edit, actually... maybe it would be much easier to write a tool to convert a full color picture to SNES pixels if I were using direct color mode. Hmm. I'll have to experiment some day, and see what kind of results that gets.

[93143]

Sorry; I see now how that could have been hard to read.

Just a clarification (it doesn't sound like you need it, but I've seen people screw this up and you aren't the only person reading this thread): An 8bpp layer is normally indexed; it uses all of CGRAM as its palette. Direct colour is an option for those layers, not the default behaviour.

And I'm pretty sure it's not a popular option. I think 8bpp indexed tends to look better, since you have free choice of all the colours in the RGB555 master palette. But I'm sure there's an application for this feature hiding somewhere...

[lidnariq]

Edit, actually... maybe it would be much easier to write a tool to convert a full color picture to SNES pixels if I were using direct color mode. Hmm. I'll have to experiment some day, and see what kind of results that gets.

Direct-color mode isn't terribly useful for things as simple as that: you can think of it as one specific pregenerated palette that you could also have explicitly uploaded to CGRAM. (There's also been hundreds of different kinds of algorithms for determining a set of colors to use with truecolor-to-palette conversion. e.g. those algorithms used by mtpaint, animmerger,or Display, almost all of them produce better results than just static non-adaptive rgb332)

The only thing that comes to mind is that you could use a direct-color 8bpp plane with a separate palette for sprites and a 2/4bpp tile layer, but you might just be in danger of running out of memory for tiles at that point.