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 24: Line 24:
*Being able to make huge sprites with various poses, using double buffering techniques you can load really big poses without worrying about flickering.
*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.
*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.

Revision as of 20:55, 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.