3D rendering: Difference between revisions

From SkyTemple
First version of Memory use table
m Frostbyte moved page User:Marius851000/Draft/3drender to 3D rendering without leaving a redirect: Finished page
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
== 3D Rendering engine ==
== 3D Rendering engine ==
The Nintendo DS dispose of hardware that can perform 3D rendering in addition to it’s dedicated 2D system. EoS mostly use the 2D system, but occasionally make use of the 3D engine for some effects. Those are:
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
* The dialogue box border and background
Line 7: Line 7:
* Boss transition wipe
* Boss transition wipe
* A few other effect during cutscenes
* A few other effect during cutscenes
** (TODO: which one?)
* (TODO: check that I forgot none)




The 3D engine is totally 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 things 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 3D engine 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 framerate from 60 to 30 FPS.
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.


=== Memory ===
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.
The bank D is dedicated to store 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 0x100B, but there it is possible to perform allocation not aligned on those arbitrary values (but it still (maybe, untested) need to be 4-bytes aligned).


=== 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.


The game store it’s 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).
 
ProcessWTE is the function used to load them.
{| class="wikitable"
{| class="wikitable"
|+
|+
Line 86: Line 83:
|0x400
|0x400
|0x200
|0x200
|which one depend on language
|which one is loaded depend on language
|-
|-
|c_wipe.wte or w_wipe2.wte
|c_wipe.wte or w_wipe2.wte
|
|
|
|horizontal bar of differing colors, presumably for wiping the screen
|0x0206afb0
|0x0206afb0
|
|
|0x8000
|0x8000
|
|0x0
|
|
|-
|-
|w_heart.wte
|w_heart.wte
|
|
|
|multiple hearts symbol, filled and shaded
|0x0206b000
|0x0206b000
|
|
|0x2000
|0x2000
|
|0x100
|
|
|-
|-
|circle.wte
|circle.wte
|
|
|
|hearth symbol, not filled
|0x0206b050
|0x0206b050
|
|
|0x2000
|0x2000
|
|0x200
|
|
|-
|-
|s13p01t1.wte
|s13p01t1.wte
|overworld
|overworld
|
|boss wipe graphic
|overlay_11::02316d4c
|overlay_11::02316d4c
|0x8000
|0x8000
|
|0x8000
|
|0x100
|
|
|-
|-
|d04p31t1.wte
|d04p31t1.wte
|overworld
|overworld
|
|big wave of the waterfall cave diamond
|overlay_11::02314b9c
|overlay_11::02314b9c
|0x0
|0x0
|0x4800
|0x4800
|
|0x0
|
|
|-
|-
|v15p03t1.wte
|v15p03t1.wte
|overworld
|overworld
|
|Some crystal cave crystals
|overlay_11::02314d20
|overlay_11::02314d20
|0x0
|0x0
|
|0x8000
|
|0x0
|
|
|-
|-
|p03p01t1.wte
|p03p01t1.wte
|overworld
|overworld
|
|fog/mist texture
|overlay_11::02314eec
|overlay_11::02314eec
overlay_11::022f33d8
|0x0
|0x6000
|0x0
|0x0
|
|
|
|
|-
|-
|frameX.wte (where X is from 0 to 4)
|frameX.wte (where X is between 0 to 4)
|both
|both
|
|dialog box frame
|0x020274e4
|0x020274e4
|0x1F000
|0x1F000
Line 162: Line 160:
|t01p01t1.wte
|t01p01t1.wte
|overworld
|overworld
|
|some clouds
|overlay_11::022f3368
|overlay_11::022f3368 (loading weather 1)
|0x0
|0x4000
|0x0
|0x0
|
|
|
|
|-
|-
|t01p01t2.wte
|t01p01t2.wte
|overworld
|overworld
|
|some clouds
|overlay_11::022f3394
|overlay_11::022f3394 (loading weather 1)
|0x4000
|0x4000
|0x4000
|
|0x100
|
|
|
|-
|-
|p03p01t1.wte
|d73p41t1.wte
|overworld
|overworld
|
|another kind of mist/fog (top of Shaymin mountain?)
|overlay_11::022f33d8
|overlay_11::022f341c (loading weather 3)
|0x0
|0x0
|
|0x6000
|
|
|-
|d73p41t1.wte
|overworld
|
|overlay_11::022f341c
|0x0
|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'''.

Latest revision as of 14:38, 30 August 2024

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.