Today I am very happy to give you finally news on the recent developments on the microcode. In the last months, as previously underlined, I tackled lighting and reflection mapping. I am not yet totally done with it but with all the changes already carried out, it is worthwhile to share the current status.

*I)
***Change
the way to load in RSP the inverse of transpose of the 3x3 part of the model matrix**

In order to compute
lighting, you have to use the inverse of transpose of the *3x3* part of the model *matrix (which I will call 3x3 matrix as from now) to get the light direction in model
coordinates.*

a)
*In Fast3D, the model matrix is
first loaded and then data are changed by using some special RSP (LTV, STV) instructions
which should help to do so. It requires some scratch DMEM space to do so and
about 16 instructions to have in the RSP one
3x3*
matrix.

* b)
**In F3DEX2, the 3x3 matrix is loaded directly from DMEM where
the model matrix is stored. There is no need to load the model matrix and then
transpose it and no scratch DMEM space is necessary. It provides again one 3x3 matrix.*

*My implementation is different as my goal is also to
implement point lighting which is totally missing in the original F3D. In order
to do point lighting, it is required to have the model matrix and the 3x3 matrix
and thus for each vertex to be processed. *

*I do underline “ for each vertex” as with directional
lighting, till you got a new matrix or new lights, you may use the same
computed light directions in model coordinates for each vertex to be processed,
meaning that the 3x3 matrix would have to be used only once for doing such
computations.*

So point
lighting requires to have the model matrix and the 3x3 matrix at the same time.
On top of it, the RSP vector instructions (VU) can hold 8 16 bits lanes, which
is used to processed two vertex at once. If for F3D, one 3x3 matrix was
sufficient to compute a limited number of light directions *in model coordinates*, it cannot be the case when
processing point lighting per vertex. So it does mean that the VU must hold two
model matrix and 3x3 matrix, duplicated on the same vectors.

It took me a
significant time to find a good solution for those requirements. After loading
the model matrix twice (as for Fast3D), I take me only 22 instructions to get
the **two** 3x3 matrix as desired. In
this respect I used a RSP instruction in a different way than usually intended,
VMRG and register VCC.

Additionally I
have replicated the way the normalization of the light direction in model
coordinates as in F3DEX2, more efficient than Fast3D.

**II)
Separate
lighting computations from vertex processing**

As explained, lighting/reflection mapping computations is done per vertex. If it may be fine with directional light, with point lighting it would mean reloading over and over, for each vertex, the model and 3x3 matrix as the RSP is unable to hold all those data and performing the rest of vertex processing tasks (i.e. multiply vertices with ModelViewProjection (MVP) matrix, clipping, fog, etc.). In order to do so, lighting computations has to be done separately. It does mean to break the Vtx structure as per gbi.h where vertex coordinates, colors/normals and textures coordinates were tied together.

There is many advantages to do so:

You may load with flexibility vertices, colors/normals and texture coordinates, in separated buffers.

You may avoid duplications of data (same color, same normal, same texture coordinates)

You can do computations more efficiently for/on those buffers.There is of course some inconveniences:

You need to have new structures for colors/normals and texture coordinates. As the vectors in RSP are 8 lanes of 16 bits, structures will have to hold 2 colors/normals or textures coordinates. It is also required to have those structure 64 bits aligned due to the RSP DMA engine.GBI compatibility is broken. N64 programmers have to rewrite a portion of their code.

Flexibility
comes with more complexity for the programmers (multiplication of the GBI macros)

Many customized microcodes has done, at least partially, such a change (i.e. Perfect Dark or Indiana Jones)

So I got to create a new command to compute lighting and texture coordinates, along with multiple GBI macros.

I took advantages of having two 3x3 matrix (instead of 1) to compute lighting directions in model coordinates nearly 2 times faster. I separated directional lighting computation from texture coordinates computation entirely in order to avoid many unnecessary computations done by F3D. If the computation speed on lighting should remain more or less the same, the one on S&T for reflection mapping has been improved.

Of course I have considered as well to optimize the DMEM space used for those computations.

In the original Fast3D, each light structure used 32 bits. In F3DX2, it uses 24 bits. In my implementation, it uses only 16 bits. In this respect I got to change the way some libultra functions were returning data (guLookAtHilite, guLookAtReflect, guPosLight, guPosLightHilite). I could notice something which could be optimized in those functions (and some others as well) and which I have implemented. According to the MIPS 4200 documentation, SQRT and DIV CPU instructions are slow so where possible it is better to use an inverse fast square root instead. (Thinking about it, it is noticeable that reflection mapping was not used in a lot of games, likely because reflection mapping was actually too demanding).

Now obviously you have to link vertex, output colors and output texture coordinates. I could have decided to use the 2 remaining byte of the vertex structure, currently padding, to do so. However I took the approach to do so at triangle level as it is at this level that the control should be given to the graphic designer. It also helps to avoid unnecessary duplications of data in buffers. However a careful approach have to be taken when some advanced lighting features will be used, as reflection mapping or point lighting, where all is interdependent at vertex level and not triangle level.

It means that
I got to rewrite entirely the G_TRI command. Additionally G_VTX commands got to
be adapted as lighting and texture coordinates computations are not done
anymore with this command.

And voila!

Now I will focus on point lighting and what I wanted to create from the very beginning of this project: implement a circular buffer to store transformed vertex and generate strip triangles.

**Side note**: I will update soon my previous article as I
continued to do some interesting changes for G_BRANCH_Z and G_CULLDL.

**HELP NEEDED**: After
implementation of point lighting, triangle strips and optimizing DMEM, it will
be time to test the microcode. In this respect I am calling for people (with sufficient
programming skills of course) to help out in this respect. It can be done in
different ways: adapt SDK N64 demos, adapt already written homebrew games, write
new test demos using the new features of the microcode, etc. Contact me on N64brew discord channel in this
respect. Thanks!