Looping backgrounds vs longer level maps. . . .

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

creaothceann wrote: Mon Jun 27, 2022 11:29 am 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.
OK, good to know.

I wonder how much of a 2bpp background I could actually update every frame in reality then when not switching in any new tiles but just rearranging them off screen as the game scrolls (per layer and for all four layers in total)? Is it only a few columns worth (per layer/total)?
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Looping backgrounds vs longer level maps. . . .

Post by creaothceann »

iNCEPTIONAL wrote: Tue Jun 28, 2022 2:48 am I wonder how much of a 2bpp background I could actually update every frame in reality then when not switching in any new tiles but just rearranging them off screen as the game scrolls (per layer and for all four layers in total)? Is it only a few columns worth (per layer/total)?
The bit depth of the tile graphics doesn't matter for that, the tilemap is always the same number of bytes regardless of BG mode. It only matters when copying new tile data to VRAM.
  • There are 224 or 239 lines per frame, i.e. 28 or 30 8x8 tiles, plus 1 more if the screen position is not exactly at a tile edge. By scrolling horizontally, you have to write 58 or 62 bytes per column per BG.
  • There are 32 tiles per line, plus 1 more if the screen position is not exactly at a tile edge. By scrolling vertically, you have to write 66 bytes per row per BG.
  • Note that farther BGs usually scroll at a slower speed (parallax) to simulate depth.
  • During VBLANK, the bandwidth to transfer new data to VRAM via DMA is ~6 KB, i.e. roughly 6100 bytes, not counting the time to set up the transfer(s).
Let's assume you want to be able to scroll diagonally on all 4 BGs no more than N tiles at a time. That means 4 * (58 * N + 66 * N) = 496 * N bytes (please correct if wrong), or N * ~8.1% of your VRAM bandwidth.

- - -

(Btw. if you ever wondered why the word "character" sometimes appears in the terminology, it's because text mode graphics are basically the same thing. For PCs there's some ROM or RAM in the CGA/EGA/VGA graphics hardware that stores the font, and some region of main RAM stores the text and colors.)
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

creaothceann wrote: Tue Jun 28, 2022 5:42 am
iNCEPTIONAL wrote: Tue Jun 28, 2022 2:48 am I wonder how much of a 2bpp background I could actually update every frame in reality then when not switching in any new tiles but just rearranging them off screen as the game scrolls (per layer and for all four layers in total)? Is it only a few columns worth (per layer/total)?
The bit depth of the tile graphics doesn't matter for that, the tilemap is always the same number of bytes regardless of BG mode. It only matters when copying new tile data to VRAM.
  • There are 224 or 239 lines per frame, i.e. 28 or 30 8x8 tiles, plus 1 more if the screen position is not exactly at a tile edge. By scrolling horizontally, you have to write 58 or 62 bytes per column per BG.
  • There are 32 tiles per line, plus 1 more if the screen position is not exactly at a tile edge. By scrolling vertically, you have to write 66 bytes per row per BG.
  • Note that farther BGs usually scroll at a slower speed (parallax) to simulate depth.
  • During VBLANK, the bandwidth to transfer new data to VRAM via DMA is ~6 KB, i.e. roughly 6100 bytes, not counting the time to set up the transfer(s).
Let's assume you want to be able to scroll diagonally on all 4 BGs no more than N tiles at a time. That means 4 * (58 * N + 66 * N) = 496 * N bytes (please correct if wrong), or N * ~8.1% of your VRAM bandwidth.

- - -

(Btw. if you ever wondered why the word "character" sometimes appears in the terminology, it's because text mode graphics are basically the same thing. For PCs there's some ROM or RAM in the CGA/EGA/VGA graphics hardware that stores the font, and some region of main RAM stores the text and colors.)
It's weird to me that it seems nearly 1/10 of the VRAM bandwidth [min] is gone on just scrolling (if I've understood you correctly). But I guess it depends on how much VRAM bandwidth all the other stuff that might happen in a game level takes up (in terms of how much I really need to worry about the cost of such things). In my case, I'll only be scrolling horizontally generally, so I guess I can at least roughly half the number required for scrolling in my game.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Looping backgrounds vs longer level maps. . . .

Post by Pokun »

iNCEPTIONAL wrote: Tue Jun 28, 2022 2:33 am 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.
I think it's good to know, as an artist, roughly how the tilemap and tileset works together so I'm going to explain that.
The tilemap (AKA the "nametable") is basically just a list (although we imagine it as a 2D grid) of tile "names". Each tile pattern in the tileset (AKA the "pattern table") has a unique "name" (though it's really a number but it's called a "name") used to refer to it and this is what you write in the tilemap to determine what tile will appear where on the screen (that's why it's also called a "nametable"). The first entry in this list determines the top-left tile, the second is the tile to the right of that and so on until the last name entry which is the bottom-right tile on the screen. There are also some other attributes (which palette it uses and display priority) stored in each tilemap entry but it forms a single number value (2 byte in size).

Here is a simplified tilemap model:

Code: Select all

tileset (descriptions only):
grass (0), tree (1), bush (2), flower (3), rock (4), water (5)

tilemap:
0 3 0 0 0 5 0 0
0 0 1 0 0 5 0 4
0 3 0 0 5 0 1 0
0 2 0 0 5 1 0 0
0 0 5 5 0 0 3 0
0 0 5 0 2 2 2 0
In the above 8x6 tiles sized tilemap you can see that there are a lot of grass and a river that divides the map in two parts. There are also some rocks, trees, flowers and bushes. Note that I skipped the other attributes in this simplified model. This tilemap only contains names, no other attributes.

The tileset data is not represented here but I wrote out what the tiles in it are supposed to look like in this model. The numbers in parenthesis are the names of the tiles and the tilemap is just a grid with these names so it's easy to switch out a tile by overwriting a new name in an entry of the tilemap grid. If you want a flower in the top-right corner just write a "3" there and it will instantly change.
The tileset however contains the pixeldata for each tile. Each tileset entry is 16 bytes (for 2bpp) and to draw a new tile pattern in the tileset you have to write over all 16 bytes with your new pixel data. If you do that it will affect the tilemap as well though, say that you don't want the water tile so you overwrite it in the tileset so that it now looks like a brick tile. Now the river in the tilemap will instantly become a brickroad since there no longer is any pixel data for the water tile. Tile 5 now looks like a brick tile.

The SNES can have up to 4 screen-sized tilemaps in a 2x2 grid. This makes it very easy to scroll in any direction without any garbage showing up as tilemap entries are changed out since it's all done outside of the screen.


As for the "cost" of changing tilemap entries it is really trivial like everyone are saying so you don't normally have to worry about it. It was actually fully doable on the NES (which was created in an era when scrolling games was still not common) so it's definitely not something you have to worry about on the SNES. Scrolling games was standard in the 16-bit era and the SNES is both much faster and has more video RAM than the NES.
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

Pokun wrote: Tue Jun 28, 2022 9:37 am
iNCEPTIONAL wrote: Tue Jun 28, 2022 2:33 am 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.
I think it's good to know, as an artist, roughly how the tilemap and tileset works together so I'm going to explain that.
The tilemap (AKA the "nametable") is basically just a list (although we imagine it as a 2D grid) of tile "names". Each tile pattern in the tileset (AKA the "pattern table") has a unique "name" (though it's really a number but it's called a "name") used to refer to it and this is what you write in the tilemap to determine what tile will appear where on the screen (that's why it's also called a "nametable"). The first entry in this list determines the top-left tile, the second is the tile to the right of that and so on until the last name entry which is the bottom-right tile on the screen. There are also some other attributes (which palette it uses and display priority) stored in each tilemap entry but it forms a single number value (2 byte in size).

Here is a simplified tilemap model:

Code: Select all

tileset (descriptions only):
grass (0), tree (1), bush (2), flower (3), rock (4), water (5)

tilemap:
0 3 0 0 0 5 0 0
0 0 1 0 0 5 0 4
0 3 0 0 5 0 1 0
0 2 0 0 5 1 0 0
0 0 5 5 0 0 3 0
0 0 5 0 2 2 2 0
In the above 8x6 tiles sized tilemap you can see that there are a lot of grass and a river that divides the map in two parts. There are also some rocks, trees, flowers and bushes. Note that I skipped the other attributes in this simplified model. This tilemap only contains names, no other attributes.

The tileset data is not represented here but I wrote out what the tiles in it are supposed to look like in this model. The numbers in parenthesis are the names of the tiles and the tilemap is just a grid with these names so it's easy to switch out a tile by overwriting a new name in an entry of the tilemap grid. If you want a flower in the top-right corner just write a "3" there and it will instantly change.
The tileset however contains the pixeldata for each tile. Each tileset entry is 16 bytes (for 2bpp) and to draw a new tile pattern in the tileset you have to write over all 16 bytes with your new pixel data. If you do that it will affect the tilemap as well though, say that you don't want the water tile so you overwrite it in the tileset so that it now looks like a brick tile. Now the river in the tilemap will instantly become a brickroad since there no longer is any pixel data for the water tile. Tile 5 now looks like a brick tile.

The SNES can have up to 4 screen-sized tilemaps in a 2x2 grid. This makes it very easy to scroll in any direction without any garbage showing up as tilemap entries are changed out since it's all done outside of the screen.


As for the "cost" of changing tilemap entries it is really trivial like everyone are saying so you don't normally have to worry about it. It was actually fully doable on the NES (which was created in an era when scrolling games was still not common) so it's definitely not something you have to worry about on the SNES. Scrolling games was standard in the 16-bit era and the SNES is both much faster and has more video RAM than the NES.
OK, thanks for that. I think I got what you were saying.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Looping backgrounds vs longer level maps. . . .

Post by Myself086 »

iNCEPTIONAL wrote: Tue Jun 28, 2022 6:32 am It's weird to me that it seems nearly 1/10 of the VRAM bandwidth [min] is gone on just scrolling (if I've understood you correctly). But I guess it depends on how much VRAM bandwidth all the other stuff that might happen in a game level takes up (in terms of how much I really need to worry about the cost of such things). In my case, I'll only be scrolling horizontally generally, so I guess I can at least roughly half the number required for scrolling in my game.
It's more than 1/10 because code needs to set up the DMA and run it. But this transfer only happens for every 8 pixels scrolled. Your game isn't very intense on scrolling so it may use less than 1/10 on average. It's also possible to preload data into the tilemap and delay a transfer to prioritize sprite animation without the player ever noticing.
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

Myself086 wrote: Tue Jun 28, 2022 3:00 pm
iNCEPTIONAL wrote: Tue Jun 28, 2022 6:32 am It's weird to me that it seems nearly 1/10 of the VRAM bandwidth [min] is gone on just scrolling (if I've understood you correctly). But I guess it depends on how much VRAM bandwidth all the other stuff that might happen in a game level takes up (in terms of how much I really need to worry about the cost of such things). In my case, I'll only be scrolling horizontally generally, so I guess I can at least roughly half the number required for scrolling in my game.
It's more than 1/10 because code needs to set up the DMA and run it. But this transfer only happens for every 8 pixels scrolled. Your game isn't very intense on scrolling so it may use less than 1/10 on average. It's also possible to preload data into the tilemap and delay a transfer to prioritize sprite animation without the player ever noticing.
Well, that's my aim: To have lots of overlapping layers and a bunch of line-scrolling and stuff but hopefully not push the machine too hard on just the backgrounds alone. I mean, I need to make sure there's still plenty of resources left for everything I want to do with the player, weapons, enemies, etc too. So that's why I sometimes panic that I'm doing too much on just the backgrounds--I've yet to really have anyone do any tests on this to figure out where I'm currently at in terms of resource usage--especially since I've rarely seen quite this amount of overlapping layer stuff and line scrolling at different speeds and the like all going on at once in the backgrounds of any SNES games. Only Rendering Ranger R2 and Scrambled Valkyrie [in the SNES shmup space] seem to do about the same [with only three layers], that I've noticed, and Scrambled Valkyrie does suffer some pretty noticeable slowdown at times, which I really want to avoid at all costs.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Looping backgrounds vs longer level maps. . . .

Post by Myself086 »

iNCEPTIONAL wrote: Tue Jun 28, 2022 3:50 pm
Myself086 wrote: Tue Jun 28, 2022 3:00 pm
iNCEPTIONAL wrote: Tue Jun 28, 2022 6:32 am It's weird to me that it seems nearly 1/10 of the VRAM bandwidth [min] is gone on just scrolling (if I've understood you correctly). But I guess it depends on how much VRAM bandwidth all the other stuff that might happen in a game level takes up (in terms of how much I really need to worry about the cost of such things). In my case, I'll only be scrolling horizontally generally, so I guess I can at least roughly half the number required for scrolling in my game.
It's more than 1/10 because code needs to set up the DMA and run it. But this transfer only happens for every 8 pixels scrolled. Your game isn't very intense on scrolling so it may use less than 1/10 on average. It's also possible to preload data into the tilemap and delay a transfer to prioritize sprite animation without the player ever noticing.
Well, that's my aim: To have lots of overlapping layers and a bunch of line-scrolling and stuff but hopefully not push the machine too hard on just the backgrounds alone. I mean, I need to make sure there's still plenty of resources left for everything I want to do with the player, weapons, enemies, etc too. So that's why I sometimes panic that I'm doing too much on just the backgrounds--I've yet to really have anyone do any tests on this to figure out where I'm currently at in terms of resource usage--especially since I've rarely seen quite this amount of overlapping layer stuff and line scrolling at different speeds and the like all going on at once in the backgrounds of any SNES games. Only Rendering Ranger R2 and Scrambled Valkyrie [in the SNES shmup space] seem to do about the same [with only three layers], that I've noticed, and Scrambled Valkyrie does suffer some pretty noticeable slowdown at times, which I really want to avoid at all costs.
What I'm trying to tell you is that if you're using a 512x256 background, which is required in case you want to avoid a 7+ pixels black bar on either left or right side, you can delay when the background is updated in order to let other more important tasks complete in time. The kind of game you're making doesn't use the same amount of CPU time each frame so being able to delay tasks helps balance CPU usage so more of it can be used without lagging the game.

The same can be done to other aspects of the game such as sprite animation taking a lesser priority than movement. Even prioritizing gameplay update over graphics which a lot of games back then didn't do.
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

Myself086 wrote: Tue Jun 28, 2022 10:38 pm
iNCEPTIONAL wrote: Tue Jun 28, 2022 3:50 pm
Myself086 wrote: Tue Jun 28, 2022 3:00 pm It's more than 1/10 because code needs to set up the DMA and run it. But this transfer only happens for every 8 pixels scrolled. Your game isn't very intense on scrolling so it may use less than 1/10 on average. It's also possible to preload data into the tilemap and delay a transfer to prioritize sprite animation without the player ever noticing.
Well, that's my aim: To have lots of overlapping layers and a bunch of line-scrolling and stuff but hopefully not push the machine too hard on just the backgrounds alone. I mean, I need to make sure there's still plenty of resources left for everything I want to do with the player, weapons, enemies, etc too. So that's why I sometimes panic that I'm doing too much on just the backgrounds--I've yet to really have anyone do any tests on this to figure out where I'm currently at in terms of resource usage--especially since I've rarely seen quite this amount of overlapping layer stuff and line scrolling at different speeds and the like all going on at once in the backgrounds of any SNES games. Only Rendering Ranger R2 and Scrambled Valkyrie [in the SNES shmup space] seem to do about the same [with only three layers], that I've noticed, and Scrambled Valkyrie does suffer some pretty noticeable slowdown at times, which I really want to avoid at all costs.
What I'm trying to tell you is that if you're using a 512x256 background, which is required in case you want to avoid a 7+ pixels black bar on either left or right side, you can delay when the background is updated in order to let other more important tasks complete in time. The kind of game you're making doesn't use the same amount of CPU time each frame so being able to delay tasks helps balance CPU usage so more of it can be used without lagging the game.

The same can be done to other aspects of the game such as sprite animation taking a lesser priority than movement. Even prioritizing gameplay update over graphics which a lot of games back then didn't do.
And that sounds good to me.

I've been thinking about similar ways to use little tricks to lighten the load for SNES as it were, such as I noticed how in two-player mode on Contra, they never show both player's weapon fire onscreen at the same time but actually switch back and forth between them every second frame, which I assume means less processing and also less chance of sprite flicker due to too many objects per scanline and so on. Was even thinking using a similar technique, plus a few other things like that, might allow us to actually have a two-player mode in my shmup game too. So, yeah, little things like that to do what looks complex but in a less stressful way on the SNES poor PCU and VRAM and the like--all good..
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Looping backgrounds vs longer level maps. . . .

Post by turboxray »

iNCEPTIONAL wrote: Wed Jun 29, 2022 1:57 am
I've been thinking about similar ways to use little tricks to lighten the load for SNES as it were, such as I noticed how in two-player mode on Contra, they never show both player's weapon fire onscreen at the same time but actually switch back and forth between them every second frame, which I assume means less processing and also less chance of sprite flicker due to too many objects per scanline and so on. Was even thinking using a similar technique, plus a few other things like that, might allow us to actually have a two-player mode in my shmup game too. So, yeah, little things like that to do what looks complex but in a less stressful way on the SNES poor PCU and VRAM and the like--all good..
I'd say more than likely it was for flicker and not processing. Because the other implies that collision was happening at 30fps. But it's an early game so I wouldn't put it past them, either.
iNCEPTIONAL

Re: Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

turboxray wrote: Wed Jun 29, 2022 7:33 am
iNCEPTIONAL wrote: Wed Jun 29, 2022 1:57 am
I've been thinking about similar ways to use little tricks to lighten the load for SNES as it were, such as I noticed how in two-player mode on Contra, they never show both player's weapon fire onscreen at the same time but actually switch back and forth between them every second frame, which I assume means less processing and also less chance of sprite flicker due to too many objects per scanline and so on. Was even thinking using a similar technique, plus a few other things like that, might allow us to actually have a two-player mode in my shmup game too. So, yeah, little things like that to do what looks complex but in a less stressful way on the SNES poor PCU and VRAM and the like--all good..
I'd say more than likely it was for flicker and not processing. Because the other implies that collision was happening at 30fps. But it's an early game so I wouldn't put it past them, either.
Yeah, probably.
Post Reply