We've just updated MediaWiki and its underlying software. If anything doesn't look or work quite right, please mention it to us. --RanAS

Dynamic Sprite: Difference between revisions

From SnesLab
Jump to: navigation, search
Line 43: Line 43:
*Implementation is usually very fast and efficient in terms of performance.
*Implementation is usually very fast and efficient in terms of performance.
==== Cons: ====
==== Cons: ====
In most cases, you cannot have more than one instance of the same sprite.
*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.
*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.
*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.
*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.
*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.

Revision as of 20:57, 16 January 2024

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.

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.
  • Space management in the VRAMedit

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.