- See below for how Offset-Per-Tile modes work
Most SNES games use Mode 1 most of the time. It gives you 2 layers of 16 color per tile, and 1 layer of 4 color per tile. All the other blog pages cover Mode 1, and I think we’ve talked enough about that. Let’s take a look at examples of games using the other modes.
(4 layers of 4 colors per tile)
The only advantage is the extra layer. (Well, also the graphics are half the size in this mode.) Very few games use this except for screens of text. (Final Fantasy 2, US)
This is similar to Mode 1, but with only 2 layers of 16 color per tile. This is an Offset-Per-Tile layer, meaning that the screen can ignore the scroll value and instead have a unique scroll value per column (it should really be called offset-per-column). I will talk about it a little more below.
Yoshi’s Island really makes good use of this mode in the “Touch Fuzzy Get Dizzy” level.
Tetris Attack uses Mode 2 to raise the game board as you play.
Another Mode 2 example is Shin Nekketsu Kouha – Kunio-tachi no Banka. The bridge moves in waves.
Mode 3 has 1 layer 256 color and 1 layer 16 color per tile. You see it a lot in title screens and cut scenes. Personally, I think this has the highest quality images. The graphic files are 2x as big (8 bits per pixel instead of 4 bpp). One advantage of this mode, you don’t need to align graphics to a grid. All tiles have use of all colors in the palette.
Though, you almost never see games use Mode 3 for actual gameplay. I found only 1 game that does: NBA All-Star Challenge.
If you are going to use mode 3 with sprites, you need to reserve some colors for the sprites… so technically the BG graphics should use maybe 128 colors, because sprites need to use the 2nd half of the CGRAM.
Another Offset-Per-Tile mode. You get 1 layer of 256 color and 1 layer with 4 color per tile. This is rarely seen, and only one game I know uses the offset OPT system. Bust-A-Move uses it for regular gameplay, and only to slightly jiggle the pieces once in a while. But any other time the pieces move (like when they fall), they are sprites.
A few other games use Mode 4 without using the Offset-Per-Tile. I guess they wanted the second layer to use 4 color graphics instead of 16 colors (like Mode 3).
Direct Color Mode
This mode is an option for any 256 color layer (such as Mode 3, 4, or 7), to ignore the palette and use the graphic data as an RGB value itself (R3,G3,B2 plus each tile can add another R1,G1,B1). It’s actually lower quality than standard 256 colors, so it was almost never used, except for this map in ActRaiser 2.
This is the High Resolution Mode. 1 layer of 16 color per tile, 1 layer of 4 color per tile. It has these weird 16×8 tiles which squish down into 8×8 on screen giving a sharper image (double the horizontal resolution). The graphics would have to be twice as big (takes up 2x as much VRAM). This mode was rarely used, and typically only for the text of some Japanese only games. Romancing Sa-Ga 3.
You might notice that the upper right 3 boxes aren’t quite as sharp as the rest of the screen (like the guy with headphones on). Those are sprite graphics. High Resolution only affects backgrounds.
I haven’t found an example of this. It is a HiRes mode with 1 layer of 16 colors per tile. It also has Offset-Per-Tile mode, like mode 2. No game uses this mode.
I just want to point out that I did some testing, and old CRT TVs tended to blur a bit, and didn’t really have the ability to generate 512 pixels wide, so the final result was not nearly as good as I was expecting. That would explain why so few game developers used the High Resolution modes.
However, emulators do a much better job, so maybe these modes could work for future homebrew development. One option, to get around running out of VRAM space, would be to split the screen, and use Mode 0 for the top (HUD) and then Mode 5 for just part of the screen.
Unfortunately, there are no good tools for creating Mode 5/6 game levels. I had to manually type the map data in a hex editor when I was testing these modes.
Pseudo HiRes Mode
For Modes 0-4, you can kind of fake High Resolution, by turning on the Pseudo HiRes. Unlike the Mode 5 (which uses 16×8 tiles)… Pseudo HiRes uses the standard 8×8 tiles, but it draws the pixels half wide and alternates between the Main Screen pixel and the Sub Screen pixel… so it squeezes 2 different pixels into the normal 1 pixel size, doubling the horizontal resolution. It goes without saying that this would be complicated to set up since the graphics would have to be split pixel by pixel into 2 different CHR files, and “why wouldn’t you just use HiRes Modes 5/6?”
Well, the way games actually used it was for a 50% transparency effect, because if you put different layers on Main Screen than on the Sub Screen, they blended together. Old TVs tended to blur this, and it would look like this (Jurassic Park, look at the yellow things at the bottom).
Another game that does this is Kirby’s Dreamland 3. There is an area with trees that uses Pseudo HiRes to make a transparency effect.
This mode really deserves its own page, there is just so much to talk about. You get one layer with 256 colors that can be stretched, skewed, and rotated. Any time you see something zoom in or out, that’s mode 7. One limitation, you get only 256 tiles max, and those individual tiles can’t be flipped. All layering effects have to be done with sprites. F-Zero has a perspective effect by zooming in as the screen gets closer to the bottom.
Final Fantasy 6
Super Castlevania 4
Super Mario Kart
How Offset-Per-Tile Modes Work
Modes 2, 4, and 6 have the option to use Offset per Tile Mode (also called Offset Change Mode).
Mode 2 and 6 works like this. You put the table of offsets where layer 3 map should be (neither of these modes has a layer 3). The first part of the table affects horizontal shifting (course shifting only) and the second part of the table affects vertical shifting (fine 1 pixel shifts). You don’t have to enable layer 3 on the main screen, just layer 1 (and/or layer 2).
It should really be called Offset-Per-Column, since each value affects an entire column of the screen. There are 32 columns times 2 bytes per column is 64 bytes for horizontal offset followed by 64 bytes for vertical offset. The left most column of the screen is unaffected by offset-per-tile… it will use that layer’s usual scrolling values. So, the first entry in the OPT table affects the 2nd column, and so forth. And, the right most OPT value is for when the screen isn’t exactly aligned to a tile (horizontal scroll & 0x07 != zero) , so you can see a portion of a 33rd column on the far right. Some games use a window to hide the left most 8 pixels of the screen so it doesn’t have to manage that part, which isn’t affected by OPT.
When I first tested this mode, I thought that the OPT values in layer 3’s map correspond to layer 1’s map. But that was wrong. They correspond to the screen itself. Like, if you divide the visual picture into 32 columns. As the layer scrolls horizontally, the offset will apply to a different tile column. It is a particular column on screen that is affected, not a particular column in the map.
Just to keep things simple, we will put our offsets at the start of layer 3’s map. You probably don’t want to use horizontal offset (using map addresses 0-0x1f), so add 0x20 to the start of the layer 3 map to place your vertical offset values. The bit order works like this…
bit 15 = 0 H, 1 V (for mode 4 only)
bit 14 = BG2 affected
bit 13 = BG1 affected
10-12 = unused
0-9 = scroll offset
(lower 3 bits of horizontal offset are ignored)
So, if you wanted a vertical offset, affecting BG1+2, with an offset of 3…
111xxx00 00000011 = $e003
Really, in mode 2 or 6 you don’t really need that upper bit, so $6003
And that offset value completely overrides the vertical scroll for that column. It’s not added to the vertical scroll, but it replaces it entirely.
For Mode 4, you can’t do both horizontal and vertical OPT, you have to choose (per column) which one you want. The data will start at the beginning of layer 3’s map, just 1 set of values, and bit 15 of each value will determine if that column will offset horizontally or vertically.
You might ask yourself, will I still be able to scroll the level? Yes. Horizontally. We just need to make sure that the first 32 values in map 3 are zero, so that the “affect layer 1” and “affect layer 2” bits are off. Thus, horizontal scrolling will function as normal. (except for Mode 4, in which the first 32 values are the only values, in which case you make sure that the upper bit “H or V” is set, then OPT will only affect V, and horizontal scrolling will work as normal).
One more detail. They made it so you can have multiple OPT tables stored in the map 3 (in VRAM). Registers $2111 (BG3HOFS) and $2112 (BG3VOFS) are used to switch between the different tables. If you are doing what I said above, where the OPT values are at the start of map 3, you need $2111 and $2112 to be zero. If they are not zero, then d3-d7 of these registers will change the start location of the OPT table. These bits are the ones I mean.
and the calculation is like this. (where register $2109 defines the start of map 3)
OPT table = map 3 base address + ($2112.d3-7 * 32) + ($2111.d3-7).
Personally, I would just keep $2111 and $2112 as zero and just update the table every frame. It’s no big deal to do 32 writes per frame. You will probably want a local copy of the values anyway… so that you have something to check for collisions with objects.
I made some example code for Mode 2.
Here’s a nice video covering all the modes, 0-6.