What sorts of limitations are there on moving backgrounds?

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

pwnagekirby
Posts: 3
Joined: Wed Mar 04, 2020 2:45 am

What sorts of limitations are there on moving backgrounds?

Post by pwnagekirby » Wed Mar 04, 2020 3:13 am

I've never done anything on NES, so I'm mostly looking for general (aka no need for code) answers to sate my curiosity.

Obviously lots of games have scrolling stages, but then there's also stuff like this boss from Mega Man 6, which moves itself horizontally across the screen, or these spikes from Ninja Gaiden 3, which appear to be tiles that move up and down separately from the rest of the background (that or animated tiles, though I've heard it quoted that only 32 tiles can change their image at a time, which seems to be a lower number than what's happening here (and in many other places, so I feel like maybe that's meant to say that only 32 unique tile changes can be made at a time))

So, what all is there stopping developers from just moving a background tile around like they would a sprite, so as to reduce issues with sprite limits? Can they only move on one axis at a time, or do they all need to animate on the same timer, or can they not move transparent tiles (I'm 80% sure those are a thing), or is it just too annoying to keep it from overlapping a tile with a different palette, or can two tiles not even share a 16x16 area in the first place? Those are some possibilities that come to mind, but really I'm just spit-balling, I dunno.

Pokun
Posts: 1447
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: What sorts of limitations are there on moving backgrounds?

Post by Pokun » Wed Mar 04, 2020 7:31 am

Individual background tiles can not be moved around like sprites (otherwise they would be called sprites not background tiles) so there are no overlapping of background tiles, but you can move the whole background at pixel level precision in both axes, this is what we call scrolling. However it is possible to split the background in two (or more) sections with separate scroll coordinates. This how the status bar in most scrolling games is prevented from moving when the level scrolls, since the status bar is usually made from background tiles. The simplest way to do this is how Super Mario Bros does it, by using sprite number 0's unique hardware collision feature to know when to split the background screen. There are also mappers (like MMC3) with scanline counters that makes this easier and more effective. I don't know if that's what Megaman 6 is doing with that boss though. Probably there are sprites involved as well there.

There are two backgrounds (or up to 4 if extra VRAM is added to cartridge), which we call nametables, and with some mappers it's possible to have them at different scroll coordinates as well, effectively giving you two layers of background (with some limitations), one that can be used as a status bar for example. Each nametable has their own palettes so there are no attribute clashes or anything when they overlap each other.

The 32 tile limit (which is an arbitrary limit depending on how fast your code is) is about how many tiles on the nametable you can change within a frame. And yeah that's not enough to move around a screen-size boss or those spikes. Plus you generally can't do smooth animations by changing the tiles.

Another way to move a background is to animate it by changing its CHR pattern. If you change a pattern, all tile instances that uses that pattern on the whole screen will also change accordingly and instantly, so it's possible to animate the background this way much faster than rewriting all the tiles on the nametable (which are only about 32 a frame as you said). Most games are using CHR-ROM which means the CHR is read-only, but mappers allows you to switch the CHR-ROM bank to another with other patterns, which is a cheap way to animate the background. The limitation is that you have to switch out the whole CHR tileset (or half of it with some mappers) so the whole screen may be affected unless you have duplicate patterns in the switched bank. This might be what the spikes in Ninja Gaiden 3 are doing, I don't know.
Some games uses CHR-RAM instead of CHR-ROM (by simply putting a RAM chip in place of the CHR-ROM chip) though. This makes it possible to change every individual CHR pattern however you want in software, but it's usually much slower than simply bank switching the whole CHR bank so you can't change as many patterns at once.

And yes background tiles and sprites can both have transparent pixels. By transparent I mean 100% transparent, not semi-transparent. Any pixel that isn't covered by an opaque background or sprite pixel will have the backdrop color (black in many games, or sky blue in Super Mario Bros). Semi-transparency can only be simulated by doing some special trick (like flashing the background tile or sprite).
Last edited by Pokun on Wed Mar 04, 2020 7:41 am, edited 2 times in total.

tepples
Posts: 21973
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: What sorts of limitations are there on moving backgrounds?

Post by tepples » Wed Mar 04, 2020 7:34 am

The Mega Man 6 boss is in front of a plain black background. This telegraphs to the player that a "background boss" is present. Some designers may disagree in principle with this telegraphing. It is more difficult to move a background boss vertically if a floor is also drawn as background. It is more difficult to flip a background boss horizontally.

The Ninja Gaiden 3 example shows spikes that are advancing or retracting, all at the same time. A common way to do this is to change the tile data in the pattern table (not the tilemap). One change to a tile affects everywhere that tile is used on the screen. This is how Super Mario Bros. 2: Mario Madness and Super Mario Bros. 3 animate cherries and coins respectively. It's also possible to modify the tilemap with optimized code.

The practical limit with halfway optimized code and sprites also moving around is about 128 bytes per vblank. Each tile in the pattern table takes 16 bytes. Each entry in the tilemap takes 1 byte. A bunch of updates scattered about the screen may take longer, as it takes time to update the VRAM pointer register. Games also have to allocate VRAM bandwidth to all the things that need it: playfield changes, updating the map at the scroll seam, updating the status bar, etc.

"At least one new post has been made to this topic. You may wish to review your post in light of this."

User avatar
tokumaru
Posts: 11692
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: What sorts of limitations are there on moving backgrounds?

Post by tokumaru » Wed Mar 04, 2020 7:52 am

That Mega Man 6 Boss is a simple scroll split: before the frame is rendered, the scroll is set according to the position of the boss, and an IRQ is configured to fire after the last scanline containing boss graphics is displayed, at which point the scroll is changed to match the position of the floor. On the NES you can change the horizontal and the vertical scroll (vertical is a little bit trickier to do) on any scanline - the hard part is keeping track of which scanlines are being rendered so the splits happen at the correct times. Mapper IRQs make this task much easier.

On the Ninja Gaiden example, nothing is really moving, it's just the graphics of the spikes themselves that are changing. NES backgrounds are made of references to 8x8-pixel tiles, and the tile graphics themselves are stored elsewhere. If you change the graphics of a single tile, the changes will appear everywhere on the screen where that tile is referenced. So in this case they only need to animate a handful of tiles and all spikes on the screen will change at once. The amount of tiles you can change at once varies according to the capabilities of the mapper and how much stuff is changing in addition to that, but any mapper with CHR-ROM bankswitching could change all 256 files with negligible use of CPU time.
pwnagekirby wrote:
Wed Mar 04, 2020 3:13 am
So, what all is there stopping developers from just moving a background tile around like they would a sprite, so as to reduce issues with sprite limits?
The background is a grid of tiles, which can only move as a single unit. This is why the background is usually blank when big bosses like that one from Mega Man 6 are drawn - you can't move only the boss, the whole background has to move with it.
Can they only move on one axis at a time, or do they all need to animate on the same timer
You can have as many vertical splits as you want, provided that you have a means of counting scanlines (e.g. mapper IRQs), but horizontal splits are basically impossible.
or can they not move transparent tiles (I'm 80% sure those are a thing)
Transparent tiles will scroll like any other tile, but since the NES only has a single background plane, there's nothing to display under those transparent tiles.
or is it just too annoying to keep it from overlapping a tile with a different palette, or can two tiles not even share a 16x16 area in the first place?
They can't. The background is a grid.

User avatar
tokumaru
Posts: 11692
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: What sorts of limitations are there on moving backgrounds?

Post by tokumaru » Wed Mar 04, 2020 9:25 am

Quick post to clarify something that might cause some confusion: while the NES does have multiple background maps (2 built-in, up to 4 if extra memory is included in the cartridge), those are also arranged in a grid, which means that they don't overlap. They're all part of a single background plane.

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: What sorts of limitations are there on moving backgrounds?

Post by unregistered » Wed Mar 04, 2020 3:55 pm

This post tries to elaborate on these responses. :)
Pokun wrote:
Wed Mar 04, 2020 7:31 am
Individual background tiles can not be moved around like sprites (otherwise they would be called sprites not background tiles) so there are no overlapping of background tiles,
tokumaru wrote:
Wed Mar 04, 2020 7:52 am
or is it just too annoying to keep it from overlapping a tile with a different palette, or can two tiles not even share a 16x16 area in the first place?
They can't. The background is a grid.

Think of the background as a field of an insane hop-scotch game. Insane bc the lines are drawn in a grid format. Inside each chalked square you must draw its label. Now, each “label” or tile on the NES is limited to, and must be, an 8 pixel sided-perimeter space (a smaller grid of 8 dots by 8 dots). Therefore, moving animating background tiles so they appear to move around like sprites would be extremely difficult bc you would need to make tons of pattern table (the current set of tiles being used) changes using tons of CHR data (the actual tiles). The NES can’t handle all of that data and amount of time (cycles) needed.

Sprites, on the other hand, can be moved about freely, and their transparent pixels, if being drawn on top of the background, will conveniently be replaced with the background pixel underneath. (In SMB3, when attempting to warp in world 1... after holding down on that white platform block, the character falls through the block and, if you run right, the character sprite eventually totally disappears bc it’s then drawn behind entirely-opaque background tiles.)

edit.
final edit.
Last edited by unregistered on Thu Mar 05, 2020 3:04 pm, edited 2 times in total.

Pokun
Posts: 1447
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: What sorts of limitations are there on moving backgrounds?

Post by Pokun » Thu Mar 05, 2020 3:33 am

OK that's 4 explanations of mostly the same things but using a bit different terms, hopefully reading them all is enough for it to click. Otherwise just ask.

Mario moving behind the background is simply setting the priority flag on his sprites. Every single sprite can either be in front of or behind the background tiles. Whenever Mario enters a pipe or a power up comes up from a block in SMB1, those sprites are set to be behind background tiles so it appears covered by the pipe or block. That's probably also why Mario disappears when he enters a pipe under water. The water is also made up from tiles so when Mario gets his sprite priority flag set, he appears behind the blue water tiles as well and therefore are no longer visible. An oversight of the developers that they never fixed.

pwnagekirby
Posts: 3
Joined: Wed Mar 04, 2020 2:45 am

Re: What sorts of limitations are there on moving backgrounds?

Post by pwnagekirby » Sun Mar 08, 2020 2:56 pm

Lots of good information here, thanks everyone! I think I pretty well understand what I was looking to understand.

There is one thing I'd like to clarify, though:
tokumaru wrote:
Wed Mar 04, 2020 7:52 am
You can have as many vertical splits as you want, provided that you have a means of counting scanlines (e.g. mapper IRQs), but horizontal splits are basically impossible.
When you say that you can have as many "vertical splits" as you want, do you mean like vertically-oriented sections or a vertical line down the screen?

EDIT: Actually, as a follow-up, can you have sections of the background scroll towards/away from the point where it splits?

lidnariq
Posts: 9383
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: What sorts of limitations are there on moving backgrounds?

Post by lidnariq » Sun Mar 08, 2020 3:53 pm

Top-vs-bottom splits.

An example of dozens of these splits being used for parallax is this homebrew prototype.

Only MMC5 allows left-vs-right splits, and both sides have to have the same fine X.

User avatar
nesrocks
Posts: 459
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: What sorts of limitations are there on moving backgrounds?

Post by nesrocks » Sun Mar 08, 2020 4:54 pm

I'd call that a horizontal split instead, as in, horizontally oriented split.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

User avatar
tokumaru
Posts: 11692
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: What sorts of limitations are there on moving backgrounds?

Post by tokumaru » Sun Mar 08, 2020 6:08 pm

But the screen is split vertically (into multiple horizontal sections). This is tough to name clearly.

lidnariq
Posts: 9383
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: What sorts of limitations are there on moving backgrounds?

Post by lidnariq » Sun Mar 08, 2020 10:56 pm

That is why I call them "top-vs-bottom splits", which I'd hope would obviously make it clear it's how the split divided the screen, instead of the orientation of the dividing line.

dink
Posts: 39
Joined: Sun Jan 12, 2020 8:42 pm

Re: What sorts of limitations are there on moving backgrounds?

Post by dink » Mon Mar 09, 2020 4:59 am

Question:
How does the parallax background work in Metal Storm?
Is it a similar method to the spikes on Ninja Gaiden?

thanks

User avatar
tokumaru
Posts: 11692
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: What sorts of limitations are there on moving backgrounds?

Post by tokumaru » Mon Mar 09, 2020 6:35 am

Yes, parallax effects in games like Metal Storm, Sword Master and Bucky O'Hare are achieved through pattern manipulation. The basic concept is that these games contain multiple copies of these parallax backgrounds, and by rotating them in the opposite direction of the scroll the game makes it look like they're scrolling slower than the parts using static graphics.

User avatar
Memblers
Site Admin
Posts: 3833
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: What sorts of limitations are there on moving backgrounds?

Post by Memblers » Mon Mar 09, 2020 4:28 pm

Kung Fu is one game I know of where the player character is fully on the background, becoming sprites only on the entrance/exit to the level. It had me fooled for a while, even after I knew more about the NES capabilities. You can see as a result though, the background is really plain compared to the original arcade version (Kung Fu Master).

Post Reply