The NES is normally limited to at most 8 sprites per scanline; if the game has more than that then some of the sprites will flicker on and off. Presumably this option disables the flickering.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
What Derakon said. The nes can't display more than 8 sprites per scanline. This results in a flicker effect as a different sprite may be drawn first and the other not being drawn:
Removing the 8 sprites per line limit results in no flickering when more than 8 sprites are on the same scanline:
If the NES works like the SNES then it's the game logic that produces the flickering (to keep them at least partially visible). If it wouldn't do that then some sprites would be permanently on and some would be permanently off.
Yes, this is true; why sprite limit removal usually works is a little more complicated.
During the rendering of each line, the NES goes through the sprites in numeric order, stopping after it's found 8. So if you have more than 8 sprites on a line, there are two ways your game can choose to flicker amongst them:
1) Reorder the sprites each frame, so that which ones are the first visible are always changing.
2) Remove sprites beyond 8 from the line entirely, so they are not considered for display.
1) is generally easier to implement, because you don't have to do any of the per line detection at all: you can just blindly reorder sprites each frame, and your game will show as little flickering as is possible.
This is why the remove sprite limit functionality usually works; because even though the sprite flickering is controlled by software, the other sprites are still there waiting to be rendered.
However, a game can choose to swap out sprites entirely when there are too many (in which case the remove sprite limit option will be nonfunctional), or use the sprite limit intentionally for other effects (in which case the remove sprite limit option will create graphical problems), so it's still a hack.