>>18763
To be clear, I wasn't saying "fuck you" to you. I was saying "fuck you" to indie hipster retards that randomly slap shit together without understanding why the hardware had those restrictions in the first place, then call it "8bit."
>>18771
Pretty much this. I've done some retroprogramming, but not a whole game, so I can answer some questions if anyone is curious.
For example, there is a hard limit of 8 (8x8 or 8x16) sprites per scanline on the NES (with similar limits on most other systems with hardware sprites). It's impossible to display any more than that, no tricks can get around it. If you try, the first 8 sprites on that line in OAM (the sprite descriptor table) will get displayed, and everything else will be hidden.
Sprite flicker is an intentionally programmed effect, so that if (say) too many enemy appear on the same scanline, you can still see all of them instead of having one suddenly disappear complete.
Multi-directional scrolling is more difficult to program than one-directional scrolling on any platform, but the main reason for its difficulty on the NES is pretty NES-specific. The NES's backgrounds are conceptually organized into two screens, that can either be placed to the left and right of each other, or on top of one another. This makes it very easy to create levels than infinitely scroll in one direction: as you scroll past a part of the background, you overwrite it with new tiles, and when you reach the end of the virtual "screen" and wrap back around, the new screen will be there.
But then, how do you implement multi-directional scrolling like this? With only one screen of vertical height, for instance (in horizontal scrolling mode), any vertical scrolling will result in the top part of the screen immediately poking its head out of the bottom. There's no extra room to place new parts of the background.
In practice, your options are to use various hacks to hide these scrolling artifacts (either using timed code to blank out the first and last lines with a 1-screen tall screen, or by wasting sprites to cover the left and right borders on a 1-screen wide screen), hope that no one will notice the artifacts (plausible on NTSC, which crops more of the image vertically than PAL), or include an extra RAM chip in the cartridge for storing 4 "screens worth" of background at once.
Later 2D consoles don't have this problem, because they use background layers that are just slightly larger in both directions than the displayable screen, so that you always have a small amount of room to place new tiles onto. If Nintendo had realized the troubles of multidirectional scrolling before making the NES, they could have done the same and actually saved VRAM (potentially even enough to lift the 2x2 color palette grid restriction) by doing so.