3D rendering

Revision as of 06:00, 30 August 2024 by Marius851000 (talk | contribs) (Improved syntax and some typo)

3D Rendering engine

The Nintendo DS dispose of hardware that can perform 3D rendering in addition to its dedicated 2D system. EoS mostly use the 2D system, but occasionally make use of the 3D engine for some effects. Those are:

  • The dialogue box border and background
  • Rendering of the quick status at the top of the bottom screen during a dungeon
  • The various weather effect
  • Boss transition wipe
  • A few other effect during cutscenes


The 3D engine is capable of rendering in 2D, simply by rendering rectangle in front of the virtual camera, which is what EoS always does. The way this game work is by first buffering the elements to render to a buffer and then a function will submit those to render (probably during VBlank), which will then take effect on the next frame.

The DS 3D hardware can only render on the main screen, which in EoS is the bottom screen. Some game (but not EoS) render on both screen by switching the main screen every frame, dividing by two the frame rate from 60 to 30 FPS.

Memory management

The bank D is dedicated to storing the textures used for the 3D render, and bank F is used to store the palettes. Bank D is 128KiB large, and bank F is 16KiB large. The game seems to mostly allocate texture on a multiple of 1KiB, and palette on a multiple of 0x100 bytes, thought it is possible to perform allocation not aligned on those arbitrary values (but it still (maybe, untested) need to be 4-bytes aligned).

The game store its 3D data in WTE files. It contain the texture and the palette, but not where the file will be stored in the RAM, which is specified in the game’s code. Here is table of the (known) allocation the game make. It is probably exhaustive.

ProcessWTE is the function used to load them (function address is for EU ROM, but palette and texture allocation have no reason to be different).

file location dungeon or overworld description call to ProcessWTE texture offset texture size (bytes) palette offset note
1025 in dungeon pack dungeon overlay_29::022eda20 0x400 0xc00 0x1d00
1007 to 1011 in dungeon pack dungeon overlay_29::02336200 0x0 0x400 0x0 which one is loaded depend on language
1031 or 1003 in dungeon pack dungeon both are fogs texture overlay_29::023394e4 or overlay_29::023395f8 0xB000 0x2000 0x1400 unknown how which one is choosed
1005 in dungeon pack dungeon overlay_29::023394e4 0xD000 0x2000 0x1500
1001 in dungeon pack dungeon overlay_29::023394e4 0xF000 0x2000 0x1600
some between 1012 to 1020 in dungeon pack dungeon overlay_29::0233614c 0x1000 0x400 0x200 which one is loaded depend on language
c_wipe.wte or w_wipe2.wte horizontal bar of differing colors, presumably for wiping the screen 0x0206afb0 0x8000 0x0
w_heart.wte multiple hearts symbol, filled and shaded 0x0206b000 0x2000 0x100
circle.wte hearth symbol, not filled 0x0206b050 0x2000 0x200
s13p01t1.wte overworld boss wipe graphic overlay_11::02316d4c 0x8000 0x8000 0x100
d04p31t1.wte overworld big wave of the waterfall cave diamond overlay_11::02314b9c 0x0 0x4800 0x0
v15p03t1.wte overworld Some crystal cave crystals overlay_11::02314d20 0x0 0x8000 0x0
p03p01t1.wte overworld fog/mist texture overlay_11::02314eec

overlay_11::022f33d8

0x0 0x6000 0x0
frameX.wte (where X is between 0 to 4) both dialog box frame 0x020274e4 0x1F000 0x800 0x1F00
t01p01t1.wte overworld some clouds overlay_11::022f3368 (loading weather 1) 0x0 0x4000 0x0
t01p01t2.wte overworld some clouds overlay_11::022f3394 (loading weather 1) 0x4000 0x4000 0x100
d73p41t1.wte overworld another kind of mist/fog (top of Shaymin mountain?) overlay_11::022f341c (loading weather 3) 0x0 0x6000 0x0

Based on those allocations, it seems that VRAM from 0x11000 to 0x1EFFF (included) are free to be used both in overworld and dungeon. For the palette, it seems everything from 0x300 to 0x13FF (included) are unused.

Loading texture

Once you have your texture in the WTE format saved in the rom, you need to call a function to load WTE (LoadWteFromRom) and then copy stuff to RAM with ProcessWTEWrapper, and then call another (unnamed in pmdsky-debug) function DoSomethingOn3dAllocAndClearInput.