3D rendering: Difference between revisions

Line 1:

== 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 Nintendo DS dispose of hardware that can perform 3D rendering in addition to its dedicated 2D system. EoS mostly uses the 2D system, but occasionally makes 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~~

* The various weather effects

* Boss transition wipe

* A few other ~~effect~~ during cutscenes

* A [[Effect.bin|few other effects]] 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 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 works 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.

Line 17:

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 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) allocations the game makes. 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).

@@ Line 1: / Line 1: @@
 == 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 Nintendo DS dispose of hardware that can perform 3D rendering in addition to its dedicated 2D system. EoS mostly uses the 2D system, but occasionally makes 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
+* The various weather effects
 * Boss transition wipe
-* A few other effect during cutscenes
+* A [[Effect.bin|few other effects]] 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 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 works 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.
@@ Line 17: / Line 17: @@
 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 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) allocations the game makes. 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).