SnesLab - Recent changes [en]

SMWHub

Anonimzwx — Sat, 06 Jun 2026 19:09:01 GMT

Created page with "{{Select Language|SMWHub}} {| class="wikitable" |- ! Nombre | SMWHub |- ! Autor | anonimzwx |- ! Lenguaje de programación | C# |- ! Plataformas | Windows, Linux |- ! Proposito | Framework de inserción de recursos All-in-one para Super Mario World |- | Github | [https://github.com/weierstrass1/SMWHub| SMWHub Repository] |} == Introducción == SMWHub es una herramienta todo en uno para la inserción y gestión de recursos en Super Mario World. Su ob..."

New page

{{Select Language|SMWHub}}

{| class="wikitable"
|-
! Nombre
| SMWHub
|-
! Autor
| [[User:Anonimzwx|anonimzwx]]
|-
! Lenguaje de programación
| C#
|-
! Plataformas
| Windows, Linux
|-
! Proposito
| Framework de inserción de recursos All-in-one para Super Mario World
|-
| Github
| [https://github.com/weierstrass1/SMWHub| SMWHub Repository]
|}

== Introducción ==

SMWHub es una herramienta todo en uno para la inserción y gestión de recursos en Super Mario World. Su objetivo es unificar en una sola aplicación las funcionalidades tradicionalmente proporcionadas por herramientas como PIXI, UberASM Tool, GPS, Dynamic Xtreme, HitmanTool y otras utilidades relacionadas, permitiendo administrar todos los recursos de un proyecto desde un único lugar.

Además de centralizar la inserción de recursos, SMWHub incorpora diversas mejoras de calidad de vida orientadas a simplificar el desarrollo y mantenimiento de proyectos. Entre ellas se incluyen soporte para múltiples índices o rangos de índices, sistemas de recursos compartidos entre distintos tipos de inserciones y formatos embebidos que permiten almacenar información auxiliar directamente dentro de los archivos ASM.

Actualmente, SMWHub permite integrar dentro del propio código ensamblador distintos tipos de datos que normalmente requerirían archivos externos, incluyendo configuraciones de sprites, archivos de Dynamic Xtreme (.dynamicinfo, .drawinfo y .effect), archivos binarios codificados en Base64 e información de hitboxes utilizada por sistemas de interacción personalizados.

La herramienta también proporciona mecanismos para compartir rutinas, macros y defines entre distintos recursos del proyecto, facilitando la reutilización de código y reduciendo la duplicación de lógica común.

SMWHub está diseñado para ser fácil de utilizar tanto por usuarios principiantes como avanzados. En su forma más simple, basta con ejecutar la herramienta para procesar e insertar automáticamente todos los recursos configurados en el proyecto. Para flujos de trabajo más complejos, también dispone de una interfaz de línea de comandos que ofrece opciones adicionales de automatización e integración.

== Instalación ==

Artículo principal: [[es/SMWHub_instalation|SMWHub Instalación]]

== Estructura de Carpetas ==

Artículo principal: [[es/SMWHub_files_and_formats|SMWHub Archivos y Formatos]]

== Funcionalidades ==

=== Recursos Compartidos ===

==== Macros Compartidas ====

==== Rutinas Compartidas ====

==== Defines Compartidos ====

=== Parches ====

=== Sprites ====

==== Sprites Normales ====

==== Cluster Sprites ====

==== Extended Sprites ====

==== Overworld Sprites ====

=== UberASM ====

==== Códigos de Nivel ====

==== Códigos de Gamemode ====

==== Códigos de Overworld ====

=== Bloques ====

=== Dynamic Xtreme ====

==== Archivos Embebido ====

==== Recursos Dinámicos Compartidos ====

=== HitmanTool ====

==== Recursos Dinámicos Compartidos ====

== Migración desde otras herramientas ==

Artículo principal: [[es/SMWHub_migrations|SMWHub Migraciones]]

== Véase también ==

* [[es/Asar| Asar]]
* [[es/Pixi| Pixi]]
* [[es/UberasmTool| UberasmTool]]
* [[es/GPS| GPS]]
* [[es/Bowsie| Bowsie]]
* [[es/Dynamic_Xtreme| Dynamic_Xtreme]]
* [[es/HitmanTool| HitmanTool]]

TCALL (SPC700)

Xetheria — Sat, 06 Jun 2026 12:10:04 GMT

capitalize other L

← Older revision		Revision as of 12:10, 6 June 2026
Line 127:		Line 127:
	\|}		\|}

	'''TCALL''' (Table ~~CALl~~) is an [[SPC700]] instruction that calls a subroutine whose 16-bit address is stored in the [[uppermost page]]. The low byte of the address of the vector (pointer to subroutine) is a function of the high nybble of the opcode, equal to $DE - n*2. The high byte of the vector address is always $FF.		'''TCALL''' (Table CALL) is an [[SPC700]] instruction that calls a subroutine whose 16-bit address is stored in the [[uppermost page]]. The low byte of the address of the vector (pointer to subroutine) is a function of the high nybble of the opcode, equal to $DE - n*2. The high byte of the vector address is always $FF.

	No flags are affected.		No flags are affected.

es/Dynamic Xtreme files and formats

Anonimzwx — Fri, 29 May 2026 17:54:16 GMT

DrawInfo

← Older revision		Revision as of 17:54, 29 May 2026
Line 418:		Line 418:
	== DrawInfo ==		== DrawInfo ==

	Los archivos DrawInfo se almacenan dentro de la carpeta DrawInfos y utilizan la extensión '''"*.~~dynamicinfo~~"''' y contienen la información necesaria para dibujar poses en pantalla.		Los archivos DrawInfo se almacenan dentro de la carpeta DrawInfos y utilizan la extensión '''"*.drawinfo"''' y contienen la información necesaria para dibujar poses en pantalla.

	Internamente, Dynamic Xtreme recopila esta información y genera rutinas gráficas optimizadas automáticamente. Cada rutina gráfica agrupa múltiples poses que comparten características similares y es optimizada específicamente para ese tipo de poses. Esto permite no solo un sistema global de renderizado de poses, sino también un sistema bastante eficiente en una gran cantidad de casos.		Internamente, Dynamic Xtreme recopila esta información y genera rutinas gráficas optimizadas automáticamente. Cada rutina gráfica agrupa múltiples poses que comparten características similares y es optimizada específicamente para ese tipo de poses. Esto permite no solo un sistema global de renderizado de poses, sino también un sistema bastante eficiente en una gran cantidad de casos.

Dynamic Xtreme files and formats

Anonimzwx — Fri, 29 May 2026 17:53:34 GMT

DrawInfo

← Older revision		Revision as of 17:53, 29 May 2026
Line 419:		Line 419:
	== DrawInfo ==		== DrawInfo ==

	DrawInfo files are stored inside the DrawInfos folder and use the '''"*.~~dynamicinfo~~"''' extension and contain all the information required to draw poses on screen.		DrawInfo files are stored inside the DrawInfos folder and use the '''"*.drawinfo"''' extension and contain all the information required to draw poses on screen.

	Internally, Dynamic Xtreme collects this information and automatically generates optimized graphic routines. Each graphic routine groups multiple poses that share similar characteristics and is specifically optimized for that type of pose. This allows not only a global pose rendering system, but also a highly efficient system in a large number of cases.		Internally, Dynamic Xtreme collects this information and automatically generates optimized graphic routines. Each graphic routine groups multiple poses that share similar characteristics and is specifically optimized for that type of pose. This allows not only a global pose rendering system, but also a highly efficient system in a large number of cases.

Stack

Xetheria — Thu, 21 May 2026 21:36:13 GMT

no stack base pointer

← Older revision		Revision as of 21:36, 21 May 2026
Line 34:		Line 34:
	* [[RTI]]		* [[RTI]]

	Note the lack of [[PLK]]. PHS and PLS similarly do not exist, nor do any instructions performing the inverse of PEA, PEI, or PER.		Note the lack of [[PLK]]. PHS and PLS similarly do not exist, nor do any instructions performing the inverse of PEA, PEI, or PER. Unlike x86, there is also no stack base pointer.

	=== See Also ===		=== See Also ===

COP

Xetheria — Thu, 21 May 2026 06:53:17 GMT

Undo revision 21257 by Xetheria (talk)

← Older revision		Revision as of 06:53, 21 May 2026
Line 67:		Line 67:
	=== External Links ===		=== External Links ===
	# [[Eyes & Lichty]], [https://archive.org/details/0893037893ProgrammingThe65816/page/447 page 447] on COP		# [[Eyes & Lichty]], [https://archive.org/details/0893037893ProgrammingThe65816/page/447 page 447] on COP
	# [[Labiak]], [https://archive.org/details/Programming_the_65816/page/~~135~~ page 135] on COP		# [[Labiak]], [https://archive.org/details/Programming_the_65816/page/n145 page 135] on COP
	# section 7.15 of 65c816 datasheet		# section 7.15 of 65c816 datasheet
	# snes9x implementation of COP: https://github.com/snes9xgit/snes9x/blob/master/cpuops.cpp#L2738		# snes9x implementation of COP: https://github.com/snes9xgit/snes9x/blob/master/cpuops.cpp#L2738

BRK

Xetheria — Thu, 21 May 2026 06:51:14 GMT

Undo revision 21258 by Xetheria (talk)

← Older revision	Revision as of 06:51, 21 May 2026
(One intermediate revision by the same user not shown)
(No difference)

COP

Xetheria — Thu, 21 May 2026 06:37:55 GMT

External Links: de n'd page number

← Older revision		Revision as of 06:37, 21 May 2026
Line 67:		Line 67:
	=== External Links ===		=== External Links ===
	# [[Eyes & Lichty]], [https://archive.org/details/0893037893ProgrammingThe65816/page/447 page 447] on COP		# [[Eyes & Lichty]], [https://archive.org/details/0893037893ProgrammingThe65816/page/447 page 447] on COP
	# [[Labiak]], [https://archive.org/details/Programming_the_65816/page/~~n145~~ page 135] on COP		# [[Labiak]], [https://archive.org/details/Programming_the_65816/page/135 page 135] on COP
	# section 7.15 of 65c816 datasheet		# section 7.15 of 65c816 datasheet
	# snes9x implementation of COP: https://github.com/snes9xgit/snes9x/blob/master/cpuops.cpp#L2738		# snes9x implementation of COP: https://github.com/snes9xgit/snes9x/blob/master/cpuops.cpp#L2738

es/Dynamic Xtreme

Anonimzwx — Mon, 18 May 2026 18:35:18 GMT

Quick Start

← Older revision		Revision as of 18:35, 18 May 2026
Line 26:		Line 26:
	== Quick Start ==		== Quick Start ==

	Guía rápida de instalación: [[es/Dynamic_Xtreme_Quick_Start\|Quick Start]]		'''Guía rápida de instalación:''' [[es/Dynamic_Xtreme_Quick_Start\|Quick Start]]

	== Herramientas y Soporte ==		== Herramientas y Soporte ==

Dynamic Xtreme

Anonimzwx — Mon, 18 May 2026 18:35:07 GMT

Quick Start

← Older revision		Revision as of 18:35, 18 May 2026
(One intermediate revision by the same user not shown)
Line 31:		Line 31:
	== Quick Start ==		== Quick Start ==

	Quick Installation Guide: [[Dynamic_Xtreme_Quick_Start\|Quick Start]]		'''Quick Installation Guide:''' [[Dynamic_Xtreme_Quick_Start\|Quick Start]]

	== Tools and Support ==		== Tools and Support ==

	== Files and Formats ==		== Files and Formats ==

			'''Related article:''' [[Dynamic_Xtreme_files_and_formats\|Dynamic Xtreme Files and Formats]]

	== Dynamic Sprite Creation Guide ==		== Dynamic Sprite Creation Guide ==

es/Dynamic Xtreme

Anonimzwx — Mon, 18 May 2026 18:33:37 GMT

Archivos y formatos

← Older revision		Revision as of 18:33, 18 May 2026
Line 32:		Line 32:
	== Archivos y formatos ==		== Archivos y formatos ==

	'''Artículo relacionado:''' [[es/~~Dynamic_Xtreme_archivos_y_formatos~~\|Archivos y Formatos de Dynamic Xtreme]]		'''Artículo relacionado:''' [[es/Dynamic_Xtreme_files_and_formats\|Archivos y Formatos de Dynamic Xtreme]]

	== Guía de creación de sprites dinámicos ==		== Guía de creación de sprites dinámicos ==

Dynamic Xtreme files and formats

Anonimzwx — Mon, 18 May 2026 18:32:11 GMT

Created page with "{{Select Language|Dynamic_Xtreme_files_and_formats}} Dynamic Xtreme uses its own well-structured file system, allowing users to have precise and flexible control over the resources, effects, and data used during the game's execution. This page documents the different types of files handled by the tool, how they work, their purpose, and the specific formats they use (both current and legacy). Understanding this structure is essential to fully take advantage of Dynamic X..."

New page

{{Select Language|Dynamic_Xtreme_files_and_formats}}

Dynamic Xtreme uses its own well-structured file system, allowing users to have precise and flexible control over the resources, effects, and data used during the game's execution.

This page documents the different types of files handled by the tool, how they work, their purpose, and the specific formats they use (both current and legacy). Understanding this structure is essential to fully take advantage of Dynamic Xtreme's capabilities.

Many of the legacy formats present in Dynamic Xtreme originally come from Dynamic X, the older version from which the project evolved. These formats remain fully compatible in order to preserve support for a large amount of already existing resources developed for Dynamic X.

The following sections detail the main file types and their formats:

== File Types ==

Dynamic Xtreme uses several specialized file types. The main ones are described below:

* '''Dynamic Resources''': Resources stored uncompressed inside the ROM. They are commonly used for dynamic sprites, graphics replacement, tilemap replacement, or palette replacement.
* '''Palette Effects (*.paleffect):''' Files used to register color palette effects.
* '''Dynamic Info (*.dynamicinfo):''' Files used to include dynamic resources into the ROM and also generate the relevant data for dynamic sprites.
* '''Draw Info (*.drawinfo):''' Files used to generate sprite poses (animation frames) and later draw them on screen.

== Dynamic Resources ==

Dynamic Resources are one of the core systems of Dynamic Xtreme. These resources are stored uncompressed inside the ROM, allowing them to be loaded and used quickly during gameplay.

=== How does the system work? ===

Dynamic Xtreme collects all dynamic resources, organizes them into packages of up to 1 bank (32 or 64 KB), and automatically inserts them into the ROM. If the ROM has available hi-banks, the tool prioritizes those banks for insertion, improving space organization.

There is no strict limitation on the type of data that can be inserted, although most files are usually '''"*.bin"''' files.

=== Main uses ===

Dynamic resources are commonly used for:
* '''Graphics:''' Dynamic sprite graphics or real-time graphics replacement.
* '''Tilemaps:''' Replacing tiles from different level layers.
* '''Color palettes:''' Replacing full palettes or assigning specific palettes to dynamic sprites.
* '''Others''': Any type of information that needs to be stored in the ROM, such as .brr audio samples, data tables, etc.

This makes the system extremely flexible, allowing not only graphical uses but also any other type of data the user may need to access quickly from the ROM.

=== Color Palette Files ===

Currently, the best way to store color palette files is by using binary files ('''*.bin''') where each color occupies 2 bytes following the color format used by the SNES. There are tools that simplify this process, such as [https://www.smwcentral.net/?p=section&a=details&id=24827 Pal2Bin].

To understand this, it is important to consider that the SNES color format is BGR555. This means that each color is stored using 5 bits for blue, 5 bits for green, and 5 bits for red.

Conceptually, the bits are organized like this:

<code>-BBBBB GGGGG RRRRR</code>

However, due to the endian format used by the SNES, the bytes must be stored reversed in memory, so internally they end up organized like this:

<code>GGG RRRRR -BBBBB GG</code>

Because this format can be confusing for users unfamiliar with SNES hardware, improved support for '''*.pal''' files is planned for the future, since they are much more common and widely used in modern graphics tools.

In the case of palettes used by dynamic sprites, they must contain a maximum of 15 colors. This means that only colors 1 through 15 of the corresponding palette should be included, since color 0 is used as transparency.

=== Graphics for Dynamic Sprites ===

Graphics used by dynamic sprites in Dynamic Xtreme must follow certain organization rules depending on the format used by the resource.

Currently, there are two formats supported by the system:

* Current format
* Legacy format

The modern format was designed to simplify the creation and maintenance of dynamic resources, allowing the use of layouts that are much easier to understand and organize.

On the other hand, the legacy format corresponds to the original system based on PosesChunksSizes, which offers more advanced and flexible control over the internal organization of graphics in VRAM, but also requires a deeper understanding of how the dynamic system works internally.

==== Current Format ====

The modern format is simply based on organizing graphics as continuous 16x16 tiles in VRAM. This format was designed to greatly simplify the process of creating dynamic sprites.

Example:

The example image shows a 32x32 sprite (which uses 4 16x16 tiles) being organized inside the graphics file.

[[File:imagen 2026-05-17 221817296.png|thumb]]

With this system, the user only needs to worry about visually organizing the tiles in the correct order for each pose.

Internally, Dynamic Xtreme reads these graphics and automatically converts them into the legacy format, which is easier for SNES hardware to handle. Additionally, the system automatically removes empty spaces generated by partial tiles declared through modifiers such as q, th, bh, lh, or q3.

==== Legacy Format ====

The legacy format uses a graphics organization system optimized to simplify the internal handling of dynamic graphics on SNES hardware.

Unlike the modern format, in this case the user must manually organize the graphics following the layout required by the system.

When a pose uses 7 or fewer 16x16 tiles, the tiles are first organized into a continuous horizontal row. Then, each 16x16 tile must be divided into two 16x8 halves:

* top half.
* bottom half.

After this:

* all top halves are placed continuously first.
* then all bottom halves are placed immediately after.

Example:

Given a pose made of 4 16x16 tiles, the following tiles are used:

<code>t1 t2 t3 t4</code>

They must be organized as follows:

<code>t1th t2th t3th t4th t1bh t2bh t3bh t4bh</code>

Where:

* tx corresponds to a 16x16 tile.
* txth corresponds to the top half of a 16x16 tile.
* txbh corresponds to the bottom half of a 16x16 tile.

When a pose uses 8 or more 16x16 tiles, all complete rows of 8 tiles must first be separated. These complete rows can be stored directly without additional reorganization.

Then, any remaining tiles that do not complete a full row of 8 tiles must be organized using the same system previously explained for poses with 7 tiles or fewer.

==== Considerations About Tile Overlap ====

In static sprites, it is common to use tile overlap to save graphic space. For example, in a 24x24 sprite it is common to use 3 16x16 tiles and 1 8x8 tile, taking advantage of overlap between the 16x16 tiles.

However, this type of organization is not valid for dynamic sprites.

Because dynamic graphics can be loaded into VRAM in unpredictable ways, tiles cannot visually depend on each other through overlap. Each tile must contain only the graphics corresponding to its own area.

For example, for a 24x24 sprite, instead of using overlap between 16x16 tiles, it is recommended to use:

* 2 diagonal 16x16 tiles with a shared 8x8 area between them.
* 2 8x8 tiles organized inside a space equivalent to 1 16x16 tile.

Tile overlap is not allowed in dynamic sprites, although redundancy between 2 different tiles is still possible and those tiles can be strategically organized to save OAM tiles. Additionally, it is still possible to save space through the strategic use of 8x8 tiles.

== Palette Effects ==

Palette Effect files are stored inside the PaletteEffects folder and use the '''"*.paleffect"''' extension.

Palette effects allow real-time color modifications over the palettes used by the game. These effects can be used by Dynamic Xtreme's global palette effect system.

Internally, these systems work by modifying the '''RGB''' or '''HSL''' channels of palette colors in order to produce different visual effects.

Some common uses include:

* Day-to-night transitions.
* Red flashes to indicate danger.
* Blinking cyan effects for objects about to explode.
* Hue changes for disco-like effects.
* Smooth transitions between visual states.
* Lighting or ambient effects.

The system allows a huge variety of combinations and visual effects.

=== Effect Types ===

Currently, the following effects exist:

<ul>
<li>'''MixRGB (ID 0)''': Interpolates the '''RGB''' channels with a base color.</li>
<li>'''MixHSL (ID 1)''': Interpolates the '''HSL''' channels with a base color.</li>
<li>'''MixRG (ID 2)''': Interpolates only '''R''' and '''G'''.</li>
<li>'''MixGB (ID 3)''': Interpolates only '''G''' and '''B'''.</li>
<li>'''MixRB (ID 4)''': Interpolates only '''R''' and '''B'''.</li>
<li>'''MixHS (ID 5)''': Interpolates only '''H''' and '''S'''.</li>
<li>'''MixSL (ID 6)''': Interpolates only '''S''' and '''L'''.</li>
<li>'''MixHL (ID 7)''': Interpolates only '''H''' and '''L'''.</li>
<li>'''MixR (ID 8)''': Interpolates only the '''R''' channel.</li>
<li>'''MixG (ID 9)''': Interpolates only the '''G''' channel.</li>
<li>'''MixB (ID 10)''': Interpolates only the '''B''' channel.</li>
<li>'''MixH (ID 11)''': Interpolates only the '''H''' channel.</li>
<li>'''MixS (ID 12)''': Interpolates only the '''S''' channel.</li>
<li>'''MixL (ID 13)''': Interpolates only the '''L''' channel.</li>
<li>'''PalTransitionRGB (ID 14)''': Interpolates an entire palette into another using '''RGB''' channels.</li>
<li>'''PalTransitionHSL (ID 15)''': Interpolates an entire palette into another using '''HSL''' channels.</li>
<li>'''PalFunctionRGB (ID 16)''': Applies a linear transformation over the '''RGB''' channels:

* R = R11*R + R12*G + R13*B
* G = R21*R + R22*G + R23*B
* B = R31*R + R32*G + R33*B

Where:

* RXY are ratios
* R corresponds to the red channel
* G corresponds to the green channel
* B corresponds to the blue channel

'''Note:''' This effect is not implemented yet.
</li>

<li>'''PalFunctionHSL (ID 17)''': Applies a linear transformation over the '''HSL''' channels:

* H = R11*H + R12*S + R13*L
* S = R21*H + R22*S + R23*L
* L = R31*H + R32*S + R33*L

Where:

* '''RXY''' are ratios.
* '''H''' corresponds to hue.
* '''S''' corresponds to saturation.
* '''L''' corresponds to lightness.

'''Note:''' This effect is not implemented yet.
</li>
</ul>

==== File Format ====

Palette effects use a JSON-based format:

<pre>
{
"Name": "BowserCharge",
"Effects": []
}
</pre>

Where:

* '''Name''': Corresponds to the effect name.
* '''Effects''': Contains the list of effects used and may use either of the 2 effect formats, simple or generator.

===== Simple Format =====

The simple format defines a single effect:

<pre>
{
"Channel1": 31,
"Channel2": 0,
"Channel3": 0,
"Ratio1": 64,
"Ratio2": 64,
"Ratio3": 64,
"EffectType": 0
}
</pre>

Where:

<ul>
<li>'''Channel1''', '''Channel2''', '''Channel3''' correspond to the main channel values.
<ul>
<li>For '''RGB''' effects:
<ul>
<li>1 = R</li>
<li>2 = G</li>
<li>3 = B</li>
</ul>
<li>For '''HSL''' effects:
<ul>
<li>1 = H</li>
<li>2 = S</li>
<li>3 = L</li>
</ul>
</ul>
</li>
<li>The '''Ratio''' values represent the interpolation ratios used by their respective channels.</li>
<li>'''EffectType''' corresponds to the effect ID being used.</li>
</ul>

===== Generator Format =====

There is also a format used to automatically generate multiple interpolated effects:

<pre>
{
"StartC1": 31,
"StartC2": 0,
"StartC3": 0,
"StartR1": 64,
"StartR2": 64,
"StartR3": 64,

"EndC1": 0,
"EndC2": 0,
"EndC3": 0,
"EndR1": 64,
"EndR2": 64,
"EndR3": 64,

"Steps": 5,
"EffectType": 0
}
</pre>

This format allows defining:

* An initial state.
* A final state.
* The number of intermediate steps.

Dynamic Xtreme automatically generates all effects required to perform the transition between both states.

==== Value Ranges ====

* Channel values ('''Channel''') use ranges between '''0''' and '''31'''.
* Ratio values ('''Ratio''') use ranges between '''0''' and '''127'''.

== DynamicInfo ==

'''DynamicInfo''' files are stored inside the '''DynamicInfos''' folder and use the '''*.dynamicinfo''' extension.

These files have 2 main purposes:

* Include dynamic resources into the ROM.
* Define which graphics correspond to dynamic sprites and how each pose should be loaded.

The basic structure of a `DynamicInfo` file is the following:

<pre>
PosesGraphics:
MyGraphics.bin
AnotherGraphics.bin

Palettes:
MyPal.bin
AnotherPal.bin

Resources:
MyResource.bin
AnotherResource.bin
</pre>

These sections work as lists of dynamic resources that will be included by Dynamic Xtreme.

* '''PosesGraphics''' contains graphics files for dynamic sprites. These must use the '''*.bin''' format.
* '''Palettes''' contains color palette files. Currently they use the '''*.bin''' format, although support for '''*.pal''' files is planned for the future.
* '''Resources''' allows including arbitrary dynamic resources and has no specific format restrictions.

In the case of PosesGraphics, when multiple graphics files are used, all of them are internally combined into a single large graphics block following the order in which they were declared.

Later, each pose is cropped from that combined data and stored inside the ROM in the most convenient way possible for the dynamic system.

Because of this, there is no important practical difference between:

* Using a single large graphics file.
* Using multiple smaller graphics files.

Both approaches will produce the same internal result inside Dynamic Xtreme.

In addition to these resource lists, '''DynamicInfo''' files also contain the definition of the dynamic poses used by the sprite.

The way these poses are defined depends on the format used by the resource:

* Current format ('''NumberOf16x16TilesPerPose''').
* Legacy format ('''PosesChunksSizes''').

=== Current Format ===

The modern format was designed to simplify the creation and maintenance of dynamic sprites.

In this format, the user only needs to specify how many 16x16 tiles each pose uses. Dynamic Xtreme automatically processes the graphics and internally converts them into the optimized format used by the dynamic system.

Example:

<pre>
NumberOf16x16TilesPerPose:
.Pose0 5
.Pose1 7h
.Pose2..6 4
</pre>

In this example:

* Pose0 uses 5 16x16 tiles.
* Pose1 uses 7 16x16 tiles and additionally one top half (16x8).
* Pose2 through Pose6 use 4 16x16 tiles.

The format also allows the use of modifiers to represent partial tiles:

* '''q''': Top-left 8x8 tile.
* '''h''': Top half (16x8).
* '''q3''': Top half + bottom-left tile (16x8 + 8x8).

This makes it possible to include a 16x16 tile containing partial graphics. These partial tiles do not support every possible combination, since many of them are not practical for the system. Only the most common and useful configurations are considered.

Internally, Dynamic Xtreme automatically transforms this format into the legacy format, since that format is optimized for performing DMA transfers to VRAM more efficiently.

=== Legacy Format ===

The legacy format uses a table called PosesChunksSizes, which manually defines how dynamic graphics should be internally organized.

Example:

<pre>
PosesChunksSizes:
Pose0_PoseChunksSizes:
db $02,$02
Pose1_PoseChunksSizes:
db $02,$02
</pre>

Each pose contains a subtable composed of 2 values.

The idea behind these values is to represent how many DMA routines would be required to transfer the pose graphics into VRAM under ideal conditions, meaning assuming the sprite is aligned at the beginning of the VRAM sprite section. In practice, ideal conditions usually require 1 or 2 DMA routines.

Most of the time, the first DMA routine transfers a larger amount of data than the second one.

Each of the 2 values represents the amount of 8x8 tiles transferred by each DMA routine.

For example:

<pre>
db $02,$02
</pre>

Means:

* the first DMA routine transfers 2 8x8 tiles
* the second DMA routine transfers another 2 8x8 tiles

In special cases where the sprite uses an amount of 16x16 tiles that perfectly fills rows inside VRAM (for example multiples of 8 16x16 tiles), it is possible to perform the entire transfer using a single DMA routine. In those cases, the second value is defined as $00.

This format was replaced by the current format because it was complex and unintuitive for most users. Currently, using NumberOf16x16TilesPerPose is recommended, although the legacy format remains fully supported and still provides more flexibility for advanced use cases.

== DrawInfo ==

DrawInfo files are stored inside the DrawInfos folder and use the '''"*.dynamicinfo"''' extension and contain all the information required to draw poses on screen.

Internally, Dynamic Xtreme collects this information and automatically generates optimized graphic routines. Each graphic routine groups multiple poses that share similar characteristics and is specifically optimized for that type of pose. This allows not only a global pose rendering system, but also a highly efficient system in a large number of cases.

To understand how DrawInfo files work, it is necessary to understand at a high level how SNES OAM works.

OAM is a special memory used to store sprite information. In the case of SMW, it works using 8x8 and 16x16 tiles.

Each tile contains the following attributes:

<ul>
<li>'''TileCode''': sometimes simply called Tile, corresponds to an internal ID used by the console to indicate which specific VRAM graphic should be used.
<br/>
'''Note:''' When working with dynamic sprites, TileCodes must be defined assuming the sprite was loaded at the beginning of the sprite section in VRAM.
<br/>
Dynamic Xtreme automatically adjusts these values internally depending on the actual position where the pose was loaded into VRAM during runtime.
</li>

<li>'''Properties''': corresponds to a byte containing special tile properties. This byte uses the following format:
* '''YXCCPPPT'''
Where:
<ul>
<li>'''Y''': indicates whether the tile is vertically flipped.</li>
<li>'''X''': indicates whether the tile is horizontally flipped.</li>
<li>'''CC''': tile priority relative to layers (higher value = higher priority).</li>
<li>'''PPP''': sprite palette used (000 => palette 8, 001 => palette 9, ..., 111 => palette F).</li>
<li>'''T''': indicates which graphics page to use (0 => SP12, 1 => SP34).</li>
</ul>

'''Note:''' It is possible to define global Properties for all tiles of a pose or sprite. Because of this, the most important properties inside DrawInfo files are usually Y, X, and T, while CC and PPP are generally configured from the code that calls the system.

In the specific case of dynamic sprites, the T property usually does not need to be manually configured, since Dynamic Xtreme automatically detects which graphics page the pose belongs to and configures this bit automatically.</li>

<li>'''Size''': defines the tile size:
<ul>
<li>$00: small tile (8x8).</li>
<li>$02: large tile (16x16).</li>
</ul>
</li>
</ul>

Additionally, each tile contains:

* X displacement (X Offset)
* Y displacement (Y Offset)

These values allow the tile to be moved relative to the sprite's base position.

Currently, Dynamic Xtreme supports 2 DrawInfo formats: the current format and the legacy format.

=== Current Format ===

The current DrawInfo format was designed to significantly improve readability and ease of maintenance for drawing files.

Unlike the legacy format, this system allows:

* Grouping multiple poses.
* Grouping tile ranges.
* Using per-tile default values.
* Omitting unnecessary subtables.
* Defining individual values or complete value lists.

Example:

<pre>
MyPose_Pose0..4:
.NumberOfTiles: 5
.TileCode2: $02
.TileCode3..4: $04
.Properties: $00,$40,$00,$00,$40
.XOffsets: $00,$10,$F8,$08,$18
.XPivot: $08
.YOffset2..4: $10
.YPivot: $10
.Size0..4: $02
</pre>

In this example:

* '''MyPose_Pose0..4''': Defines shared information for poses 0 through 4 using the name "MyPose".
* '''.NumberOfTiles''': Defines that each pose uses 5 tiles.
* '''.TileCode2''': Modifies the '''TileCode''' only for tile 2.
* '''.TileCode3..4''': Modifies the '''TileCode''' for tiles 3 and 4.
* '''.Properties''': Defines an individual '''Properties''' list for each tile.
* '''.XOffsets''': Defines an individual '''XOffset''' for each tile.
* '''.YOffset2..4''': Modifies the '''YOffset''' only for tiles 2 through 4.
* '''.Size0..4''': Defines the size of tiles 0 through 4.

Directives used in singular form allow modifying a specific tile or a specific range of tiles.

Examples:

<pre>
.TileCode2: $02
.TileCode3..4: $04
.YOffset1..3: $10
</pre>

In these cases:

* '''.TileCode2:''': Modifies only tile 2
* '''.TileCode3..4''': Modifies only tiles 3 and 4
* '''.YOffset1..3''': Modifies the YOffset of tiles 1 through 3

On the other hand, plural directives allow explicitly defining a complete list of values for all tiles in the pose.

Examples:

<pre>
.Properties: $00,$40,$00,$00,$40
.XOffsets: $00,$10,$F8,$08,$18
</pre>

In these cases:

* '''.Properties''': defines a complete Properties list.
* '''.XOffsets''': defines a complete XOffsets list.

This allows combining simple general configurations with specific modifications only where needed.

When a value is not explicitly defined, Dynamic Xtreme automatically uses default values:

* '''TileCode''': $00
* '''Property''': $00
* '''XOffset''': $00
* '''YOffset''': $00
* '''Size''': $02

Unlike the legacy format, these default values work individually per tile, allowing only the necessary information to be omitted without affecting the rest of the pose.

The '''XPivot''' and '''YPivot''' values are used as rotation axes for performing horizontal or vertical flips on a pose. These values allow tile positions to be automatically recalculated when using the X or Y properties.

If '''XPivot''' is not defined, the pose will not be considered compatible with horizontal flipping. Likewise, if '''YPivot''' is not defined, the pose will not be considered compatible with vertical flipping.

This allows Dynamic Xtreme to generate more optimized graphic routines when these features are not needed, while also slightly reducing ROM space usage.

It is also possible to use:

<pre>
.IsStatic
</pre>

This indicates that the defined poses should be treated as static poses instead of dynamic ones. By default, all poses are treated as dynamic.

The legacy DrawInfo format remains fully supported. The modern format mainly exists to simplify the writing, reading, and maintenance of DrawInfo files while still maintaining a high level of flexibility.

=== Legacy Format ===

The legacy DrawInfo format uses multiple separate tables to define each attribute of the tiles used by a pose.

This format was designed following a structure similar to the one normally used when writing manual graphic routines for SNES sprites. The original idea was that people already familiar with developing sprites this way could work with DrawInfo using an organization that felt familiar and relatively intuitive for that traditional workflow.

Example:

<pre>
Dynamic:
true

Tiles:
MyPose0_Tiles:
db $00
MyPose1_Tiles:
db $00

Properties:
MyPose0_Properties:
db $00
MyPose1_Properties:
db $00

XDisplacements:
MyPose0_XDisp:
db $00
MyPose1_XDisp:
db $00
MyPose0_XDispFlip:
db $00
MyPose1_XDispFlip:
db $00

YDisplacements:
MyPose0_YDisp:
db $01
MyPose1_YDisp:
db $01
MyPose0_YDispFlip:
db $FF
MyPose1_YDispFlip:
db $FF

Sizes:
MyPose0_Sizes:
db $02
MyPose1_Sizes:
db $02
</pre>

In this format:

* Each attribute uses an independent section.
* Each pose requires a separate subtable.
* All values must be manually written.
* Tile ranges and pose grouping do not exist.

The main tables correspond to:

* '''Tiles''': TileCodes
* '''Properties''': OAM Properties
* '''XDisplacements''': Horizontal displacements
* '''YDisplacements''': Vertical displacements
* '''Sizes''': Tile sizes (8x8 or 16x16)

In the case of XDisplacements and YDisplacements, it is also possible to define flipped versions:

* XDispFlip
* YDispFlip

These tables allow manually specifying the offsets used when a pose is drawn using horizontal or vertical flip.

The directive:

<pre>
Dynamic: true
</pre>

Indicates that the poses should be treated as dynamic poses. If defined as false, the poses will be considered static.

Just like in the modern format, automatic default values also exist. If a table does not exist, Dynamic Xtreme will automatically assume the following values:

* '''TileCode''': $00
* '''Property''': $00
* '''XOffset''': $00
* '''YOffset''': $00
* '''Size''': $02

This format remains fully compatible with Dynamic Xtreme, although the modern format is currently recommended since it is considerably more readable, maintainable, and easier to edit.

es/Dynamic Xtreme files and formats

Anonimzwx — Mon, 18 May 2026 18:27:30 GMT

Created page with "{{Select Language|Dynamic_Xtreme_files_and_formats}} Dynamic Xtreme utiliza un sistema de archivos propio y bien estructurado que permite al usuario tener un control preciso y flexible sobre los recursos, efectos y datos que se usan durante la ejecución del juego. Esta página documenta los diferentes tipos de archivos que maneja la herramienta, cómo funcionan, su propósito y los formatos específicos que utilizan (tanto los actuales como los legacy). Entender esta..."

New page

{{Select Language|Dynamic_Xtreme_files_and_formats}}

Dynamic Xtreme utiliza un sistema de archivos propio y bien estructurado que permite al usuario tener un control preciso y flexible sobre los recursos, efectos y datos que se usan durante la ejecución del juego.

Esta página documenta los diferentes tipos de archivos que maneja la herramienta, cómo funcionan, su propósito y los formatos específicos que utilizan (tanto los actuales como los legacy). Entender esta estructura es fundamental para aprovechar al máximo las capacidades de Dynamic Xtreme.

Muchos de los formatos legacy presentes en Dynamic Xtreme provienen originalmente de Dynamic X, la versión antigua sobre la cual evolucionó el proyecto. Estos formatos continúan siendo totalmente compatibles con el objetivo de mantener soporte para una gran cantidad de recursos ya existentes desarrollados para Dynamic X.

A continuación se detallan los principales tipos de archivos y sus formatos:

== Tipos de Archivos ==

Dynamic Xtreme utiliza varios tipos de archivos especializados. A continuación se describen los principales:

* '''Recursos Dinámicos''': Son recursos que se guardan en el ROM de forma descomprimida. Normalmente se usan para sprites dinámicos, cambios de gráficos, cambios de tilemaps o cambios de paletas.
* '''Palette Effects (*.paleffect):''' Son archivos utilizados para registrar efectos de paletas de colores.
* '''Dynamic Info (*.dynamicinfo):''' Son archivos que se usan para incluir recursos dinámicos en el ROM y también generar la data relevante para los sprites dinámicos.
* '''Draw Info (*.drawinfo):''' Son archivos utilizados para generar las poses (cuadros de animación) para los sprites y luego poder dibujarlas en pantalla.

== Recursos Dinámicos ==

Los Recursos Dinámicos son uno de los sistemas centrales de Dynamic Xtreme. Estos recursos se almacenan en el ROM de forma descomprimida, lo que permite cargarlos y utilizarlos rápidamente durante la ejecución del juego.

=== ¿Cómo funciona el sistema? ===

Dynamic Xtreme recopila todos los recursos dinámicos, los organiza en paquetes de máximo 1 bank (32 O 64 KB) y los inserta automáticamente en el ROM. Si el ROM tiene hi-banks disponibles, el tool prioriza estos bancos para la inserción, mejorando la organización del espacio.

No existe una limitación estricta sobre el tipo de datos que se pueden insertar, aunque la mayoría de los archivos suelen ser de tipo '''"*.bin"'''.

=== Usos principales ===

Los recursos dinámicos se utilizan comúnmente para:
* '''Gráficos:''' Gráficos de sprites dinámicos o reemplazos gráficos en tiempo real.
* '''Tilemaps:''' Reemplazar tiles de los diferentes layers del nivel.
* '''Paletas de colores:''' Reemplazar paletas completas o asignar paletas específicas a sprites dinámicos.
* '''Otros''': Cualquier tipo de información que se desee almacenar en el ROM, como muestras de audio .brr, tablas de datos, etc.

Esto hace que el sistema sea extremadamente flexible, permitiendo no solo usos gráficos sino también cualquier otro tipo de dato que el usuario necesite tener disponible en el ROM de forma rápida.

=== Archivos de Paletas de colores ===

Actualmente, la mejor forma de guardar archivos de paletas de colores es utilizando archivos binarios ('''*.bin''') donde cada color ocupa 2 bytes siguiendo el formato de color utilizado por el SNES. Existen herramientas que facilitan este proceso, como [https://www.smwcentral.net/?p=section&a=details&id=24827 Pal2Bin].

Para entender esto, es importante considerar que el formato de color del SNES es BGR555. Esto significa que cada color se almacena utilizando 5 bits para azul, 5 bits para verde y 5 bits para rojo.

Conceptualmente, los bits se organizan así:

<code>-BBBBB GGGGG RRRRR</code>

Sin embargo, debido al endian utilizado por el SNES, los bytes deben almacenarse invertidos en memoria, por lo que internamente terminan organizados así:

<code>GGG RRRRR -BBBBB GG</code>

Debido a que este formato puede resultar confuso para usuarios no familiarizados con hardware del SNES, a futuro se planea incorporar soporte mejorado para archivos '''*.pal''', los cuales son mucho más conocidos y utilizados en herramientas gráficas modernas.

En el caso de las paletas utilizadas por sprites dinámicos, estas deben contener un máximo de 15 colores. Esto significa que únicamente deben incluirse los colores 1 al 15 de la paleta correspondiente, ya que el color 0 es utilizado como transparencia.

=== Gráficos para Sprites Dinámicos ===

Los gráficos utilizados por los sprites dinámicos en Dynamic Xtreme deben seguir ciertas reglas de organización dependiendo del formato utilizado por el recurso.

Actualmente existen dos formatos soportados por el sistema:

* Formato actual
* Formato legacy

El formato moderno fue diseñado para simplificar la creación y mantenimiento de recursos dinámicos, permitiendo trabajar con layouts mucho más fáciles de entender y organizar.

Por otro lado, el formato legacy corresponde al sistema original basado en PosesChunksSizes, el cual ofrece un control más avanzado y flexible sobre la organización interna de gráficos en VRAM, pero también requiere una comprensión más profunda del funcionamiento interno del sistema dinámico.

==== Formato actual ====

El formato moderno se basa simplemente en organizar los gráficos como tiles continuos de 16x16 en VRAM. Este formato fue diseñado para simplificar considerablemente el proceso de creación de sprites dinámicos.

Ejemplo:

La imagen del ejemplo muestra un sprite de 32x32 (el cual utiliza 4 tiles de 16x16) siendo organizado dentro del archivo de gráficos.

[[File:imagen 2026-05-17 221817296.png|thumb]]

Con este sistema, el usuario únicamente necesita preocuparse por organizar visualmente los tiles en el orden correcto de cada pose.

Internamente, Dynamic Xtreme se encarga de leer estos gráficos y convertirlos automáticamente al formato legacy, el cual es más sencillo de manejar por el hardware del SNES. Además, el sistema elimina automáticamente los espacios vacíos generados por tiles parciales declarados mediante modificadores como q, th, bh, lh o q3.

==== Formato Legacy ====

El formato legacy utiliza un sistema de organización gráfica optimizado para facilitar el manejo interno de gráficos dinámicos en el hardware del SNES.

A diferencia del formato moderno, en este caso el usuario debe organizar manualmente los gráficos siguiendo el layout requerido por el sistema.

Cuando una pose utiliza 7 tiles de 16x16 o menos, los tiles se organizan primero en una fila horizontal continua. Luego, cada tile de 16x16 debe dividirse en dos mitades de 16x8:

* mitad superior.
* mitad inferior.

Después de esto:

* primero se colocan todas las mitades superiores de forma continua.
* y luego todas las mitades inferiores inmediatamente después.

Ejemplo:

Dada una pose de 4 tiles de 16x16, se tienen los siguientes tiles:

<code>t1 t2 t3 t4</code>

Se tendria que organizar de la siguiente manera:

<code>t1th t2th t3th t4th t1bh t2bh t3bh t4bh</code>

Donde:

* tx corresponde a un tile de 16x16.
* txth corresponde a la mitad superior (top half) de un tile de 16x16.
* txbh corresponde a la mitad inferior (bottom half) de un tile de 16x16.

Cuando una pose utiliza 8 tiles de 16x16 o más, primero deben separarse todas las filas completas de 8 tiles. Estas filas completas pueden almacenarse directamente sin reorganización adicional.

Luego, los tiles sobrantes que no completen una fila de 8 tiles deben organizarse utilizando el mismo sistema explicado anteriormente para poses de 7 tiles o menos.

==== Consideraciones sobre overlap de tiles ====

En sprites estáticos es común utilizar overlap entre tiles para ahorrar espacio gráfico. Por ejemplo, en un sprite de 24x24 normalmente pueden utilizarse 3 tiles de 16x16 y 1 tile de 8x8, aprovechando overlap entre los tiles de 16x16.

Sin embargo, este tipo de organización no es válida en sprites dinámicos.

Debido a que los gráficos dinámicos pueden ser cargados de maneras impredecibles en VRAM, los tiles no pueden depender visualmente unos de otros mediante overlap. Cada tile debe contener únicamente los gráficos correspondientes a su propia área.

Por ejemplo, para un sprite de 24x24, en lugar de utilizar overlap entre tiles de 16x16, se recomienda utilizar:

* 2 tiles de 16x16 en diagonal con una zona de 8x8 igual entre ambos.
* 2 tiles de 8x8 organizados dentro de un espacio equivalente a 1 tile de 16x16.

El overlap entre tiles no está permitido en sprites dinámicos, aunque sí puede haber redundancia entre 2 tiles distintos y estos pueden organizarse estratégicamente para ahorrar tiles de OAM. Además, sigue siendo posible ahorrar espacio mediante el uso estratégico de tiles de 8x8.

== Efectos de Paletas ==

Los archivos de Efectos de paletas se almacenan dentro de la carpeta PaletteEffects y utilizan la extensión '''"*.paleffect"'''.

Los efectos de paleta permiten realizar modificaciones de colores en tiempo real sobre las paletas utilizadas por el juego. Estos efectos pueden ser utilizados por el sistema global de efectos de paleta de Dynamic Xtreme.

Internamente, estos sistemas funcionan modificando los canales '''RGB''' o '''HSL''' de los colores de la paleta para producir distintos efectos visuales.

Algunos usos comunes incluyen:

* Transiciones de día a noche.
* Flashes rojos para indicar peligro.
* Efectos cyan intermitentes para objetos a punto de explotar.
* Cambios de tinte para efectos tipo discoteca.
* Transiciones suaves entre estados visuales.
* Efectos de iluminación o ambientación.

El sistema permite una gran cantidad de combinaciones y efectos distintos.

=== Tipos de efectos ===

Actualmente existen los siguientes efectos:
<ul>
<li>'''MixRGB (ID 0)''': Interpola los canales '''RGB''' con un color base.</li>
<li>'''MixHSL (ID 1)''': Interpola los canales '''HSL''' con un color base.</li>
<li>'''MixRG (ID 2)''': Interpola únicamente '''R''' y '''G'''.</li>
<li>'''MixGB (ID 3)''': Interpola únicamente '''G''' y '''B'''.</li>
<li>'''MixRB (ID 4)''': Interpola únicamente '''R''' y '''B'''.</li>
<li>'''MixHS (ID 5)''': Interpola únicamente '''H''' y '''S'''.</li>
<li>'''MixSL (ID 6)''': Interpola únicamente '''S''' y '''L'''.</li>
<li>'''MixHL (ID 7)''': Interpola únicamente '''H''' y '''L'''.</li>
<li>'''MixR (ID 8)''': Interpola únicamente el canal '''R'''.</li>
<li>'''MixG (ID 9)''': Interpola únicamente el canal '''G'''.</li>
<li>'''MixB (ID 10)''': Interpola únicamente el canal '''B'''.</li>
<li>'''MixH (ID 11)''': Interpola únicamente el canal '''H'''.</li>
<li>'''MixS (ID 12)''': Interpola únicamente el canal '''S'''.</li>
<li>'''MixL (ID 13)''': Interpola únicamente el canal '''L'''.</li>
<li>'''PalTransitionRGB (ID 14)''': Interpola una paleta completa hacia otra utilizando canales '''RGB'''.</li>
<li>'''PalTransitionHSL (ID 15)''': Interpola una paleta completa hacia otra utilizando canales '''HSL'''.</li>
<li>'''PalFunctionRGB (ID 16)''': Aplica una transformación lineal sobre los canales '''RGB''':

* R = R11*R + R12*G + R13*B
* G = R21*R + R22*G + R23*B
* B = R31*R + R32*G + R33*B

Donde:

* RXY Son ratios
* R Corresponde al canal rojo
* G Corresponde al canal verde
* B Corresponde al canal azul

'''Nota:''' Este efecto aún no se encuentra implementado.
</li>

<li>'''PalFunctionHSL (ID 17)''': Aplica una transformación lineal sobre los canales '''HSL''':

* H = R11*H + R12*S + R13*L
* S = R21*H + R22*S + R23*L
* L = R31*H + R32*S + R33*L

Donde:

* '''RXY''' Son ratios.
* '''H''' Corresponde al tinte ('''Hue''').
* '''S''' Corresponde a la saturación.
* '''L''' Corresponde al brillo ('''Lightness''').

'''Nota:''' Este efecto aún no se encuentra implementado.
</li>
</ul>

==== Formato de archivos ====

Los efectos de paleta utilizan un formato basado en JSON:

<pre>
{
"Name": "BowserCharge",
"Effects": []
}
</pre>

Donde:

* '''Name''': Corresponde al nombre del efecto
* '''Effects''': Contiene la lista de efectos utilizados y pueden estar en cualquiera de los 2 formatos de efecto, ya sea el simple o el generador.

===== Formato simple =====

El formato simple define un único efecto:

<pre>
{
"Channel1": 31,
"Channel2": 0,
"Channel3": 0,
"Ratio1": 64,
"Ratio2": 64,
"Ratio3": 64,
"EffectType": 0
}
</pre>

Donde:

<ul>
<li>'''Channel1''', '''Channel2''', '''Channel3''' corresponden a los valores de canales principales
<ul>
<li>En efectos '''RGB''':
<ul>
<li>1 = R</li>
<li>2 = G</li>
<li>3 = B</li>
</ul>
<li>En efectos '''HSL''':
<ul>
<li>1 = H</li>
<li>2 = S</li>
<li>3 = L</li>
</ul>
</ul>
</li>
<li>Los valores '''Ratio''' representan las proporciones utilizadas durante la interpolación usados por su canal respectivo.</li>
<li>'''EffectType''' corresponde al ID del efecto utilizado.</li>
</ul>

===== Formato generador =====

También existe un formato utilizado para generar automáticamente múltiples efectos interpolados:

<pre>
{
"StartC1": 31,
"StartC2": 0,
"StartC3": 0,
"StartR1": 64,
"StartR2": 64,
"StartR3": 64,

"EndC1": 0,
"EndC2": 0,
"EndC3": 0,
"EndR1": 64,
"EndR2": 64,
"EndR3": 64,

"Steps": 5,
"EffectType": 0
}
</pre>

Este formato permite definir:

* Un estado inicial.
* Un estado final.
* La cantidad de pasos intermedios.

Dynamic Xtreme genera automáticamente todos los efectos necesarios para realizar la transición entre ambos estados.

==== Rangos de valores ====

* Los valores de canales ('''Channel''') utilizan rangos entre '''0''' y '''31'''.
* Los valores de ratios ('''Ratio''') utilizan rangos entre '''0''' y '''127'''.

== DynamicInfo ==

Los archivos '''DynamicInfo''' se almacenan dentro de la carpeta '''DynamicInfos''' y utilizan la extensión '''*.dynamicinfo'''.

Estos archivos tienen 2 funciones principales:

* Incluir recursos dinámicos dentro del ROM.
* Definir qué gráficos corresponden a sprites dinámicos y cómo debe cargarse cada pose.

La estructura básica de un archivo `DynamicInfo` es la siguiente:

<pre>
PosesGraphics:
MyGraphics.bin
AnotherGraphics.bin

Palettes:
MyPal.bin
AnotherPal.bin

Resources:
MyResource.bin
AnotherResource.bin
</pre>

Estas secciones funcionan como listas de recursos dinámicos que serán incluidos por Dynamic Xtreme.

* '''PosesGraphics''' contiene archivos gráficos para sprites dinámicos. Estos deben utilizar formato '''*.bin'''.
* '''Palettes''' contiene archivos de paletas de colores. Actualmente utilizan formato '''*.bin''', aunque a futuro se planea agregar soporte para archivos '''*.pal'''.
* '''Resources''' permite incluir recursos dinámicos arbitrarios y no posee restricciones específicas de formato.

En el caso de PosesGraphics, cuando se utilizan múltiples archivos gráficos, todos ellos son combinados internamente en un único gran bloque de gráficos siguiendo el orden en el que fueron declarados.

Posteriormente, cada pose es recortada desde esa data combinada y almacenada dentro del ROM de la forma más conveniente posible para el sistema dinámico.

Debido a esto, no existe una diferencia práctica importante entre:

* Utilizar un único archivo grande de gráficos.
* Utilizar múltiples archivos pequeños separados.

Ambos enfoques producirán el mismo resultado interno dentro de Dynamic Xtreme.

Además de estas listas de recursos, los archivos '''DynamicInfo''' también contienen la definición de las poses dinámicas utilizadas por el sprite.

La forma en la que estas poses son definidas depende del formato utilizado por el recurso:

* Formato actual ('''NumberOf16x16TilesPerPose''').
* Formato legacy ('''PosesChunksSizes''').

=== Formato Actual ===

El formato moderno fue diseñado para simplificar la creación y mantenimiento de sprites dinámicos.

En este formato, el usuario únicamente necesita indicar cuántos tiles de 16x16 utiliza cada pose. Dynamic Xtreme se encarga automáticamente de procesar los gráficos y convertirlos internamente al formato optimizado utilizado por el sistema dinámico.

Ejemplo:

<pre>
NumberOf16x16TilesPerPose:
.Pose0 5
.Pose1 7h
.Pose2..6 4
</pre>

En este ejemplo:

* Pose0 utiliza 5 tiles de 16x16.
* Pose1 utiliza 7 tiles de 16x16 y adicionalmente una mitad superior (16x8).
* Pose2 hasta Pose6 utilizan 4 tiles de 16x16.

El formato también permite utilizar modificadores para representar tiles parciales:

* '''q''': Tile 8x8 superior izquierdo.
* '''h''': Mitad superior (16x8).
* '''q3''': Mitad superior + tile inferior izquierdo (16x8 + 8x8).

De este modo es posible incluir un tile de 16x16 que contenga gráficos de manera parcial. Estos tiles parciales no permiten todas las combinaciones posibles, debido a que muchas de ellas no son prácticas para el sistema. Únicamente se consideran las configuraciones más comunes y útiles.

Internamente, Dynamic Xtreme transforma automáticamente este formato al formato legacy, ya que dicho formato se encuentra optimizado para realizar transferencias DMA hacia VRAM de manera más eficiente.

=== Formato Legacy ===

El formato legacy utiliza una tabla llamada PosesChunksSizes, la cual define manualmente cómo deben organizarse los gráficos dinámicos internamente.

Ejemplo:

<pre>
PosesChunksSizes:
Pose0_PoseChunksSizes:
db $02,$02
Pose1_PoseChunksSizes:
db $02,$02
</pre>

Cada pose posee una subtabla compuesta por 2 valores.

La idea detrás de estos valores es representar cuántas rutinas DMA serían necesarias para transferir los gráficos de la pose hacia VRAM en condiciones ideales, es decir, asumiendo que el sprite se encuentra alineado al inicio de la sección de sprites de VRAM. En la práctica, en condiciones ideales se necesita 1 o 2 rutinas DMA.

La mayoría de las veces, la primera rutina DMA transfiere una cantidad mayor de datos que la segunda.

Cada uno de los 2 valores representa la cantidad de tiles de 8x8 transferidos por cada rutina DMA.

Por ejemplo:

<pre>
db $02,$02
</pre>

Significa:

* la primera rutina DMA transfiere 2 tiles de 8x8
* la segunda rutina DMA transfiere otros 2 tiles de 8x8

En casos especiales donde el sprite utiliza una cantidad de tiles de 16x16 que completa filas exactas dentro de VRAM (por ejemplo múltiplos de 8 tiles de 16x16), es posible realizar toda la transferencia utilizando una sola rutina DMA. En esos casos, el segundo valor se define como $00.

Este formato fue reemplazado por el formato actual debido a que resultaba complejo y poco intuitivo para la mayoría de usuarios. Actualmente se recomienda utilizar NumberOf16x16TilesPerPose, aunque el legacy continúa siendo totalmente compatible y sigue ofreciendo mayor flexibilidad para casos avanzados.

== DrawInfo ==

Los archivos DrawInfo se almacenan dentro de la carpeta DrawInfos y utilizan la extensión '''"*.dynamicinfo"''' y contienen la información necesaria para dibujar poses en pantalla.

Internamente, Dynamic Xtreme recopila esta información y genera rutinas gráficas optimizadas automáticamente. Cada rutina gráfica agrupa múltiples poses que comparten características similares y es optimizada específicamente para ese tipo de poses. Esto permite no solo un sistema global de renderizado de poses, sino también un sistema bastante eficiente en una gran cantidad de casos.

Para comprender cómo funcionan los archivos DrawInfo, es necesario entender a grandes rasgos cómo funciona la OAM del SNES.

La OAM es una memoria especial utilizada para almacenar información de sprites. En el caso del SMW, este trabaja utilizando tiles de 8x8 y 16x16.

Cada tile posee los siguientes atributos:

<ul>
<li>'''TileCode''': a veces llamado simplemente Tile, corresponde a un ID interno utilizado por la consola para indicar qué gráfico específico de VRAM debe utilizarse.
<br/>
'''Nota:''' Cuando se trabaja con sprites dinámicos, los TileCodes deben definirse asumiendo que el sprite fue cargado al inicio de la sección de sprites de VRAM.
<br/>
Dynamic Xtreme se encarga automáticamente de ajustar internamente estos valores dependiendo de la posición real donde la pose haya sido cargada en VRAM durante la ejecución.
</li>
<li>'''Properties''': corresponde a un byte con propiedades especiales del tile. Este byte utiliza el siguiente formato:
* '''YXCCPPPT'''
Donde:
<ul>
<li>'''Y''': indica si el tile se encuentra flippeado verticalmente.</li>
<li>'''X''': indica si el tile se encuentra flippeado horizontalmente.</li>
<li>'''CC''': prioridad del tile respecto a los layers (mayor valor = mayor prioridad).</li>
<li>'''PPP''': paleta de sprites utilizada (000 => palette 8, 001 => palette 9, ..., 111 => palette F).</li>
<li>'''T''': indica qué página gráfica utilizar (0 => SP12, 1 => SP34).</li>
</ul>

'''Nota:''' Es posible definir Properties generales para todos los tiles de una pose o sprite. Debido a esto, normalmente las properties más importantes dentro de los archivos DrawInfo son Y, X y T, mientras que las propiedades CC y PPP suelen configurarse desde el código que llama al sistema.

En el caso específico de sprites dinámicos, la property T normalmente no necesita ser configurada manualmente, ya que Dynamic Xtreme detecta automáticamente en qué página gráfica se encuentra la pose y configura este bit de forma automática.</li>
<li>'''Size''': define el tamaño del tile:
<ul>
<li>$00: tile pequeño (8x8).</li>
<li>$02: tile grande (16x16).</li>
</ul>
</li>
</ul>

Además, cada tile posee:

* X displacement (X Offset)
* Y displacement (Y Offset)

Estos valores permiten mover el tile respecto a la posición base del sprite.

Actualmente, Dynamic Xtreme posee 2 formatos DrawInfo: el formato actual y el formato legacy.

=== Formato Actual ===

El formato actual de DrawInfo fue diseñado para mejorar considerablemente la legibilidad y facilidad de mantenimiento de los archivos de dibujo.

A diferencia del formato legacy, este sistema permite:

* Agrupar múltiples poses.
* Agrupar rangos de tiles.
* Utilizar valores por defecto individuales.
* Omitir subtables innecesarias.
* Definir valores individuales o listas completas de valores.

Ejemplo:

<pre>
MyPose_Pose0..4:
.NumberOfTiles: 5
.TileCode2: $02
.TileCode3..4: $04
.Properties: $00,$40,$00,$00,$40
.XOffsets: $00,$10,$F8,$08,$18
.XPivot: $08
.YOffset2..4: $10
.YPivot: $10
.Size0..4: $02
</pre>

En este ejemplo:

* '''MyPose_Pose0..4''': Define información compartida para las poses 0 hasta 4 que comparten el nombre "MyPose".
* '''.NumberOfTiles''': Define que cada pose utiliza 5 tiles.
* '''.TileCode2''': Modifica el '''TileCode''' únicamente del tile 2.
* '''.TileCode3..4''': Modifica el '''TileCode''' de los tiles 3 y 4.
* '''.Properties''': Define una lista individual de '''Properties''' para cada tile.
* '''.XOffsets''': Define un '''XOffset''' individual para cada tile.
* '''.YOffset2..4''': Modifica el '''YOffset''' únicamente de los tiles 2 al 4.
* '''.Size0..4''': Define el tamaño de los tiles 0 al 4.

Las directivas utilizadas en singular permiten modificar un tile específico o un rango de tiles determinado.

Ejemplos:

<pre>
.TileCode2: $02
.TileCode3..4: $04
.YOffset1..3: $10
</pre>

En estos casos:

* '''.TileCode2:''': Modifica únicamente el tile 2
* '''.TileCode3..4''': Modifica únicamente los tiles 3 y 4
* '''.YOffset1..3''': Modifica el YOffset de los tiles 1 al 3

Por otro lado, las directivas en plural permiten definir explícitamente una lista completa de valores para todos los tiles de la pose.

Ejemplos:

<pre>
.Properties: $00,$40,$00,$00,$40
.XOffsets: $00,$10,$F8,$08,$18
</pre>

En estos casos:

* '''.Properties''': define una lista completa de Properties.
* '''.XOffsets''': define una lista completa de XOffsets.

Esto permite combinar configuraciones generales simples con modificaciones específicas únicamente donde sean necesarias.

Cuando un valor no es definido explícitamente, Dynamic Xtreme utiliza automáticamente valores por defecto:

* '''TileCode''': $00
* '''Property''': $00
* '''XOffset''': $00
* '''YOffset''': $00
* '''Size''': $02

A diferencia del formato legacy, estos valores por defecto funcionan de forma individual por tile, permitiendo omitir únicamente la información necesaria sin afectar el resto de la pose.

Los valores '''XPivot''' y '''YPivot''' son utilizados como ejes de rotación para realizar flip horizontal o vertical de una pose. Estos valores permiten recalcular automáticamente las posiciones de los tiles cuando se utilizan las properties X o Y.

Si '''XPivot''' no es definido, la pose no será considerada compatible con flip horizontal. Del mismo modo, si '''YPivot''' no es definido, la pose no será considerada compatible con flip vertical.

Esto permite que Dynamic Xtreme genere rutinas gráficas más optimizadas cuando estas características no son necesarias, además de reducir ligeramente el espacio utilizado dentro del ROM.

También es posible utilizar:

<pre>
.IsStatic
</pre>

Esto indica que las poses definidas deben considerarse poses estáticas en lugar de dinámicas. Por defecto, todas las poses son tratadas como dinámicas.

El formato legacy de DrawInfo continúa siendo totalmente compatible. El formato moderno existe principalmente para simplificar la escritura, lectura y mantenimiento de archivos DrawInfo, manteniendo al mismo tiempo un alto nivel de flexibilidad.

=== Formato Legacy ===

El formato legacy de DrawInfo utiliza múltiples tablas separadas para definir cada atributo de los tiles utilizados por una pose.

Este formato fue diseñado siguiendo una estructura similar a la utilizada normalmente al escribir rutinas gráficas manuales para sprites en SNES. La idea original era que las personas que ya estaban acostumbradas a desarrollar sprites de esta forma pudieran trabajar con DrawInfo utilizando una organización familiar y relativamente intuitiva para ese workflow tradicional.

Ejemplo:

<pre>
Dynamic:
true

Tiles:
MyPose0_Tiles:
db $00
MyPose1_Tiles:
db $00

Properties:
MyPose0_Properties:
db $00
MyPose1_Properties:
db $00

XDisplacements:
MyPose0_XDisp:
db $00
MyPose1_XDisp:
db $00
MyPose0_XDispFlip:
db $00
MyPose1_XDispFlip:
db $00

YDisplacements:
MyPose0_YDisp:
db $01
MyPose1_YDisp:
db $01
MyPose0_YDispFlip:
db $FF
MyPose1_YDispFlip:
db $FF

Sizes:
MyPose0_Sizes:
db $02
MyPose1_Sizes:
db $02
</pre>

En este formato:

* Cada atributo utiliza una sección independiente
* Cada pose requiere una subtabla separada
* Todos los valores deben escribirse manualmente
* No existen rangos de tiles ni agrupación de poses

Las tablas principales corresponden a:

* '''Tiles''': TileCodes
* '''Properties''': Properties de OAM
* '''XDisplacements''': Desplazamientos horizontales
* '''YDisplacements''': Desplazamientos verticales
* '''Sizes''': Tamaño de los tiles (8x8 o 16x16)

En el caso de XDisplacements y YDisplacements, también es posible definir versiones flippeadas:

* XDispFlip
* YDispFlip

Estas tablas permiten especificar manualmente los offsets utilizados cuando una pose es dibujada utilizando flip horizontal o vertical.

La directiva:

<pre>
Dynamic: true
</pre>

Indica que las poses deben ser tratadas como poses dinámicas. Si se define como false, las poses serán consideradas estáticas.

Al igual que en el formato moderno, existen valores por defecto automáticos. Si alguna tabla no existe, Dynamic Xtreme asumirá automáticamente los siguientes valores:

* '''TileCode''': $00
* '''Property''': $00
* '''XOffset''': $00
* '''YOffset''': $00
* '''Size''': $02

Este formato continúa siendo totalmente compatible con Dynamic Xtreme, aunque actualmente se recomienda utilizar el formato moderno debido a que resulta considerablemente más legible, mantenible y fácil de editar.

es/Dynamic Xtreme archivos y formatos

Anonimzwx — Mon, 18 May 2026 18:26:30 GMT

Show changes