nesdev.org

@Okk : It's always like this, if 95% of games handles something a simple way and that 5% of them are doing it an "improved" way for which the hardware was not originally designed for, and requires some kind of "trickery", you can bet that all Nesdev regulars (including myself) are only talking about those rare/complex cases because they're more interesting and push the system closer to its limit.

So sprite animation is done like this :
aprox 80-90% of games : Static sprite pages that are only re-loaded / bankswitched when changing the levels (if at all)
aprox 10-15% of games : CHR-ROM, reserve a whole page for the main character and switch it depending on the animation frame
aprox 1% of games : CHR-RAM is updated as the character is animated. I can only think of a great total of 3 games (there's probably more) : Solstice, Battletoads and Prince of Persia.

So tepples and tokumaru were talking as if only the two last alternatives are possible, when in fact the first one is sufficient for the vast majority of cases, but is of course less interesting on the technical plan.

Also please note that I MADE THOSE NUMBERS UP I didn't collect them scientifically, but it is to show the idea.

Okk wrote:I saw a thread down lower comparing the advantages of 8x8 sprites with the advantages of 8x16 sprites, and I think I should take another look at that, but yeah I am leaning towards 8x16. The majority of my objects are going to be 16x16, so that would mean I could have as many as 32 instead of 16 onscreen at a time, right?

Oh, sorry, for some reason (I honestly don't know why!) I though you meant you were gonna make the characters 8x16 pixels big, not that they were going to be made of multiple 8x16 sprites. In this case, yes, I totally agree with you. I always use 8x16, because even if you waste some tiles you can have more stuff on the screen.

Of course, I should probably evaluate whether or not I actually NEED 32 objects onscreen at a time.

On a real NES that wouldn't happen so often, because managing that many objects would consume a lot of CPU time and would probably cause slowdowns. Unless they were really simple objects, without complex physics behaviors or the ability to collide with many different objects.

Because I don't see bank switching done to animate sprites quite as much. That is, it does happen - Mario 3 swaps in a new set of tiles when any powered up Mario jumps - but it's a SET of tiles to use for animations. A new bank switch doesn't take place every frame.

You're correct. Many games that use mappers with 1KB or 2KB CHR bankswitching do have the main character's graphics spread across several banks, but the actual animation is not a direct consequence of the switch. In most cases, the OAM (memory that defines where the sprites are and what colors and tiles they use) is completely wiped and rewritten every frame. Each game implements its own solution, but I assume most have some sort of animation scripting system, with pointers to metasprites (the values that will be processed according to the positions of the objects they represent to generate OAM data) and timing information (how long each animation frame should be displayed).

tepples wrote:The technique is more common on Genesis, Super NES, and Game Boy Advance, all of which have hardware-assisted copying to VRAM.

But also on the Master System and B/W Game Boy, which don't have any hardware assistance (on the Master System this is almost mandatory, since it doesn't have sprite flipping), even if sometimes they have to use double buffering to avoid displaying partially updated sprites. There's one NES game I can think of, The Smurfs, which does take longer than a frame to update player patterns and doesn't do anything to hide it. The problem is clearly visible in this level, because of the bird's wings.

Bregalad wrote:aprox 80-90% of games : Static sprite pages that are only re-loaded / bankswitched when changing the levels (if at all)

I think it's a bit less.

aprox 10-15% of games : CHR-ROM, reserve a whole page for the main character and switch it depending on the animation frame

I think it's a bit more.

aprox 1% of games : CHR-RAM is updated as the character is animated. I can only think of a great total of 3 games (there's probably more) : Solstice, Battletoads and Prince of Persia.

The percentage looks about right in this case. One game you forgot is The Smurfs, which I mentioned above. But like you said, there are probably more.

EDIT: I went looking for more games that animate player sprites through pattern table updates, and here are a few names:

-Alfred Chicken
-Asterix
-Bad Street Brawler
-Castelian
-Dragon's Lair
-Indiana Jones and the Last Crusade (Taito)
-Indiana Jones and the Last Crusade (UBI Soft)
-Ironsword - Wizards & Warriors II
-Wizards & Warriors III

Guess this technique isn't so rare on the NES after all. With a little more effort we can probably list at least 20 games or so, which would be more than 1% of all NES games.