Question about Mode 3's full colour capablities

[Kirk_Johnston]

Watch at the 4:35 mark for where he talks about direct colour, or go back and watch from 4:15 to get the full details of Mode 3.

 

Can someone who understands the SNES as well as the guy in the video confirm if my thinking here is correct:

 

Is he saying that, with direct colour and the three extra RGB bits activated for BG1, the SNES can display any one of those 2048 RGB colours on each 8x8 background tile and a total of 2048 colours on-screen on BG1 alone? And then BG2 can display an additional 128 CGRAM colours at 4bpp on top of that, plus the 128 CGRAM colours at 4bpp for the sprites too?

 

Basically, is saying the SNES could technically show around 2304 colours on-screen if used for say a full-screen image using both the two background layer colours and sprite colours combined, when layered in some way as to use all three of them effectively on a single image, if someone wanted to do so?

 

Also, I presume I could actually have pure black and white in such an image just by adding and using those in the BG2 or sprite palettes and cutting out any pixels in BG1 where I want any pure black and white to be displayed?

Edited December 20, 2022 by Kirk_Johnston

[jeffythedragonslayer]

On 12/19/2022 at 7:46 PM, Kirk_Johnston said:

Is he saying that, with direct colour and the three extra RGB bits activated for BG1, the SNES can display any one of those 2048 RGB colours on each 8x8 background tile and a total of 2048 colours on-screen on BG1 alone?

 

Not quite.  Let's talk about BG1 first.  In direct color, those 3 extra RGB bits (the attribute bits) can only be controlled on a per-tile basis.  Whatever choice you make for those bits, you're locked into that same choice for every pixel in the same tile.  But if you don't care about what color neighboring pixels are, sure you can make whatever pixel you want any one of those 2048 colors.  2^3 = 8, so it would take 8 tiles to cycle through every possible choice for those 3 extra RGB bits, and then within each of those tiles you have 8 bits of color left to choose to set however you like, so within a single tile you can have 256 different colors, but they can be a different 256 than neighboring tiles.  It's a bit of a poor design choice that these per-tile controlled bits are low bits of the total 15 (control color subtly) and not high bits (control color coarsely).

Now, for BG2:

All colors entries in CGRAM have 15 bits of precision.  So each one can be any of 32768 colors.  That allow fine-grained tuning of each CGRAM color.

 

In Mode 3, CGRAM's 256 entries are divided into 128 entries for the backgrounds (only BG2 uses it here since we are using direct color for BG1) and another 128 entries for the sprites.  So you have totally different colors for the background and sprites.  The first 128 colors in CGRAM are divided into 8 palettes of 4 colors each (well I guess 3 each since the first one is backdrop).

 

On 12/19/2022 at 7:46 PM, Kirk_Johnston said:

Also, I presume I could actually have pure black and white in such an image just by adding and using those in the BG2 or sprite palettes and cutting out any pixels in BG1 where I want any pure black and white to be displayed?

 

Yes I think so, you can add pure black and pure white to the CGRAM table because you have the full 15 bits of precision there.  Each background layer also has what I think of as two different sub-layers.  One is high priority (on top) and the other is low priority (underneath).  You can see the drawing order here:

https://wiki.superfamicom.org/background-priority-chart

 

The priority can be controlled on a per-tilemap entry (not per-tile instance) basis; see here: https://snes.nesdev.org/wiki/Tilemaps

 

I do not know how you derived 2304.

[Kirk_Johnston]

13 hours ago, jeffythedragonslayer said:

I do not know how you derived 2304.

OK, so, basically, the direct colour background still allows the choice of 256 colours per tile (from the more limited 2048 palette), but, across the entire screen you'd be able to have up to 2048 different colours on BG1 alone?

 

Haha. I just added the 2048 for BG1 + 128 for BG2 + the 128 for sprites and got to 2304. And, obviously, that's not considering the transparent colours in each palette or the backdrop colour and the like, just a rough total.

 

With the background priority, you could technically change it per scanline using HDMA or a raster interrupt or something like that though, right? For example, while say the top half of a background might be set to low priority, you could switch that half way down the screen to high priority and move it on top of the layer it is normally behind and such.

Edited January 3, 2023 by Kirk_Johnston

[jeffythedragonslayer]

11 hours ago, Kirk_Johnston said:

OK, so, basically, the direct colour background still allows the choice of 256 colours per tile (from the more limited 2048 palette), but, across the entire screen you'd be able to have up to 2048 different colours on BG1 alone?

Yes, but keep in mind a 8x8 tile only has 64 pixels.

11 hours ago, Kirk_Johnston said:

 

With the background priority, you could technically change it per scanline using HDMA or a raster interrupt or something like that though, right? For example, while say the top half of a background might be set to low priority, you could switch that half way down the screen to high priority and move it on top of the layer it is normally behind and such.

In general no, because the tilemap priority lives in VRAM - it's not a PPU register:

https://forums.nesdev.org/viewtopic.php?p=194049#p194049

 

I'd set up the priorities for the whole layer during VBLANK: set the top half as low priority, and the bottom half high priority.

 

EDIT: disregard "(not per-tile instance)" in my last post, could not edit.  Also, this sentence should be: "So you can have totally different colors for the background and sprites."

Edited January 3, 2023 by jeffythedragonslayer
delete (not per-tile instance)

[Kirk_Johnston]

1 hour ago, jeffythedragonslayer said:

Yes, but keep in mind a 8x8 tile only has 64 pixels.

In general no, because the tilemap priority lives in VRAM - it's not a PPU register:

https://forums.nesdev.org/viewtopic.php?p=194049#p194049

 

I'd set up the priorities for the whole layer during VBLANK: set the top half as low priority, and the bottom half high priority.

 

EDIT: disregard "(not per-tile instance)" in my last post, could not edit.  Also, this sentence should be: "So you can have totally different colors for the background and sprites."

Yeah, so, for BG1, it would have its own/separate direct colour master palette of 2048 colours (I think that makes it 9-bit colour rather than the 15-bit colour of the standard 32,768 palette, right?), of which you can ultimately/practically display 64 unique colours per tile (literally a different one for every single pixel in a tile), which could also be an entirely different/new set of 64 colours per tile chosen from that 2048 mater palette if you like, and it's still a potential maximum of 2048 colours total across the whole of BG1 layer alone.

 

And, although you can't really change the layer priority on the fly as a single screen in being drawn, it is still set on a per-tile basis in each layer anyway (during VBlank), so it's pretty versatile in how and where it's applied on each layer.

Edited January 3, 2023 by Kirk_Johnston

[jeffythedragonslayer]

Yeah, you got it, except:

 

1 hour ago, Kirk_Johnston said:

 it is still set on a per-tile basis in each layer anyway (during VBlank)

 

This doesn't just magically happen every VBLANK.  Code would have to be run on the Ricoh CPU to do this.  In general though the rule is, when your code sets some setting on the PPU or VRAM, it stays that way until code changes it again.  It doesn't have to be re-setup every frame.  Only if you are changing stuff do you need to do that.

 

Now for during a single frame, you can always FBLANK and then change the layer priority while the frame is being drawn.  Perhaps one blank scanline wouldn't be too distracting.

Edited January 4, 2023 by jeffythedragonslayer
FBLANK stuff

[Kirk_Johnston]

13 hours ago, jeffythedragonslayer said:

Yeah, you got it, except:

 

 

This doesn't just magically happen every VBLANK.  Code would have to be run on the Ricoh CPU to do this.  In general though the rule is, when your code sets some setting on the PPU or VRAM, it stays that way until code changes it again.  It doesn't have to be re-setup every frame.  Only if you are changing stuff do you need to do that.

 

Now for during a single frame, you can always FBLANK and then change the layer priority while the frame is being drawn.  Perhaps one blank scanline wouldn't be too distracting.

I think there might be some confusion regarding what I'm saying here about setting the priorities of the layers for the effect I'm talking about, which is possibly my fault and I've confused things. I just mean like this effect below, where you can have different parts of the same background with different priorities so a sprite could pass behind one part while in front of another for example:

 

https://rasterscroll.com/wp-content/uploads/2021/02/World-of-Illusion-01.mp4

 

As described here: https://rasterscroll.com/mdgraphics/graphical-effects/row-column-scrolling/

 

And, obviously, this works for just backgrounds displaying on top of and under other backgrounds too. So, my thinking is you could have two backgrounds with certain tiles set to high priority and others low on both layers, and both layers also with various colour 0 pixels in appropriate places similarly used to only show a single pixel or so from the other layer through the gap and such, basically where necessary to get closet to the original colour of some lovely high-colour image or whatever. Ultimately, with the combination of those things allowing for far more colours in both single tiles and the screen overall than just full tiles on a single background can show and therefore creating some really nice high-colour images. So, I don't think there's any need for blank scanlines and other compromises like that to do what I'm saying.

 

But, if you're actually saying the same thing, and are just adding in some extra details around how this is done in code, then I think we're on the same page.

 

On a related note, I just thought I'd post some standard Mode 3 images again, this time with any unnecessary borders removed, just to show how lovely they can look on SNES, and that's how they would look just on a single 8bpp layer in standard Mode 3, before doing any of the stuff I just mentioned or using colour math and the like:

 

 

There's just so much untapped potential there.

Edited January 4, 2023 by Kirk_Johnston

[jeffythedragonslayer]

Yeah that World of Illusion mp4 looks like what I'm talking about.  I just wanted to make sure I de-magic'd my explanation to make sure we're on the same page because it was hard for me to tell how the SNES PPU works at first - it's hard to follow these technical conversations (and especially fullsnes, the official docs, anomie/yoshi docs) without a lot of background knowledge.