You appear to be mixing up sprites and objects. An object/actor/entity (or whatever you want to call it) is something that exists in the game world, while a sprite is just a visual representation of that thing. Sprites are quite limited on the NES (64 per frame, 8 per scanline), so games don't typically hardcode hardware sprites to game objects, but instead generate a new list of hardware sprites every frame based on the objects that are currently active, assigning different sprite slots for each object every frame. The purpose of this is mainly to cycle the priority of the sprites so that different sprites are dropped each frame in case the limits are reached (which can happen quite often depending on the type of the game), so you get flickering instead of completely invisible objects.
Contrary to popular belief, sprite flickering in NES games is not automatic: if the hardware finds more than 8 sprites on the same scanline, it will simply not draw anymore sprites on that scanline. It's up to the programmer to rotate the sprite priorities so that different sprites are dropped each frame.
Also, the NES has very limited processing power, so indeed most games only keep track of objects that are near the camera. In a side scroller this is pretty easy: just keep your list of objects sorted by their X coordinates and every few pixels scrolled compare the position of an imaginary "spawn column" against the coordinate of the next object in the list, and if it's larger, activate the object. Active objects can test their own coordinates against the camera and choose to deactivate themselves if they're too far.
mantanz wrote:
It's possible to clear the PPU and load new tile sets on the fly right?
Yeah, but you can only write to VRAM during vblank or when rendering is disabled.
Quote:
Basically I want to turn the background black at the end of a level, clearing the background, and load a new tile set to use for a big Boss.
The way a new tileset is loaded depends on the type of CHR memory you're using, ROM or RAM. ROM can be switched nearly instantaneously, since the process consists basically in telling the mapper to point to a different place in a bigger CHR-ROM chip (i.e. there's no data being moved anywhere), while CHR-RAM must be rewritten manually byte by byte. CHR-RAM is more common among homebrews, because the mappers that use CHR-RAM are usually easier/cheaper to recreate in cartridge form.
Either would work well for what you describe though, since you plan on fading to black and back in... If using CHR-ROM, just have the mapper switch the new tiles at any time, if using CHR-RAM, upload the new tileset byte by byte across several consecutive vblanks until the whole thing is done, then you can fade back in. With the fastest possible code (unrolled loop), you'd be able to update the whole 8KB of CHR-RAM in about half a second (i.e. 30 vblanks), but a full second using a regular loop doesn't sound bad either.