es/Dynamic Xtreme archivos y formatos

From SnesLab
Jump to: navigation, search
English Português Español 日本語

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 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í:

-BBBBB GGGGG RRRRR

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

GGG RRRRR -BBBBB GG

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.

imagen 2026-05-17 221817296.png

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:

t1 t2 t3 t4

Se tendria que organizar de la siguiente manera:

t1th t2th t3th t4th t1bh t2bh t3bh t4bh

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:

  • MixRGB (ID 0): Interpola los canales RGB con un color base.
  • MixHSL (ID 1): Interpola los canales HSL con un color base.
  • MixRG (ID 2): Interpola únicamente R y G.
  • MixGB (ID 3): Interpola únicamente G y B.
  • MixRB (ID 4): Interpola únicamente R y B.
  • MixHS (ID 5): Interpola únicamente H y S.
  • MixSL (ID 6): Interpola únicamente S y L.
  • MixHL (ID 7): Interpola únicamente H y L.
  • MixR (ID 8): Interpola únicamente el canal R.
  • MixG (ID 9): Interpola únicamente el canal G.
  • MixB (ID 10): Interpola únicamente el canal B.
  • MixH (ID 11): Interpola únicamente el canal H.
  • MixS (ID 12): Interpola únicamente el canal S.
  • MixL (ID 13): Interpola únicamente el canal L.
  • PalTransitionRGB (ID 14): Interpola una paleta completa hacia otra utilizando canales RGB.
  • PalTransitionHSL (ID 15): Interpola una paleta completa hacia otra utilizando canales HSL.
  • 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.
  • 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.

Formato de archivos

Los efectos de paleta utilizan un formato basado en JSON:

{
  "Name": "BowserCharge",
  "Effects": []
}

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:

{
  "Channel1": 31,
  "Channel2": 0,
  "Channel3": 0,
  "Ratio1": 64,
  "Ratio2": 64,
  "Ratio3": 64,
  "EffectType": 0
}

Donde:

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

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

{
  "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
}

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:

PosesGraphics:
    MyGraphics.bin
    AnotherGraphics.bin

Palettes:
    MyPal.bin
    AnotherPal.bin

Resources:
    MyResource.bin
    AnotherResource.bin

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:

NumberOf16x16TilesPerPose:
.Pose0 5
.Pose1 7h
.Pose2..6 4

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:

PosesChunksSizes:
Pose0_PoseChunksSizes:
    db $02,$02
Pose1_PoseChunksSizes:
    db $02,$02

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:

db $02,$02

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:

  • 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.
    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.
    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.
  • Properties: corresponde a un byte con propiedades especiales del tile. Este byte utiliza el siguiente formato:
    • YXCCPPPT
    Donde:
    • Y: indica si el tile se encuentra flippeado verticalmente.
    • X: indica si el tile se encuentra flippeado horizontalmente.
    • CC: prioridad del tile respecto a los layers (mayor valor = mayor prioridad).
    • PPP: paleta de sprites utilizada (000 => palette 8, 001 => palette 9, ..., 111 => palette F).
    • T: indica qué página gráfica utilizar (0 => SP12, 1 => SP34).

    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.
  • Size: define el tamaño del tile:
    • $00: tile pequeño (8x8).
    • $02: tile grande (16x16).

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:

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

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:

.TileCode2: $02
.TileCode3..4: $04
.YOffset1..3: $10

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:

.Properties: $00,$40,$00,$00,$40
.XOffsets: $00,$10,$F8,$08,$18

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:

.IsStatic

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:

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

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:

Dynamic: true

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.