Hello :)
It is a long while that I did not update my blog. I continued to work on my ucode and actually I am near completion. Not all features intended are at final stage but my codes works as according to my ideas.
In a nutshell:
1) Colors (including fog alpha value) and textures coordinates are loaded at pipeline level and they are not part of the vertex attribute anymore. With a color and texture DMEM buffer, this saves a significant DMEM memory.
2) After reviewing the clipping code in more details of Fast3D, I discovered that awful truth: about 200 bytes of memory, reserved for clipping in DMEM, was NEVER used.
As I only arrive 52 vtx available in the vertex buffer, I went down the road to further optimize the vertex structure.
3) The only way to do was to reduce the space used for clipping. As such I decided to keep in the original vertices coordinates along with a reference to its MVP matrix and calculate the data needed for the clipping only when clipping occurs. It does mean that the MVP matrix used for the vertex processed must be still available in DMEM memory.
4) In order to do so, I change the way to store the matrix: the space allocated in DMEM for modelview, projection and ModelviewProjection matrix can be allocated dynamically by the users. This allows where necessary to have actually 3 MVP matrix stored at the same time in DMEM. It is also possible to pop matrix as necessary.
This trick works fine for static objects/scene but it might be an issue with characters using bones.
The vertex buffer thanks to this went up to 64 vertex, which is really nice! :)
I tried, without success, to get my ucode working with nusys. I am not sure it is feasible to do without the source code of nusys.
I did not finish the implementation of point lighting. I may one day want to come back to this, though it is unlikely.
I am happy to arrive to this point, I learnt a lot and I feel definitely that I arrive to a point where I can look at this work as an achievement.
But, and I know this for a long while now, that this work has been done only for my own purpose. I cannot release proprietary code, even rewritten. Additionally no N64 homebrew developers will work with libultra anymore (c.f. Portal).
This is why I decided to stop working on the ucode and leave it as is. It is sad but it is the right move to do.
It does not mean that all is wasted, I will continue to play with the N64
but after having spent so much time at low level, I would prefer working at
"high" level. Likely I will try to develop homebrews with Libdragon
and Tiny3D. It may take a while till I arrive to something interesting but this
is where I want to develop.
It was a pitty. i dont know If your code will be works fine into F3DEX3, for optimize official roms, since ait could replace ucode for roms with a patcher. It will be a dream, optimize any game with a simple patch
RépondreSupprimer