Skip to content

Commit

Permalink
Deploying to gh-pages from @ 4778bda 🚀
Browse files Browse the repository at this point in the history
  • Loading branch information
sauraen committed Aug 31, 2024
1 parent 029d532 commit 01e3af4
Show file tree
Hide file tree
Showing 3 changed files with 2,144 additions and 2,123 deletions.
8 changes: 4 additions & 4 deletions gbi_8h.html
Original file line number Diff line number Diff line change
Expand Up @@ -2970,7 +2970,7 @@ <h2 class="memtitle"><span class="permalink"><a href="#a2069e57bde4b09cbbdd1110e
</div><div class="memdoc">
<p>F3DEX3 has a basic auto-batched rendering system. At a high level, if a material display list being run is the same as the last material, the texture loads are automatically skipped the second time as they should already be in TMEM.</p>
<p>This design generally works, but can break if you call a display list twice but in between change a segment mapping so that a referenced image inside is actually different the two times. In these cases, run the below command between the two calls (e.g. when you change the segment) and the microcode will not skip the second texture loads.</p>
<p>Internally, a material is defined to start with any set image command, and end on any of the following: call, branch, return, vertex, all tri commands, modify vertex, branch Z/W, or cull. The physical address of the display list &ndash;not the address of the image&ndash;is stored when a material is started. If a material starts and its physical address is the same as the stored last start address, i.e. we're executing the same material display list as the last material, material cull mode is set. In this mode, load block, load tile, and load TLUT all are skipped. This mode is cleared when the material ends.</p>
<p>Internally, a material is defined to start with any set image command, and end on any of the following: call, branch, return, vertex, all tri commands, tex/fill rectangles, and successes on cull or branch w/z (which are usually preceded by vertex loads anyway). The physical address of the display list &ndash;not the address of the image&ndash;is stored when a material is started. If a material starts and its physical address is the same as the stored last start address, i.e. we're executing the same material display list as the last material, material cull mode is set. In this mode, load block, load tile, and load TLUT all are skipped. This mode is cleared when the material ends.</p>
<p>This design has the benefit that it works correctly even with complex materials, e.g. with two CI4 textures (four loads), whereas it would be difficult to implement tracking all these loads separately. Furthermore, a design based on tracking the image addresses could break if you loaded different tile sections of the same image in consecutive materials. </p>

</div>
Expand Down Expand Up @@ -3607,7 +3607,7 @@ <h1><a class="anchor" id="autotoc_md3"></a>
<div class="line"><span class="comment">// draw triangle 2 using vertex #3</span></div>
<div class="line"><a class="code hl_define" href="#afe0d779cf45ef43bbffd47bbaea0e390">gSP1Triangle</a>(glistp++, 1,2,3,0);</div>
<div class="ttc" id="agbi_8h_html_aa10b6a6fa88381b34eb4325034230024"><div class="ttname"><a href="#aa10b6a6fa88381b34eb4325034230024">gSPVertex</a></div><div class="ttdeci">#define gSPVertex(pkt, v, n, v0)</div><div class="ttdoc">macro which loads an internal vertex buffer in the RSP with points that are used by gSP1Triangle macr...</div><div class="ttdef"><b>Definition</b> gbi.h:2205</div></div>
<div class="ttc" id="agbi_8h_html_abc12c0642acde2394639e9f9e247dde9"><div class="ttname"><a href="#abc12c0642acde2394639e9f9e247dde9">gSPModifyVertex</a></div><div class="ttdeci">#define gSPModifyVertex(pkt, vtx, where, val)</div><div class="ttdoc">You can use this macro to modify certain sections of a vertex after it has been sent to the RSP (by t...</div><div class="ttdef"><b>Definition</b> gbi.h:3077</div></div>
<div class="ttc" id="agbi_8h_html_abc12c0642acde2394639e9f9e247dde9"><div class="ttname"><a href="#abc12c0642acde2394639e9f9e247dde9">gSPModifyVertex</a></div><div class="ttdeci">#define gSPModifyVertex(pkt, vtx, where, val)</div><div class="ttdoc">You can use this macro to modify certain sections of a vertex after it has been sent to the RSP (by t...</div><div class="ttdef"><b>Definition</b> gbi.h:3078</div></div>
<div class="ttc" id="agbi_8h_html_afb84e8da2787a5cf8ca385335a850d5c"><div class="ttname"><a href="#afb84e8da2787a5cf8ca385335a850d5c">G_MWO_POINT_ST</a></div><div class="ttdeci">#define G_MWO_POINT_ST</div><div class="ttdoc">changes the S and T values (texture coordinates of the vertex). The high 16 bits of val specify the S...</div><div class="ttdef"><b>Definition</b> gbi.h:289</div></div>
<div class="ttc" id="agbi_8h_html_afe0d779cf45ef43bbffd47bbaea0e390"><div class="ttname"><a href="#afe0d779cf45ef43bbffd47bbaea0e390">gSP1Triangle</a></div><div class="ttdeci">#define gSP1Triangle(pkt, v0, v1, v2, flag)</div><div class="ttdef"><b>Definition</b> gbi.h:2544</div></div>
</div><!-- fragment --><dl class="params"><dt>Parameters</dt><dd>
Expand Down Expand Up @@ -4631,7 +4631,7 @@ <h2 class="memtitle"><span class="permalink"><a href="#a06ed1458dbefbadfb146e0b2
</div><div class="memdoc">
<p>F3DEX3 has a basic auto-batched rendering system. At a high level, if a material display list being run is the same as the last material, the texture loads are automatically skipped the second time as they should already be in TMEM.</p>
<p>This design generally works, but can break if you call a display list twice but in between change a segment mapping so that a referenced image inside is actually different the two times. In these cases, run the below command between the two calls (e.g. when you change the segment) and the microcode will not skip the second texture loads.</p>
<p>Internally, a material is defined to start with any set image command, and end on any of the following: call, branch, return, vertex, all tri commands, modify vertex, branch Z/W, or cull. The physical address of the display list &ndash;not the address of the image&ndash;is stored when a material is started. If a material starts and its physical address is the same as the stored last start address, i.e. we're executing the same material display list as the last material, material cull mode is set. In this mode, load block, load tile, and load TLUT all are skipped. This mode is cleared when the material ends.</p>
<p>Internally, a material is defined to start with any set image command, and end on any of the following: call, branch, return, vertex, all tri commands, tex/fill rectangles, and successes on cull or branch w/z (which are usually preceded by vertex loads anyway). The physical address of the display list &ndash;not the address of the image&ndash;is stored when a material is started. If a material starts and its physical address is the same as the stored last start address, i.e. we're executing the same material display list as the last material, material cull mode is set. In this mode, load block, load tile, and load TLUT all are skipped. This mode is cleared when the material ends.</p>
<p>This design has the benefit that it works correctly even with complex materials, e.g. with two CI4 textures (four loads), whereas it would be difficult to implement tracking all these loads separately. Furthermore, a design based on tracking the image addresses could break if you loaded different tile sections of the same image in consecutive materials. </p>

</div>
Expand Down Expand Up @@ -5337,7 +5337,7 @@ <h2 class="memtitle"><span class="permalink"><a href="#aaf15e5e8939a99813136386c
</div><div class="memdoc">
<b>Value:</b><div class="fragment"><div class="line"> <a class="code hl_define" href="#a05cbbc5a54641419bc1258390f3d6710">gsSPNumLights</a>(n), \</div>
<div class="line"> gsDma2p(G_MOVEMEM, &amp;(name), (n) * 0x10 + 8, G_MV_LIGHT, 0x10)</div>
<div class="ttc" id="agbi_8h_html_a05cbbc5a54641419bc1258390f3d6710"><div class="ttname"><a href="#a05cbbc5a54641419bc1258390f3d6710">gsSPNumLights</a></div><div class="ttdeci">#define gsSPNumLights(n)</div><div class="ttdef"><b>Definition</b> gbi.h:3257</div></div>
<div class="ttc" id="agbi_8h_html_a05cbbc5a54641419bc1258390f3d6710"><div class="ttname"><a href="#a05cbbc5a54641419bc1258390f3d6710">gsSPNumLights</a></div><div class="ttdeci">#define gsSPNumLights(n)</div><div class="ttdef"><b>Definition</b> gbi.h:3258</div></div>
</div><!-- fragment --><p>Set all your scene's lights (directional/point + ambient) with one memory transaction. n is the number of directional / point lights, from 0 to 9. There is also always an ambient light. name should be the NAME of a Lights struct (NOT A POINTER) filled in with all the lighting data. You can use the gdSPDef* macros to fill in the struct or just do it manually. Example: Lights2 myLights; // 2 dir/pos + 1 ambient <code> gSPSetLights(POLY_OPA_DISP++, 2, myLights);</code></p>
<p><code>If you need to use a pointer, e.g. if the number of lights is variable at runtime: Light *lights = memory_allocate((numLights + 1) * sizeof(Light)); lights[0].p.pos = ...; lights[1].l.dir = ...; ... lights[numLights].l.col = ambient_color(); gSPSetLights(POLY_OPA_DISP++, numLights, *lights); // &lt;- NOTE DEREFERENCE</code></p>
<p><code>If you're wondering why this macro takes a name / dereference instead of a pointer, it's for backwards compatibility. </code></p>
Expand Down
Loading

0 comments on commit 01e3af4

Please sign in to comment.