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

Looping backgrounds vs longer level maps. . . .

Post by iNCEPTIONAL »

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)?
Last edited by iNCEPTIONAL on Tue Jun 28, 2022 2:09 am, edited 3 times in total.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

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

Post by Oziphantom »

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.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

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

Post by jeffythedragonslayer »

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)?
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

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

Post by iNCEPTIONAL »

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.
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.

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.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Wed Jun 15, 2022 3:30 am
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)?
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.
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)?
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

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

Post by jeffythedragonslayer »

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)?
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.)

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.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Wed Jun 15, 2022 8:59 am
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)?
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.)

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.
OK.

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?
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

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

Post by Myself086 »

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.
Either give the images or tileset+tilemap+palettes.
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 I'm not sure what you mean by "same".
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].
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 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.
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

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

Post by iNCEPTIONAL »

Myself086 wrote: Wed Jun 15, 2022 11:19 am
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 I'm not sure what you mean by "same".
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.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

jeffythedragonslayer wrote: Wed Jun 15, 2022 8:59 am
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)?
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.)

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.
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?

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.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

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

Post by creaothceann »

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.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

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

Post by Pokun »

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.
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

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

Post by Myself086 »

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?
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 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.
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.

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.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

Myself086 wrote: Mon Jun 27, 2022 6:04 pm
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?
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 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.
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.

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.
OK, I messaged you on Discord.
iNCEPTIONAL

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

Post by iNCEPTIONAL »

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.
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.

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.
Post Reply