It's also possible to use HDMA (automatic speed writes from a table, timed to happen during HBlank) to change colours between scanlines. In fact, HDMA can write to anything on the B bus, but writing to the VRAM port does nothing (unless the screen is blanked) and writing to object attribute memory just overwrites the size and high X bit of a set of four sprites that includes the last one accessed by the PPU (yes, there was actually a game that did this).Bitbeam wrote:Number of color indexes available: 256, but many more on-screen colors were possible via color arithmetic for transparency effects.
Technically there are 257 colour values stored by the PPU - the 256 colours in CGRAM, of which colour #0 is used for the main screen backdrop, plus the subscreen backdrop colour which is stored separately and normally only used for colour math (the whole idea of the subscreen is that it gets blended with the main screen with colour math). HDMA was often used to change one or the other of the backdrop colours for sky gradients and such, but you can write to any entry in CGRAM by using an HDMA channel in Mode 3 or 7 (no relation*) to write the desired index to CGADD (twice, because there are no 3-byte DMA patterns) followed by the actual colour word to CGDATA. There are 8 DMA channels, so you can change up to 8 colours per scanline as long as you have nothing else you want to do with HDMA.
The subscreen backdrop colour is a funny one. You don't write the whole x1B5G5R5 value to it at once. You write an RGB channel value, packed together with three bits that indicate which colour channels it applies to. So you can only change the entire colour in one shot if you want grayscale. And since there are no 4-byte DMA patterns that just target one address, you need a minimum of two HDMA channels to write an arbitrary colour to COLDATA.
So... if you see an artist trying to jam a sky gradient plus clouds and stuff into a 15-colour palette, tell him about HDMA.
Oh, and I should mention: You can't use colour averaging with backdrop colours. It will do additive transparency for those parts of the screen.
Also, sprites cannot be mathed with other sprites. They get rendered into a single layer before being sent to the colour math circuitry.
In fact, just read this: https://wiki.superfamicom.org/snes/show/Transparency
* The usual "Mode 7" etc. is the background rendering mode, specified in BGMODE. Here I'm talking about the DMA write pattern mode specified in DMAPx, which is totally unrelated.
That's a weird hybrid of the SNES and the Neo Geo you've got there. (Funny story: the Neo Geo didn't have scrollable backgrounds at all. There was the fix layer, used for the HUD, and there were sprites. Which could be shrunk, but not zoomed. It just had a ridiculous amount of sprite overdraw, so you could fake multiple scrolling backgrounds with sprites without getting dropout.)The SNES allows for 2 scrolling layers, 1 sprite layer, and one non scrolling “window” layer typically used for the games HUD (life bars, score etc.).
The thing called "windowing" on the SNES is unrelated to the background functionality. It allows you to specify the left and right edges of a pair of clip windows that can be used to mask off any set of background layers, and/or the sprite layer, and/or colour math, either inside or outside the windowed region. Window combination logic can be OR, AND, XOR, or XNOR. If you want more than a vertical line, HDMA is crucial (you could use an IRQ instead, but there's not much point because not only is it less efficient, but if you're using all 8 HDMA channels the CPU has a lot less time left in HBlank than it otherwise would, so it could be hard or impossible to reliably fit anything else in). Super Mario World uses windowing plus HDMA to draw the keyholes. Star Fox uses windowing plus HDMA to draw the big round glowy explosions.
Actually, you can optionally use 16x16 tiles. This gives you bigger maps, but results in coarser palette mapping.Each scrolling layer is made of 8x8 pixel tiles.
There are 8 available 15-colour palettes (not counting the zero colours, which don't get used). Each 4bpp tile can use any one of them.Each tile can be 16 colors, using one of any of the 4 available 16 color palettes.
Okay, background rendering modes, with description (yeah, I got kinda ninja'd, but whatever):
Mode 0: four 2bpp layers. Each tile can use one of 8 2bpp palettes, which are apparently unique to each layer (ie: each layer has an entirely separate set of 8 3-colour palettes that each tile can pick from). Nobody used this.
Mode 1: two 4bpp layers and one 2bpp layer. Each 4bpp tile can use any of the 8 4bpp palettes, which occupy the bottom half of CGRAM (the top half is for the 8 sprite palettes, and for 8bpp layers). The 2bpp layer uses colours from the bottom two 15-colour palettes. This is the most popular mode.
Mode 2: two 4bpp layers, with offset-per-tile - essentially column scrolling, whereby columns of tiles can be vertically scrolled independently. You can also relocate tiles between columns, but why would you do that? Yoshi's Island uses column scroll for lava and for when you touch Fuzzy. You can combine this with horizontal scroll changes via HDMA to produce the illusion of rotation, though the illusion will break down if you try to go too far. Star Fox uses this for its backdrop (but not for the actual polygonal layer, which was rendered with the appropriate rotation angle in software).
Mode 3: one 8bpp layer and one 4bpp layer. The 8bpp layer can access all of CGRAM - except for colour #0, but since in this case colour #0 is the actual bottom of CGRAM it gets used for the main screen backdrop, which is displayed when all the layers on the main screen are transparent, so the upshot is that you can use all 256 colours. Often used for title screens.
Mode 4: one 8bpp layer and one 2bpp layer, with offset-per-tile like in Mode 2.
Mode 5: one 4bpp layer and one 2bpp layer, in high resolution (512x224 progressive or 512x448 interlaced).
Mode 6: one 4bpp layer, in high resolution, with offset-per-tile like in Modes 2 and 4.
Mode 7: one 8bpp layer, with a fixed-location 128x128-tile map and 256 tiles maximum, no flipping. This layer is subject to an affine transform as specified by the Mode 7 transform matrix and origin coordinates. By changing the transform parameters every scanline with HDMA (two channels to fully rewrite the matrix, one more if you want to change the origin), it is possible to do fancy effects such as perspective, as seen in F-Zero et al..
All 8bpp layers can be set to direct colour, wherein the 8-bit CGRAM index is instead interpreted as a B2G3R3 value, with the three palette selector bits (which are otherwise nonfunctional on 8bpp layers for obvious reasons) used as one extra bit each for R, G, and B (resulting in B3G4R4, kinda - the extra bits are from the tilemap and are thus at tile granularity rather than pixel). Except that since the tilemap in Mode 7 is 8-bit with no palette selection (or priority, or flipping), those extra bits are only available in Modes 3 and 4.
Also, Mode 7 can be set to use two layers instead of one, but the pixel fetch is the same (so you can't do parallax or anything like that) and the only difference is that the top bit in the second layer is used as a priority bit instead of part of the colour index. This gives you pixel-perfect (well, texel-perfect) control of BG/sprite overlap. Oh, and mosaic works differently on the second layer...
Also, Mode 7 is the only hardware scaling/rotation effect available, unless you count offset-per-tile plus HDMA line scroll as rotation. You can only scale and rotate sprites in software, which is hard to do fast enough for action games (ask tepples and psycopathicteen for tips on fast sprite scaling and rotation respectively). Scaled sprites on SNES were typically just stored in ROM at multiple sizes and made to change size using ordinary sprite animation techniques.
1024 for each background in Modes 0-6. Tile pools for the different layers can be separate, overlapping, or identical, since they can be independently positioned in VRAM with 8 KB granularity.HOW MANY TILES CAN BE USED FOR THE BACKGROUNDS?
Mode 7 can only use 256 tiles, since the tilemap is 8-bit in order to allow a very large (1024x1024 texels) map without using an inordinate amount of VRAM.
[Digression: Super Mario Kart never updates the Mode 7 tilemap during a race; this was the best way to do a 2-player mode, since the Mode 7 map is locked to a single position in VRAM and is way too big to rewrite mid-frame even with quite a large black bar across the middle (Super Mario Kart uses that black bar to update OAM so that sprites don't cross over between the Player 1 and Player 2 screens). So they simply jammed each race course into one map and set it to repeat tile #0 outside that area (your options in Mode 7 are: transparent outside the map, tile #0 outside the map, or repeat/loop the whole map. In Modes 0-6, the map just loops). Originally it was going to be a 2-player F-Zero game, but they couldn't get much of a sense of speed going in such a small area, so they made it a go-kart game, but then they decided that their go-kart racers were too samey and needed to be recognizable mascots, and the rest is history...]
Furthermore, Mode 7 uses a different tile format than the rest of the Modes, so you can't reuse tiles from Mode 7 in a different Mode in the same frame, even if there's an 8bpp layer in that Mode. You need a separate copy of the tile in the appropriate format if you want to do that. You can reuse sprite tiles as 4bpp background tiles, though, if the tile pool for the background in question overlaps one or both of the OBJ tables.
Good reference here: https://wiki.superfamicom.org/snes/show/Backgrounds
As said, you can indeed change BG modes between scanlines with HDMA or an IRQ. You can also (I'm pretty certain) change where in VRAM a background layer looks for its map and tile data - except for Mode 7, since both the map and the tile pool are fixed-position.
In canonical SNES graphics, each scanline is drawn in only one background rendering mode. Technically you can change the BG mode mid-scanline, but this results in visual glitching and is poorly understood, on top of being very CPU intensive; if you're an artist you have no business doing this. In other words, no fancy Mode 1 colour math right next to a rotating Mode 7 scene. I did this, but it ate half my CPU time and I had to fake some of the colour math with HDMA and eye strain because I needed to cover the glitching with sprites, and I'm still not sure I won't get visible dancing specks on the sprite layer once I start doing colour math in the Mode 7 area... my excuse is that I'm porting a game from a way more powerful platform and want it to look as accurate as possible, and the CPU time loss isn't as big a deal as it could be because I'm using a Super FX chip... note also that this stunt has not been tested on a 1CHIP or SNES Jr. and may very well fail...
This is a good use for HDMA. You can change horizontal scroll quite easily with one HDMA channel per layer. In fact, you can change horizontal and vertical scroll (see Axelay) with one HDMA channel per layer.On top of the 2 separate background layers, either of them can be individually sliced horizontally in order to add even more parts of the background scrolling at separate speeds to create the illusion or dept in scrolling games.
The Mega Drive/Genesis has special features called "line scroll" and "row scroll" to help with this. The SNES doesn't need them because HDMA can do the same thing and more besides.
8x8 and 16x16The SNES can have two sizes of sprites on the screen at once. WHAT SIZES ARE POSSIBLE OPTIONS?
8x8 and 32x32
8x8 and 64x64
16x16 and 32x32
16x16 and 64x64
32x32 and 64x64
16x32 and 32x64 (vertical flipping flips each half separately)
16x32 and 32x32 (vertical flipping flips each half separately)
Those last two were not documented by Nintendo and were probably either an unfinished feature or a side effect, like the "illegal opcodes" on the 6502.
You can designate two 8 KB areas of VRAM for sprites. That's 256 tiles per OBJ table, for 512 total. The primary table is positioned with 16 KB granularity, and the secondary table is offset from it with 8 KB granularity. I believe the locations do wrap in VRAM, so you can put table 0 at the top of VRAM and table 1 at the bottom.Up to HOW MANY? tiles can be dedicated to sprites?
You can actually change the location of the sprite tile tables mid-screen with a write to OBSEL timed to happen in the middle of a scanline; the next line will use the new data locations (allowing you to access more than 16 KB of sprite data per frame, but not per scanline). The ideal use case here is a fixed layer of sprites that never move, as might be necessary if you wished to plaster a Super FX rendered layer over a Mode 7 backdrop, just to pick an example at random [*cough*]...
Note that mosaic (that blocky fade-out effect from Super Mario World) does not work on sprites.
...yeah, all of those are wrong. But that should be evident by now.Bitbeam wrote:1) All tiles for any given 4bpp layer WILL be displayed with the same single 16 color palette?
2) The 4 color (three plus transparent) layer will use only those three colors to draw all tiles?
3) All three layers would be made from tiles in the same tile-set image of up to 1,024 tiles images?
4) By changing a setting to 0, 1,2 etc, that's how you set which palette (color index range) each entire layer is using to draw it's tiles?
The closest you got was in (4), but the "setting" in question is a three-bit value in the upper byte of every entry in the tilemap.
It was the basis for this, I believe: https://wiki.superfamicom.org/snes/show/Registerscreaothceann wrote:Anomie's register document is a relatively accurate and easy-to-read resource.
I find it a massively useful resource; it has information that even the pages dedicated to a particular feature leave out.