The NES, although being an awesome console (especially considering its age), is not without its limitations. For example, the NES can draw up to 64 sprites on screen. A sprite is an 8×8 pixel image that can move freely on screen. So for instance when your main character is a 16×16 pixel character, it will use 4 of the 64 available sprites. To make matters worse, whenever there are more than 8 sprites on a horizontal scanline, additional sprites on that line won’t be drawn. Here are two code modifications which can help you overcome this limitation.
1. Don’t draw empty sprites
When using larger objects (for instance a 32×32 pixel enemy, taking up 25 percent of available sprites) the object may have one or a few sprites that are fully transparent. By default, NESmaker draws these transparent sprites on screen, taking up one of the available sprites. These may add up to a point where horizontal scanlines are overpopulated, or even the 64 sprite limit may be exceeded.
To solve this problem, forum user CutterCross posted a solution which prevents NESmaker from drawing invisible or transparent sprites. Basically, what you do is check each sprite of an object, and if it references a dedicated transparent sprite tile, it skips drawing that sprite on screen, saving you a few sprites in the long run. You can find the solution and its implementation here.
2. Enable sprite flickering
When more than eight sprites are on a horizontal scanline, you can use sprite flickering to still show them all. Sprites get drawn on screen sixty times per second. The order in which these get drawn, can be modified through code. By continuously changing the sprite priority (ie. changing which sprites should be drawn first every frame), you can simulate more than eight sprites being shown on a scanline. Basically, you draw eight sprites every odd frame, and draw eight other sprites every even frame. In essence, the sprites “flicker” every other frame. Hence the name “sprite flickering”.
By default, NESmaker uses the same sprite priority every frame. Luckily, a forum user by the name of AllDarnDavey has implemented a way to randomize this prioritization, enabling sprite flickering in your NESmaker project. You can find the instructions to enabling sprite flickering here.
Other possible solutions
These are two pretty quick fixes to help you overcome the sprite limits of the NES. There are more solutions though. Especially or bigger bosses that won’t have to move on screen, you can use backgound tiles instead of sprites for most of their graphics. Applying more advanced techniques like CHR bankswitching and playing with the scrolling offset might even enable you to move large graphics on screen. This is how Mega Man 1 prevented sprite overload in the Dr. Wily boss fight: the boss does not really move, but rather the screen itself moves, using the scroll offsets. That’s why the background is fully black: so you don’t see that the background is actually moving instead of the sprites. But as I said, this is pretty advanced stuff that may be more fitting for a native nesdev project, rather than within NESmaker.