Looping backgrounds vs longer level maps. . . .
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Looping backgrounds vs longer level maps. . . .
If I have a background that technically fits into one 256x224 screen but want to have it so it's not just a single looping image but instead changes some elements of that background each time it loops for a bit of variety, still using the elements that already exist in the background tileset but switching positions and having some show up one pass but not the other, etc, is that just a matter of drawing a longer background using the available set of tiles and giving that longer image to the artist as a tilemap, and how does that compare in terms of how much VRAM/other resources/processing it takes to do that vs just looping the single 256x224 background image endlessly? I mean, if I already have all the tiles loaded for the background that I'm going to use anyway but I just want to vary their positions a little each time they scroll past the screen in principle, what's the "cost" of that (in layman's terms)?
If you don't get what I mean then look at my ice level, which currently just loops a 256x224 image for every background layer, but at times I'd like to vary when/where some of the elements appear as it goes through the level just for a bit of visual variety, say the white icebergs (without loading in any new tiles): https://youtu.be/ytNUcBYcEuI
Also, side question: If I want to animate some of the background tiles, do I just included the extra tile frames in the tileset and the programmer somehow tells the game to switch some of the tiles to other ones in the tileset per frame (or every few frames or so)? Is that basically all I have to do for this on my part (as the designer and artist)?
If you don't get what I mean then look at my ice level, which currently just loops a 256x224 image for every background layer, but at times I'd like to vary when/where some of the elements appear as it goes through the level just for a bit of visual variety, say the white icebergs (without loading in any new tiles): https://youtu.be/ytNUcBYcEuI
Also, side question: If I want to animate some of the background tiles, do I just included the extra tile frames in the tileset and the programmer somehow tells the game to switch some of the tiles to other ones in the tileset per frame (or every few frames or so)? Is that basically all I have to do for this on my part (as the designer and artist)?
Last edited by iNCEPTIONAL on Tue Jun 28, 2022 2:09 am, edited 3 times in total.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Looping backgrounds vs longer level maps. . . .
you would need to make a full map, or if you have a simple way to modify if it, ie repeat this column N times, then this part of the screen, then these blocks again type deal, greatly changes how much the map or system would cost. It comes down to the exact specifics of the map and how it can be built. You can use a window to remove 8 pixels of the side to hide the new row coming in so you can keep it in 1 screens worth in VRAM. Or just assume that a screen can't see it way as SMB3 did. But emulators will show you all of it.
if you just update the tile data to animate it, doing that is relatively cheap, its part of your VRAM DAM budget, but if the tile map has to change to accommodate the new layout and that has to be in frame that gets rather expensive and you might as well just do a whole screen DMA.
if you just update the tile data to animate it, doing that is relatively cheap, its part of your VRAM DAM budget, but if the tile map has to change to accommodate the new layout and that has to be in frame that gets rather expensive and you might as well just do a whole screen DMA.
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Looping backgrounds vs longer level maps. . . .
Which tiles are animated and with which other frames, and how fast I think are level design tasks. I don't think as many level editors support animated tiles as static ones, so I'd try to deliver some other "animation" map the same dimensions as the static map, which clearly marks which tiles are animated (you could visualize this as a stack of tile frames jettin out into the 3rd dimension) in a format easily digestable by software. That way the programmer doesn't have to guess, or worse, simply doesn't realize a map is supposed to be animated. Usually only a few tiles are animated, so if you leave gaps in the static map where those animated tiles are and set them to some obnoxious color, the lack of animation code before it is implemented will be obvious.iNCEPTIONAL wrote: ↑Tue Jun 14, 2022 4:12 pm Also, side question: If I want to animate some of the background tiles, do I just included the extra tile frames in the tileset and the programmer somehow tells the game to switch some of the tiles to other ones in the tileset per frame (or every few frames or so)? Is that basically all I have to do for this on my part (as the designer and artist)?
Re: Looping backgrounds vs longer level maps. . . .
I probably confused you there because obviously I don't want to be doing any updating visually to the background within the screen view, even if I could hide it with a strip or whatever. I definitely don't want that kind of thing.Oziphantom wrote: ↑Wed Jun 15, 2022 12:16 am you would need to make a full map, or if you have a simple way to modify if it, ie repeat this column N times, then this part of the screen, then these blocks again type deal, greatly changes how much the map or system would cost. It comes down to the exact specifics of the map and how it can be built. You can use a window to remove 8 pixels of the side to hide the new row coming in so you can keep it in 1 screens worth in VRAM. Or just assume that a screen can't see it way as SMB3 did. But emulators will show you all of it.
if you just update the tile data to animate it, doing that is relatively cheap, its part of your VRAM DAM budget, but if the tile map has to change to accommodate the new layout and that has to be in frame that gets rather expensive and you might as well just do a whole screen DMA.
So, if I make the background two screens wide rather than one, can I then have the programmer regularly update the part of the background that's outside the camera more easily so the layout varies a bit each time it scrolls into view and with every loop? Is that more efficient than just drawing a long background say ten screens wide (or whatever) with some variations pre-set throughout it (basically a smaller but regularly changing [layout] and looping background vs a longer full level map that's all pre-set)?
Last edited by iNCEPTIONAL on Wed Jun 15, 2022 8:34 am, edited 3 times in total.
Re: Looping backgrounds vs longer level maps. . . .
OK, so I guess I could just give the programmer a version of the map with the parts for animated tiles in a say green 8x8 blocks vs the normal pink/purple I use for the transparent colour. And would I include the tile animation frames still in the same tilemap though, just in part of the background off screen or something? Or do I give them to him separately, and how does that work in terms of managing max unique tiles and the like, which I would have thought you'd have to have all the tiles you want to have in the level already in the background or tilemap (unless you specifically plan on streaming in all new tiles)?jeffythedragonslayer wrote: ↑Wed Jun 15, 2022 3:30 amWhich tiles are animated and with which other frames, and how fast I think are level design tasks. I don't think as many level editors support animated tiles as static ones, so I'd try to deliver some other "animation" map the same dimensions as the static map, which clearly marks which tiles are animated (you could visualize this as a stack of tile frames jettin out into the 3rd dimension) in a format easily digestable by software. That way the programmer doesn't have to guess, or worse, simply doesn't realize a map is supposed to be animated. Usually only a few tiles are animated, so if you leave gaps in the static map where those animated tiles are and set them to some obnoxious color, the lack of animation code before it is implemented will be obvious.iNCEPTIONAL wrote: ↑Tue Jun 14, 2022 4:12 pm Also, side question: If I want to animate some of the background tiles, do I just included the extra tile frames in the tileset and the programmer somehow tells the game to switch some of the tiles to other ones in the tileset per frame (or every few frames or so)? Is that basically all I have to do for this on my part (as the designer and artist)?
- jeffythedragonslayer
- Posts: 344
- Joined: Thu Dec 09, 2021 12:29 pm
Re: Looping backgrounds vs longer level maps. . . .
Let me clarify some terminology because nasty bugs can happen if you get them confused like I did recently. This can happen because both tilesets and tilemaps live in VRAM. (It is harder to get things confused with palettes, because CGRAM is a separate area of memory.)iNCEPTIONAL wrote: ↑Tue Jun 14, 2022 4:12 pmAnd would I include the tile animation frames still in the same tilemap though, just in part of the background off screen or something? Or do I give them to him separately, and how does that work in terms of managing max unique tiles and the like, which I would have thought you'd have to have all the tiles you want to have in the level already in the background or tilemap (unless you specifically plan on streaming in all new tiles)?
There is the tileset, which should contain one and only one version of each tile, including one of all of its various incarnations as animation frames, if has any. (A set in mathematics either contains an element, or it doesn't, if you want to talk about the same element being in a set multiple times you should use the word multiset instead.) In other engines I have written, a tileset is a PNG file where similar looking tiles are adjacent, but it doesn't matter too much where in a tileset a tile appears. (In fact, in mathematics you can move elements in a set around and it is still considered "the same" set.) A game level will still look the same even if you swap two tiles in the tileset, so long as you swap their references in the tilemap. The artist makes the tileset.
Then there is the tilemap. The tilemap is the size of the game level or game map. Each entry in the tilemap "points to" or references a tile in the tileset. The same tile can, and usually is, be pointed to by the tileset many times, but it is also okay for a tile in the tileset to not be pointed to at all by any tilemap entries. For animation, the target tile of this "pointing" is changing with time. The level designer makes the tilemap. Tilemaps are also called nametables.
Re: Looping backgrounds vs longer level maps. . . .
OK.jeffythedragonslayer wrote: ↑Wed Jun 15, 2022 8:59 amLet me clarify some terminology because nasty bugs can happen if you get them confused like I did recently. This can happen because both tilesets and tilemaps live in VRAM. (It is harder to get things confused with palettes, because CGRAM is a separate area of memory.)iNCEPTIONAL wrote: ↑Tue Jun 14, 2022 4:12 pmAnd would I include the tile animation frames still in the same tilemap though, just in part of the background off screen or something? Or do I give them to him separately, and how does that work in terms of managing max unique tiles and the like, which I would have thought you'd have to have all the tiles you want to have in the level already in the background or tilemap (unless you specifically plan on streaming in all new tiles)?
There is the tileset, which should contain one and only one version of each tile, including one of all of its various incarnations as animation frames, if has any. (A set in mathematics either contains an element, or it doesn't, if you want to talk about the same element being in a set multiple times you should use the word multiset instead.) In other engines I have written, a tileset is a PNG file where similar looking tiles are adjacent, but it doesn't matter too much where in a tileset a tile appears. (In fact, in mathematics you can move elements in a set around and it is still considered "the same" set.) A game level will still look the same even if you swap two tiles in the tileset, so long as you swap their references in the tilemap. The artist makes the tileset.
Then there is the tilemap. The tilemap is the size of the game level or game map. Each entry in the tilemap "points to" or references a tile in the tileset. The same tile can, and usually is, be pointed to by the tileset many times, but it is also okay for a tile in the tileset to not be pointed to at all by any tilemap entries. For animation, the target tile of this "pointing" is changing with time. The level designer makes the tilemap. Tilemaps are also called nametables.
So, if I want to loop a single 256x224 background image then it's the tileset with all the unique tiles in the image plus a tilemap that's 256x224 that I give the programmer.
If I want to have a larger graphic that loops [repeats] a bit less often, say every two screens, it would be the same tileset plus a tilemap that's 512x224.
If I want a background that basically doesn't loop but goes on for the whole level and mixes and matches background elements from the tileset for a bit of variety, I give the programmer the same tileset and a tilemap that could be say ten screens long. And that's basically the only way to that variation in the background layer layout as the level scrolls by [while using only the tiles in the current tileset].
And I give the programmer the tileset for each background layer [with any animated tiles in it] plus the tilemap for each background layer, along with some notes and indicators on what tiles are supposed to animate and what tiles from the corresponding tileset and timings to use for them.
Correct?
Re: Looping backgrounds vs longer level maps. . . .
Either give the images or tileset+tilemap+palettes.iNCEPTIONAL wrote: ↑Wed Jun 15, 2022 9:29 am So, if I want to loop a single 256x224 background image then it's the tileset with all the unique tiles in the image plus a tilemap that's 256x224 that I give the programmer.
Correct but I'm not sure what you mean by "same".iNCEPTIONAL wrote: ↑Wed Jun 15, 2022 9:29 am If I want to have a larger graphic that loops [repeats] a bit less often, say every two screens, it would be the same tileset plus a tilemap that's 512x224.
Correct but at this point, your image width can be a multiple of 8 instead of 256 at no extra performance cost.iNCEPTIONAL wrote: ↑Wed Jun 15, 2022 9:29 am If I want a background that basically doesn't loop but goes on for the whole level and mixes and matches background elements from the tileset for a bit of variety, I give the programmer the same tileset and a tilemap that could be say ten screens long. And that's basically the only way to that variation in the background layer layout as the level scrolls by [while using only the tiles in the current tileset].
If you can, group animated tiles together in the tileset. Segmented data transfer wastes time. If you have multiple timings on the same tileset, try to group tiles by timing.iNCEPTIONAL wrote: ↑Wed Jun 15, 2022 9:29 am And I give the programmer the tileset for each background layer [with any animated tiles in it] plus the tilemap for each background layer, along with some notes and indicators on what tiles are supposed to animate and what tiles from the corresponding tileset and timings to use for them.
Re: Looping backgrounds vs longer level maps. . . .
I just mean that giving the programmer the one tileset [per background] covers all the background examples above, be it a single looping 256x224 image or a longer tilemap up to the whole size of the level.Myself086 wrote: ↑Wed Jun 15, 2022 11:19 amCorrect but I'm not sure what you mean by "same".iNCEPTIONAL wrote: ↑Wed Jun 15, 2022 9:29 am If I want to have a larger graphic that loops [repeats] a bit less often, say every two screens, it would be the same tileset plus a tilemap that's 512x224.
Re: Looping backgrounds vs longer level maps. . . .
By the way, regarding tilemaps, the largest tilemap using 8x8 tiles is 512x512 pixels, correct? But if I want a larger level in any direction (still using the same tileset), which I presume is often the case in scrolling games like my shmup, are the extra sections of the level beyond that 512x512 max tilemap size just updated in real-time by the programmer's code as the screen scrolls to reflect my full level image? If so, is this just about the programmer basically rearranging the tilemap using the tiles in the current tileset as the screen scrolls, so nowhere near as costly as having to load in all new tiles or whatever?jeffythedragonslayer wrote: ↑Wed Jun 15, 2022 8:59 amLet me clarify some terminology because nasty bugs can happen if you get them confused like I did recently. This can happen because both tilesets and tilemaps live in VRAM. (It is harder to get things confused with palettes, because CGRAM is a separate area of memory.)iNCEPTIONAL wrote: ↑Tue Jun 14, 2022 4:12 pmAnd would I include the tile animation frames still in the same tilemap though, just in part of the background off screen or something? Or do I give them to him separately, and how does that work in terms of managing max unique tiles and the like, which I would have thought you'd have to have all the tiles you want to have in the level already in the background or tilemap (unless you specifically plan on streaming in all new tiles)?
There is the tileset, which should contain one and only one version of each tile, including one of all of its various incarnations as animation frames, if has any. (A set in mathematics either contains an element, or it doesn't, if you want to talk about the same element being in a set multiple times you should use the word multiset instead.) In other engines I have written, a tileset is a PNG file where similar looking tiles are adjacent, but it doesn't matter too much where in a tileset a tile appears. (In fact, in mathematics you can move elements in a set around and it is still considered "the same" set.) A game level will still look the same even if you swap two tiles in the tileset, so long as you swap their references in the tilemap. The artist makes the tileset.
Then there is the tilemap. The tilemap is the size of the game level or game map. Each entry in the tilemap "points to" or references a tile in the tileset. The same tile can, and usually is, be pointed to by the tileset many times, but it is also okay for a tile in the tileset to not be pointed to at all by any tilemap entries. For animation, the target tile of this "pointing" is changing with time. The level designer makes the tilemap. Tilemaps are also called nametables.
I'm still slightly confused about this whole tileset, tilemap, actual level stuff: I get that there is a tileset that contains all the unique tiles I will use in the background (one tileset for each background layer, which is presumably all pre-loaded normally. And for now let's say I'm going with the 8x8 tile size and sticking within the current tileset to create the whole level). I sort of get that the tilemap is those tiles laid out and repeated to create the max background tilemap that can be loaded into memory at once time (one tilemap for each layer), with the largest tilemap using 8x8 tiles being 512x512, I think. But I'm not sure exactly what happens when I want a level that's much larger than this, and how much "cost" there is having levels larger than the largest tilemap size.
Basically, I'm trying to figure out if I have to particularly worry about this "cost" when I have a Mode 0 level with four scrolling background layers where the level goes on for much longer/larger than two screens wide (the width of the largest tilemap using 8x8 tiles), with some of the backgrounds simply looping 256x224 images but others absolutely won't be, and I have some line scrolling in each layer, some tile animation, maybe some colour math, possibly some window/shape masking, on top of all the normal animation and code for the player and enemies and so on going on at the same time too.
I'm probably thinking about this all wrong and/or asking the wrong questions, but just trying to get my head around this.
Last edited by iNCEPTIONAL on Tue Jun 28, 2022 2:24 am, edited 1 time in total.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: Looping backgrounds vs longer level maps. . . .
There is no inherent limit on the size of a level; it just has to fit into the cartridge, and scrolling should not be faster than how fast the game can update rows and/or columns of the tilemap.
https://youtu.be/wfrNnwJrujw?t=50
https://youtu.be/uRjf8ZP6rs8?t=39
If all your tiles were already in VRAM and you were able to update the entire (visible part of the) tilemap every frame, there would be no limit on the scrolling speed or level size. IIRC that's what for example Uniracers is doing - it never loads new tiles and only updates the tilemap, thereby allowing for very fast scrolling speeds.
https://youtu.be/wfrNnwJrujw?t=50
https://youtu.be/uRjf8ZP6rs8?t=39
If all your tiles were already in VRAM and you were able to update the entire (visible part of the) tilemap every frame, there would be no limit on the scrolling speed or level size. IIRC that's what for example Uniracers is doing - it never loads new tiles and only updates the tilemap, thereby allowing for very fast scrolling speeds.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: Looping backgrounds vs longer level maps. . . .
Basically most games just switches out a tile column or row (or both in case of 8-way scrolling) on a part of the tilemap that is outside the visible part. This "scroll-seam" can be about anywhere on the second tilemap half, and updating this is quite trivial on the SNES for normal scrolling speeds.
Uniracer/Unirally has amazing speed, but it also uses very simplistic graphics which I guess is the drawback. The game was made by NOA as an attempt to counter Sega's aggressive commercials in USA where the SNES was portrayed as sluggish (which is partly true though).
If you need new unique tiles you can switch out those too as you scroll, but I don't know the bandwidth here. It is much slower than updating the tilemap since a single 8x8 tile pattern is 32 bytes for 4bpp tilemaps or 16 bytes if 2bpp. Compare that to a single tilemap "name" (tilemap entry) which is just 2 bytes, so it's easy to see why tilemaps are used in the first place instead of just using a pixel bitmap for the screen. It would use too much VRAM and be too slow to update for the action.
Uniracer/Unirally has amazing speed, but it also uses very simplistic graphics which I guess is the drawback. The game was made by NOA as an attempt to counter Sega's aggressive commercials in USA where the SNES was portrayed as sluggish (which is partly true though).
If you need new unique tiles you can switch out those too as you scroll, but I don't know the bandwidth here. It is much slower than updating the tilemap since a single 8x8 tile pattern is 32 bytes for 4bpp tilemaps or 16 bytes if 2bpp. Compare that to a single tilemap "name" (tilemap entry) which is just 2 bytes, so it's easy to see why tilemaps are used in the first place instead of just using a pixel bitmap for the screen. It would use too much VRAM and be too slow to update for the action.
Re: Looping backgrounds vs longer level maps. . . .
For anything that isn't 256x256, 256x512, 512x256, 512x512, the tilemap needs to be updated as the screen scrolls. For these maps, you are no longer limited by the size of the actual tilemap in VRAM but by any multiple of 8 pixels in both X and Y axis. For example, your image could be 1024x96 and you could have another image of 256*x128 (*any horizontal size) on the other part of the same BG.iNCEPTIONAL wrote: ↑Mon Jun 27, 2022 8:53 am By the way, regarding tilemaps, the largest tilemap using 8x8 tiles is 512x512 pixels, correct? But if I want a larger level in any direction (still using the same tileset), which I presume is often the case in scrolling games like my shmup, are the extra sections of the level beyond that 512x512 max tilemap size just updated in real-time by the programmer's code as the screen scrolls to reflect my full level image? If so, is this just about the programmer basically rearranging the tilemap using the tiles in the current tileset as the screen scrolls, so nowhere near as costly as having to load in all new tiles or whatever?
The "cost" of changing tiles as you're scrolling the level isn't significant at all. You could even change part of the tileset as the level progresses.iNCEPTIONAL wrote: ↑Mon Jun 27, 2022 8:53 am I'm still slightly confused about this whole tileset, tilemap, actual level stuff: I get that there is a tileset that contains all the unique tiles I will use in the background (one tileset for each background layer, which is presumably all pre-loaded normally. And for now let's say I'm going with the 8x8 tile size and sticking within the current tileset to create the whole level). I sort of get that the tilemap is those tiles laid out and repeated to create the max background tilemap that can be loaded into memory at once time (one tilemap for each layer), with the largest tilemap using 8x8 tiles being 512x512, I think. But I'm not sure exactly what happens when I want a level that's much larger than this, and how much "cost" there is having levels larger than the largest tilemap size.
If you want something advanced, you can move this process to a low priority thread and even decompress the new tileset as the level progresses. You'd need to set a trigger to load the new tileset at least a few frames in advance. A low priority thread only runs when nothing else is busy and creates no visible lag spike to the gameplay (a higher priority thread).
I can explain it better in a discord call (or "wee Zoom" as you call it) while sharing screen.
Re: Looping backgrounds vs longer level maps. . . .
OK, I messaged you on Discord.Myself086 wrote: ↑Mon Jun 27, 2022 6:04 pmFor anything that isn't 256x256, 256x512, 512x256, 512x512, the tilemap needs to be updated as the screen scrolls. For these maps, you are no longer limited by the size of the actual tilemap in VRAM but by any multiple of 8 pixels in both X and Y axis. For example, your image could be 1024x96 and you could have another image of 256*x128 (*any horizontal size) on the other part of the same BG.iNCEPTIONAL wrote: ↑Mon Jun 27, 2022 8:53 am By the way, regarding tilemaps, the largest tilemap using 8x8 tiles is 512x512 pixels, correct? But if I want a larger level in any direction (still using the same tileset), which I presume is often the case in scrolling games like my shmup, are the extra sections of the level beyond that 512x512 max tilemap size just updated in real-time by the programmer's code as the screen scrolls to reflect my full level image? If so, is this just about the programmer basically rearranging the tilemap using the tiles in the current tileset as the screen scrolls, so nowhere near as costly as having to load in all new tiles or whatever?
The "cost" of changing tiles as you're scrolling the level isn't significant at all. You could even change part of the tileset as the level progresses.iNCEPTIONAL wrote: ↑Mon Jun 27, 2022 8:53 am I'm still slightly confused about this whole tileset, tilemap, actual level stuff: I get that there is a tileset that contains all the unique tiles I will use in the background (one tileset for each background layer, which is presumably all pre-loaded normally. And for now let's say I'm going with the 8x8 tile size and sticking within the current tileset to create the whole level). I sort of get that the tilemap is those tiles laid out and repeated to create the max background tilemap that can be loaded into memory at once time (one tilemap for each layer), with the largest tilemap using 8x8 tiles being 512x512, I think. But I'm not sure exactly what happens when I want a level that's much larger than this, and how much "cost" there is having levels larger than the largest tilemap size.
If you want something advanced, you can move this process to a low priority thread and even decompress the new tileset as the level progresses. You'd need to set a trigger to load the new tileset at least a few frames in advance. A low priority thread only runs when nothing else is busy and creates no visible lag spike to the gameplay (a higher priority thread).
I can explain it better in a discord call (or "wee Zoom" as you call it) while sharing screen.
Re: Looping backgrounds vs longer level maps. . . .
Yeah, that's the kind of thing I was thinking: So, for now, if I'm not actually switching in any brands new tiles, it's really just a matter of basically rearranging the current tilemap off-screen as the screen scrolls using the tiles that are available in the already loaded tileset, and rearranging the tiles in the tilemap this way isn't something I have to really worry about too much term of the "cost" of doing so. And, as the artist, I basically still just have to give the programmer the tileset and the tilemap for the full multi-screen-long level (one tileset and one tilemap for each background layer), and the programmer will do the rest.Pokun wrote: ↑Mon Jun 27, 2022 5:02 pm Basically most games just switches out a tile column or row (or both in case of 8-way scrolling) on a part of the tilemap that is outside the visible part. This "scroll-seam" can be about anywhere on the second tilemap half, and updating this is quite trivial on the SNES for normal scrolling speeds.
Uniracer/Unirally has amazing speed, but it also uses very simplistic graphics which I guess is the drawback. The game was made by NOA as an attempt to counter Sega's aggressive commercials in USA where the SNES was portrayed as sluggish (which is partly true though).
If you need new unique tiles you can switch out those too as you scroll, but I don't know the bandwidth here. It is much slower than updating the tilemap since a single 8x8 tile pattern is 32 bytes for 4bpp tilemaps or 16 bytes if 2bpp. Compare that to a single tilemap "name" (tilemap entry) which is just 2 bytes, so it's easy to see why tilemaps are used in the first place instead of just using a pixel bitmap for the screen. It would use too much VRAM and be too slow to update for the action.
And, just to check, does that single tilemap name/entry cover the entire tilemap then (2 bytes for a whole tilemap), or is that actually 2 bytes per tile in the tilemap to move its position vs 16-32 bytes per tile if I were to load in new tiles, so moving a tile's position is really only about 8-16 times more efficient than loading in a brand new tile?
Note: My game is running in Mode 0, so it's going to be those 2bpp tiles.