Dynamic Xtreme

English

Português

Español

日本語

Dynamic Xtreme is a tool for dynamic graphics and palettes in Super Mario World on the SNES, created by Anonimzwx as the successor to Dynamic Z and Dynamic X. Built for the ROM hacking community, it lets graphics and colors change in real time during gameplay. Its dynamic graphics system is flexible and modular, with a focus on performance.

A dynamic sprite loads resources, such as graphics or palettes, in real time during gameplay. A static sprite uses resources that were already loaded when the level began.

Dynamic Xtreme does not break the SNES hardware limits: it works within them, optimizing memory use and transfers to reduce their impact and make them much less noticeable during gameplay.

Its main features include:

• Real-time (on-the-fly) graphics and palette changes.
• The most powerful and flexible dynamic sprite system available for Super Mario World.
• An Advanced Drawing System that can draw any registered frame on screen, with full control over priority, layer, offsets, and properties.
• Advanced palette effects, including real-time changes to hue, saturation, brightness, color blending, smooth transitions, and individual RGB and HSL channels.
• Complete replacement of player graphics and palettes, supporting any Mario size, any number of frames, and any animation style.
• Yoshi graphics replacement using a layout like the original game's.
• Extensive NMI handler optimizations to maximize performance.

Dynamic Xtreme's features are selected during installation so a project can use only what it needs. Some have dependencies, compatibility issues, or restrictions on uninstalling them; check each option's warnings. The tool aims to make complex visual effects easier to implement in Super Mario World hacks while maintaining a high level of compatibility and stability.

Project goals

Dynamic Xtreme's main goal is to make dynamic sprites easier to use and provide full support for real-time graphics, palette, and tilemap changes.

The project aims to make the most of the SNES without requiring advanced knowledge of the console's internal hardware. Traditional dynamic systems are often complex and rely heavily on technical concepts such as VRAM, CGRAM, OAM, and DMA. Dynamic Xtreme hides much of that complexity behind more modern, readable tools and formats that are easier to use.

Another main goal is to maintain high performance even in visually complex situations, allowing extensive use of dynamic graphics, palette effects, and advanced drawing systems without unnecessarily compromising performance.

Dynamic Xtreme also aims to make dynamic sprites as natural and straightforward to use as regular sprites. People focused on level design or content creation should be able to work with dynamic resources without constantly worrying about the system's internal technical limitations.

Features

During installation, you can choose which features to enable. The names in parentheses match the installer options and Settings.json.

Graphics, poses, and palettes

Feature	Purpose
Graphics changes (GraphicsChange)	Allows graphics to be loaded during gameplay. This is the foundation for tile animations, level graphics changes, and dynamic poses.
Palette changes (PalettesChange)	Allows palettes to be loaded and managed during gameplay. Includes automatic palette assignment so sprites can share the same colors without loading them multiple times.
Dynamic poses (DynamicPoses)	Manages VRAM space as a pose cache: reuses loaded poses, shares them between entities, and chooses which ones to replace when more space is needed. This avoids unnecessary loads.
Pose drawing (DrawingSystem)	Draws both dynamic and static poses defined in DrawInfo files. Allows control over their tiles, position, flipping, palette, and drawing priority.
Palette effects (PalettesEffects)	Changes colors using RGB and HSL effects: tinting palettes, adjusting hue, saturation, or lightness, and making transitions between palettes. Effects can apply to individual resources or globally.

Dynamic pose loading and drawing are separate systems: you can draw a static pose without loading its graphics dynamically.

Player and Yoshi

Feature	Purpose
Player features (PlayerFeatures)	Allows player graphics and palettes to be changed and adapts player drawing and pose loading for custom systems. Also allows the player to be hidden or dynamic uploads to be disabled. May conflict with patches that modify player graphics or palettes; read the installer warning before enabling it.
Yoshi features (YoshiFeatures)	Allows Yoshi's graphics to be changed while retaining the original pose layout. Requires PlayerFeatures and shares its compatibility restrictions.

Memory and optimizations

These options reorganize some of the game's work to leave more time for graphics and palette transfers. NMI is the routine that updates the display during the interval between frames.

Feature	Purpose
Free the $7E2000 area (Free7E2000)	On ROMs without SA-1, avoids keeping certain original player, Yoshi, and animation graphics in RAM and reads them from ROM instead. Dynamic Xtreme uses the recovered space for its internal variables; it is not freely available for other uses without reservation. This option does not apply to SA-1 ROMs.
Controller optimization (ControllerOptimization)	Moves controller processing out of NMI to leave more time for display updates.
Fixed color optimization (FixedColorOptimization)	Reduces NMI work for updating the fixed color used by the game's color math.
Kevin's Lunar Magic VRAM optimization (KevinLMVRAMOptimization)	Integrates Kevin's optimization for Lunar Magic VRAM updates and moves some of its processing out of NMI. Use this version instead of installing the original patch separately. Once installed, it must not be uninstalled: doing so can break the ROM.
Status bar optimization (StatusBarOptimization)	Reduces the original status bar's NMI work. Incompatible with resources that replace or modify it, such as custom status bars or patches that remove it.

For options that may conflict with other resources and the RAM used by the system, see Compatibility.

Some features depend on others: DynamicPoses requires GraphicsChange; PalettesEffects requires PalettesChange; PlayerFeatures requires both graphics and palette changes; and YoshiFeatures requires PlayerFeatures.

Quick Start

Quick installation guide: Quick Start

Tools and support

Pending

Files and formats

Related article: Dynamic Xtreme files and formats

Dynamic sprite creation guide

To learn how to prepare, program, load, and draw a dynamic sprite, see the Dynamic Xtreme dynamic sprite creation guide.

Dynamic Xtreme with UberASM

The Dynamic Xtreme UberASM guide shows how to reserve palettes, configure dynamic sprite space and the per-frame data limit, create animations, change player graphics, and apply palette effects.

API

The ASM API reference explains how to use Dynamic Xtreme's variables, defines, routines, and macros. It covers each call's inputs and results, with examples for poses, drawing, palettes, color effects, and graphics transfers, as well as multiplication and division macros.

How the system works

The article on Dynamic Xtreme's internal workings explains the organization of NMI and game modes, graphics and palette loading, pose drawing, optimizations, the dynamic pose cache, and palette effects.

Compatibility

In general, features without installer warnings do not usually have compatibility problems with other resources. These are:

• GraphicsChange
• PalettesChange
• DynamicPoses
• DrawingSystem
• PalettesEffects
• Free7E2000
• ControllerOptimization
• FixedColorOptimization

This does not guarantee that every resource combination will work: two pieces of code may still use the same RAM, the same VRAM space, or modify the same game routine. Also, YoshiFeatures requires PlayerFeatures, so the latter's restrictions still apply.

Features with compatibility restrictions

Optional feature	Possible conflicts and what to do
PlayerFeatures	May conflict with LX5's Powerups, Player 8x8 tiles DMAer, Player 32x32, and other systems that replace player graphics or palette loading. Player Revolution is compatible. If your player system needs those original routines, leave this option disabled; you must also disable YoshiFeatures.
YoshiFeatures	Depends on PlayerFeatures and inherits its compatibility restrictions, even though it has no separate warning. If a resource is incompatible with PlayerFeatures, enabling only YoshiFeatures cannot avoid the conflict: leave both disabled.
StatusBarOptimization	Incompatible with resources that modify, replace, or remove the original status bar, such as LX5's DKC Style Status Bar, Minimalistic Status Bar, and Nuke Status Bar. Leave this optimization disabled if you use one of them.
KevinLMVRAMOptimization	Integrates Kevin's Lunar Magic VRAM optimization patch: use this version instead of installing the original separately. Its warning also states that it must not be uninstalled after installation, because doing so can break the ROM. To revert it, restore a backup made before installation.

These features are optional: leave a conflicting feature disabled and continue using Dynamic Xtreme's other systems, respecting their dependencies. Disabling an option does not undo another patch's changes or remove the uninstall restriction on KevinLMVRAMOptimization.

RAM usage

The main addresses are configured in ASM/DXDefines.asm inside the Dynamic Xtreme directory. In the repository, this is DynamicXtremeLibrary/ASM/DXDefines.asm.

The space used depends on the enabled features and whether the ROM uses SA-1. The following ranges include both endpoints and were calculated with all features that reserve RAM enabled, !VRAMTransferSize = 64, and !CGRAMTransferSize = 64:

Configuration	!Variables block	Size	!Variables2 block	Size
LoROM with Free7E2000	$7E2000–$7E2500	$0501: 1281 bytes	$7E2800–$7E3608	$0E09: 3593 bytes
LoROM without Free7E2000	$7FB440–$7FB940	$0501: 1281 bytes	$7F9C80–$7FAA88	$0E09: 3593 bytes
SA-1	$40C000–$40C47E	$047F: 1151 bytes	$418AFF–$419907	$0E09: 3593 bytes

The two internal blocks total 4874 bytes on LoROM and 4744 bytes on SA-1. The difference comes from the drawing system's 130 bytes, which are reserved only on LoROM. The gap between the blocks is not automatically occupied.

Disabling a feature removes its conditional reservations and shifts the addresses that follow. Increasing !VRAMTransferSize or !CGRAMTransferSize also increases their table sizes.

Sprite tables

DX_FreeRams and DX_FreeRams2 are not available for your own variables: the sprite tables from DynamicXSpritesTables.asm and MoreSpriteMiscs.asm begin there. You must also reserve them when using those resources.

With the same configuration as the table above, their ranges are:

Configuration	Tables starting at DX_FreeRams	Size	Tables starting at DX_FreeRams2	Size
LoROM with Free7E2000	$7E2501–$7E26EC	492 bytes	$7E3609–$7E3824	540 bytes
LoROM without Free7E2000	$7FB941–$7FBB2C	492 bytes	$7FAC82–$7FAE9D	540 bytes
SA-1	$40C47F–$40C6D8	602 bytes	$419908–$419BCD	710 bytes

Including these tables, the described space totals 5906 bytes on LoROM and 6056 bytes on SA-1. Tables are calculated for 12 normal sprites on LoROM and 22 on SA-1, plus the corresponding cluster, extended, and smoke slots.

Normally, DX_FreeRams2 starts immediately after the second internal block. On LoROM without Free7E2000, it is placed separately using !Variables3 = $7FAC82, so its tables do not immediately follow !Variables2.

Dynamic Xtreme also uses the existing fixed color and palette mirrors: $7E0701 (2 bytes) and $7E0703 (512 bytes) on LoROM. Their declared SA-1 addresses are $406701 and $006703. These are neither additional reservations within the blocks above nor free addresses for your code.

Relocating RAM to resolve a conflict

Warning: relocating these variables requires knowing which address to choose and accounting for the full memory footprint. A free starting address is not enough: the entire block must fit, and the routines must be able to access it. If you are unfamiliar with this, consult someone experienced before changing the addresses.

If another resource uses any of these areas, you can edit ASM/DXDefines.asm to make Dynamic Xtreme use other available space in your ROM hack.

• Change !Variables and !Variables2 in the configuration matching your ROM: LoROM with Free7E2000, LoROM without it, or SA-1.
• On LoROM without Free7E2000, also check !Variables3, which determines where the DX_FreeRams2 tables begin.
• Reserve enough space for the entire block and the sprite tables that follow. A free first address alone is not enough.
• Respect the memory map and the banks required by the routines. Not every free address works with every type of access.
• After changing the addresses, reinstall Dynamic Xtreme and reinsert PIXI, UberASM, and any other resources that use its defines.

With Free7E2000, Dynamic Xtreme uses the RAM recovered by relocating the original graphics; do not share it with other resources without checking which part is used. Without that option, the alternative addresses may overlap those of other common resources. SA-1 uses its own addresses and disables Free7E2000.

Edit the file in the ASM directory, not the generated copies in ExtraDefines or Patch/ExtraDefines: those copies are regenerated during installation.

Resources made with Dynamic Xtreme

Resources developed for Dynamic Xtreme are not usually published on traditional sites such as SMW Central, because many depend directly on the framework and its advanced systems.

Instead, Dynamic Xtreme resources, examples, systems, and related projects are mainly collected at:

https://snestorage.dev

There you can find sprites, player systems, graphical effects, technical examples, and other resources designed specifically for Dynamic Xtreme.

Conclusion

Dynamic Xtreme aims to modernize and simplify dynamic systems in Super Mario World, offering more flexible, powerful, and accessible tools while retaining compatibility and advanced control.

The project continues to evolve with new optimizations, formats, and tools for both experienced users and people just starting to work with dynamic graphics on SNES.

Dynamic Xtreme's main aim is to support increasingly complex resources and systems while keeping the workflow cleaner, easier to maintain, and more accessible to the community.