3D rendering: Difference between revisions
Marius851000 (talk | contribs) Initial page creation |
m Frostbyte moved page User:Marius851000/Draft/3drender to 3D rendering without leaving a redirect: Finished page |
||
(5 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 | 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 | ||
The 3D engine | 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. | |||
The | |||
=== 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). | |||
{| class="wikitable" | |||
|+ | |||
!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'''. |
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.