I'm trying to figure out how I can make different rows of tiles on the screen not only scroll at different rates but also efficiently update the tilemap at the particular seam corresponding to each row.
Currently I'm storing the background map in each level as 64x64-pixel metatiles, which are made of 32x32-pixel metatiles, which are made of 16x16-pixel metatiles, which are made of 8x8-pixel tiles. Each of the four layers of metatile storage can have no more than 256 unique tiles in one map.
Any row that does not scroll at the same rate as the playfield is a "background loop" row, which does not get updated in the tilemap during the scrolling process. Thus the map of a background loop is currently limited to 512x240 pixels, the size of the tilemap in vertical mirroring mode. The background loop gets its own set of 256 tiles in CHR RAM. But in order to make an NES game's graphical style competitive with that of PC-native pixel art games such as Shovel Knight, someone may want to change this to make the map used by some rows wider than 512 pixels, especially rows in the "foreground" that scroll twice as fast as the camera moves. I've attached a video of what the scrolling seam for such updates might look like, along with the Python program that generated the video.
Is there an efficient way to store the map that allows for efficient reading of a decently compressed map from ROM to produce a horizontally staggered nametable update? What other NES games use a staggered update seam in this fashion? Or is this uncharted territory, as if I were trying to demake Virtual Boy Wario Land on the NES?
Bonus question: If the terrain occasionally has to protrude above the vertical position of the split, such as making the ladder in the middle of this map taller, what's the best way to draw it? Should the scroll rate of the tile rows containing this bit of terrain temporarily change to the same scroll speed as the playfield while the bit of terrain is temporarily on screen?
Currently I'm storing the background map in each level as 64x64-pixel metatiles, which are made of 32x32-pixel metatiles, which are made of 16x16-pixel metatiles, which are made of 8x8-pixel tiles. Each of the four layers of metatile storage can have no more than 256 unique tiles in one map.
Any row that does not scroll at the same rate as the playfield is a "background loop" row, which does not get updated in the tilemap during the scrolling process. Thus the map of a background loop is currently limited to 512x240 pixels, the size of the tilemap in vertical mirroring mode. The background loop gets its own set of 256 tiles in CHR RAM. But in order to make an NES game's graphical style competitive with that of PC-native pixel art games such as Shovel Knight, someone may want to change this to make the map used by some rows wider than 512 pixels, especially rows in the "foreground" that scroll twice as fast as the camera moves. I've attached a video of what the scrolling seam for such updates might look like, along with the Python program that generated the video.
Attachment:
Is there an efficient way to store the map that allows for efficient reading of a decently compressed map from ROM to produce a horizontally staggered nametable update? What other NES games use a staggered update seam in this fashion? Or is this uncharted territory, as if I were trying to demake Virtual Boy Wario Land on the NES?
Bonus question: If the terrain occasionally has to protrude above the vertical position of the split, such as making the ladder in the middle of this map taller, what's the best way to draw it? Should the scroll rate of the tile rows containing this bit of terrain temporarily change to the same scroll speed as the playfield while the bit of terrain is temporarily on screen?