Dynamic Sprite

English	Português	Español	日本語

A Dynamic Sprite is a Sprite that loads its own graphics into the VRAM (Video Memory of the Super Nintendo). This allows the sprite to use an unlimited amount of poses (animation frames) and to have a greater amount of enemy variety in a level.

It could also be considered a dynamic sprite if it loads other resources such as its color palette or tilemaps, in these cases it is usually differentiated using the term "Dynamic Palettes", "Dynamic Tilemaps", "Dynamic Background", etc.

Why is a dynamic sprite system necessary?

The VRAM of the SNES is very limited, allowing only 64 kb of memory to be used for both level graphics, tilemaps and sprite graphics. If we consider the space that is only destined for sprites (Sprite Pages), in general games do not use more than 16 kb of VRAM for sprites, which is equivalent to a space of 128x256 that is divided between all enemies, characters, player or any entity made with sprites.

Also considering that sprites can only use 8 color palettes, a dynamic sprite system that includes dynamic color palettes is also necessary, since, with only 8 color palettes the amount of different enemies you can use in a level is reduced a lot.

To solve these problems what is done is to have a system of dynamic sprites that allows to change in real time both graphics and color palettes and thus not to have all these limitations at the moment of working with sprites.

Practical Applications

Dynamic sprites have several applications, the most common is to use them for the player of a game, although in reality they could be used for enemies, bosses, decoration, etc.

Here is a list of utilities of a good dynamic sprite system:

Decrease level loading time: Since each sprite loads its own graphics, it is not necessary that these are loaded during level loading.
If you add a dynamic color palette system, you can use any dynamic sprite in any level.
Being able to have Sprites with multiple animations and poses without worrying about video memory space.
Be able to rotate or scale sprites without the need for mode 7.
Make Players, most of the sprites used as player are almost impossible without using dynamic sprites.
Being able to make huge sprites with various poses, using double buffering techniques you can load really big poses without worrying about flickering.
Bosses: many bosses are impossible to make without dynamic sprites.

Glossary

Sprite: It has 2 main meanings when spoken in the context of SNES:
- To refer to each of the OAM objects, which would come to be blocks of a fixed size (example 8x8 or 16x16) that are used to draw entities on screen that are not part of backgrounds.
- To refer to entities that are not part of the Backgrounds.
Dynamic: In the context of this guide, it refers to the ability to change in real time resources such as graphics, tilemaps or color palettes.
Dynamic Sprite: Sprite that loads its own resources in real time.
VRAM: Video memory of the SNES, used to store graphics and tilemaps.
CGRAM: Color memory of the SNES, it is used to store color palettes that are used by the graphics.
BPP: Refers to the amount of bits per pixel that a type of graphic uses, during this guide, in general we will talk about 4BPP which would be 4 bits per pixel (2 pixels per byte).
Tile: In the context of this guide tile will be used to refer to blocks of specific size (8x8, 16x16, etc.) that are used for sprites or Backgrounds. This is similar to the first definition of Sprite and will be used in general to differentiate from the second definition of Sprite.
DMA: Direct Memory Access refers mainly to a piece of hardware that is concerned with sending a massive amount of data as fast as possible.
DMA overflow: refers to when the DMA sends more data than the snes can process during NMI. This causes flickering and if excessive could even cause graphical glitches.
Frame: Refers to 1 full cycle of the SNES, the Super Nintendo uses 60 of these cycles per second (50 if PAL version). This cycle normally includes a full execution of the logic and a full execution of the NMI Handler.
NMI: Not Masked Interruption, in the context of the SNES, an NMI is generated the moment the TV pointer moves from the lower right corner to the upper left corner, which is also known as Blanking. During this interruption a function called NMI Handler is called which allows changes to be made to the console's stored resources such as graphics, color palettes, tilemaps, etc.
Pose: This term will be used to refer to the animation frames of a sprite, this is because animation frame when translated to English is Animation Frame, which can be confusing with SNES Frames.
Sprite Page: Refers to the space in the VRAM that can only be used by sprites.
Tilemap: Usually refers to the Tiles used by backgrounds, which are used both for the terrain of a level and for backgrounds or in some cases elements such as dialog boxes or HUD.

How to create a dynamic sprite system?

When creating a dynamic sprite system the following must be considered:

VRAM space management.
DMA overflow management.
Uploading data to the VRAM.
Insertion of resources in the ROM.
Connection between resources and code.

VRAM Space management in the VRAM

Fixed Allocation

A dynamic sprite needs a place in the VRAM sprite pages where it can load its poses. There are several ways to allocate space for dynamic sprites, in this section we will discuss each of these ways. Fixed Allocation

This consists of assigning a fixed place in the VRAM for a specific dynamic sprite.

Pros:

Easy to implement.
Implementation is usually very fast and efficient in terms of performance.

Cons:

In most cases, you cannot have more than one instance of the same sprite.
The allocated space is very restrictively designed to only work with that specific sprite. This makes it very restrictive to change the skin of the sprite, since the skin must use the same allocation space as the original sprite.
If you wanted to make multiple dynamic sprites you would have to assign each one a specific space and that would greatly limit the use of these sprites.
The system does not scale well, as adding more dynamic sprites or more things that require VRAM can be counterproductive.
It goes partly against the spirit of dynamic sprites, since, the idea of dynamic sprites is to increase the flexibility of using sprites and remove limitations. But this system often restricts more than it helps.

Recommendations for use

This system in general is quite bad in several senses, but it has a niche of use mainly for simple games that do not have many graphics or enemies or that these enemies do not use many poses or a big size, in this type of games, it has utility for the player or for a specific sprite that should never have more than 1 copy on screen. This niche is only if you want to have a better performance although other systems even if they are not so good in performance, I doubt you will have slowdown problems because of them.

Fixed assignment for specific tiles

This consists in that instead of using a fixed allocation for a specific sprite, this allocation is made for some specific tile animations. Tiles are usually animated continuously and allows to save some tiles in the VRAM.

Pros:

Easy to implement.
The implementation is usually very fast and efficient in terms of performance, although, not as fast as in the normal fixed allocation.

Cons:

In general it has the same cons as the fixed allocation, except that it is a bit more flexible (depending on how it is done to animate the tiles) to be able to put more than one instance of the sprite on the screen.

Recommendations for use

In general, this system is also quite bad and although it can get out of trouble to someone without much knowledge of code, I do not recommend it, but it can still have a niche in the Rom Hacks hacking when you want to implement something fast without programming a complex system of dynamic sprites for a couple of specific sprites.