How are animations stored and used on the NES?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
How are animations stored and used on the NES?
by on (#185032)
Hi, I'm very new at this kind of stuff and I'd like to know how are animations stored on the NES?

How are the length and (especially) x/y offsets of the animation defined for example, what kind of control does the developer have in regards to it?

Is it somewhat similar or very different to how many animations are stored nowadays, with .json files or something defining each frame's length, x, y, flip etc.
Re: How are animations stored and used on the NES?
by on (#185033)
The NES PPU can use either all 8x8 pixel sprites or all 8x16 pixel sprites. To create larger characters, games use "metasprites" to specify how smaller hardware sprites shall be combined into a single frame of animation, and they render these metasprites to a display list each frame. Different game engines use different formats for metasprites. Some games assume that individual sprites shall form a regular grid. Some games allow each sprite to be individually placed at an arbitrary (x, y) offset from the hotspot. Some games have a compromise, with each sprite cel consisting of a set of regular horizontal strips whose first sprite can be placed at an arbitrary (x, y) offset from the hotspot and whose subsequent sprites are placed at regular 8-pixel offsets.

One game I worked on used something similar to the json files you mention as a means to generate such strips.

Or are you looking for a survey of which particular titles use each of these techniques?
Re: How are animations stored and used on the NES?
by on (#185052)
The NES itself doesn't know anything about animations, all it does is draw 8x8-pixel (or 8x16-pixel) sprites according to information from the OAM (X, Y, tile index, palette, flipping and priority), anything beyond that has to be implemented by the programmer and varies greatly from game to game.

Games normally use metasprites, which consist of groupings of hardware sprites (8x8 or 8x16) to form larger pictures, and these are usually defined in tables, in a format the game's engine was coded to translate into individual OAM entries. Animation systems are built on top of that, with the use of timers and simple scripts (with commands like "goto frame X" or "stop"). Animations may also be defined in tables in a format the game's engine was coded to understand, where references to the metasprites will be stored along with the script commands, delay values, and so on.