Offset-per-tile: Difference between revisions
Rainwarrior (talk | contribs) (link to more examples) |
Rainwarrior (talk | contribs) (→Details on how the feature works: explain what the tilemap data looks like and how it applies) |
||
| Line 9: | Line 9: | ||
== Details on how the feature works == | == Details on how the feature works == | ||
In offset-per-tile | In offset-per-tile modes, BG3's tilemap data is used instead as an offset map. | ||
This contains 2 rows of 32 entries (128 bytes total), the first for horizontal offset, and the second for vertical. Mode 4 only contains 1 row of 32 entries which instead choose either only horizontal or vertical per-entry. | |||
Each entry is a 16-bit value: | |||
<pre> | <pre> | ||
15 bit 8 7 bit 0 | 15 bit 8 7 bit 0 | ||
| Line 23: | Line 25: | ||
</pre> | </pre> | ||
The leftmost column of tiles is not affected by the offsets. The 0th entry for the offset map applies instead to the second visible column. This allows the first column's offset to be controlled by that layer's normal HOFS/VOFS setting, and the 32 entries affect the remaining 32 tiles that may be visible on that scanline. (Because the left column may be partially scrolled offscreen, up to 33 tiles can be at least partly seen on a scanline.) | |||
Each entry affects an entire column of the image, but [[HDMA]] or other timing techniques may be used to switch to multiple "sets" of scroll overrides in different parts of the screen. | |||
The low 3 bits of HOFS are ignored for BG3's offset map, so it can be scrolled to match the other layers it applies to. VOFS is ignored. | |||
Revision as of 01:37, 31 August 2022
Offset-per-tile is a feature of background modes 2, 4, and 6. It allows overriding a layer's horizontal and vertical scroll position on a tile-by-tile basis. This is used by Yoshi's Island for the dizzy effect and Tetris Attack to have two different playfields with different vertical positions.
This feature can be used to simulate a rotating background for small rotation angles, as seen in Star Fox.
See:
Details on how the feature works
In offset-per-tile modes, BG3's tilemap data is used instead as an offset map.
This contains 2 rows of 32 entries (128 bytes total), the first for horizontal offset, and the second for vertical. Mode 4 only contains 1 row of 32 entries which instead choose either only horizontal or vertical per-entry.
Each entry is a 16-bit value:
15 bit 8 7 bit 0 ---- ---- ---- ---- V21. ..SS SSSS Ssss ||| || |||| |||| ||| ++---++++-++++- New scroll value for this tile. For horizontal values, the bottom three bits are ignored ||+------------------- Override scroll value for layer 1 |+-------------------- Override scroll value for layer 2 +--------------------- Mode 4 only: Scroll direction (0 = horizontal, 1 = vertical)
The leftmost column of tiles is not affected by the offsets. The 0th entry for the offset map applies instead to the second visible column. This allows the first column's offset to be controlled by that layer's normal HOFS/VOFS setting, and the 32 entries affect the remaining 32 tiles that may be visible on that scanline. (Because the left column may be partially scrolled offscreen, up to 33 tiles can be at least partly seen on a scanline.)
Each entry affects an entire column of the image, but HDMA or other timing techniques may be used to switch to multiple "sets" of scroll overrides in different parts of the screen.
The low 3 bits of HOFS are ignored for BG3's offset map, so it can be scrolled to match the other layers it applies to. VOFS is ignored.
