rainwarrior wrote:
Considering that it's CHR-RAM, if each character had 8 x 512 byte sprite pages, you could fit 6 characters into 3 x 1k banked regions just by loading all the permutations of pairs. 8 x 8 combinations is only 64k. 6 characters in pairs like that would only take 192k.
Kind of a trade of constraints on how many source pages you need vs. how many independent characters you want. If some of the characters use the same pages, you could reuse the same 1k pages in different 1k bank slots too?
In
The Curse of Possum Hollow, we ran into a problem with permutations of characters. The game uses MMC3 with 32 KiB CHR RAM, where the player sprite uses banks 16-23 in window 2 ($1000-$13FF), commonly used objects such as powerups and particles use bank 31 in window 5 ($1C00-$1FFF), and enemies can use banks 24-30 in window 3 ($1400-$17FF) or window 4 ($1800-$1BFF). If a particular sprite sheet is 1K or smaller, multiple actors using it can share a window. (Only players and bosses have a larger sprite sheet.) But if both window 3 and window 4 are in use, and the enemy does not share a sprite sheet with the enemies in window 3 or the enemies in window 4, it enters a queue where it waits to pop into existence until window 3 or window 4 is no longer in use. (This behavior can be seen in the pattern table viewer when the game is run in a debugging emulator.)
In order to have more than two types of enemy on screen at once, we had to combine enemies that commonly occur next to each other and have less than 1K of tile data (thirty-two 8x16-pixel tiles) between them into the same sprite sheet so that they can share a window. The initial plan was to do this combining at build time, assuming that these pairs of enemies that take up parts of the same 1K sprite sheet would always occur together. But later on, the level designer felt frustration in not being able to freely vary enemy placement due to window conflicts. At that point, it was too late to change the fact that combination is done at build time, not runtime, without unduly delaying the game's release for a revamp of the sprite system. So I made a tool that would read the enemy placement data from the source code, find places where too many enemies or enemies from too many different sprite sheets are placed near one another, and write the level filenames and coordinates of the places most likely to be painful. Some were false positives, such as enemies that enter and quickly leave the screen or "decoration" enemies that can wait to pop in until other enemies leave or are destroyed.