What I've understood so far :
- CG toolkit is great for creating vertex shaders (in NVidia SDK 9.5, for free)
- The result of compilation/assembly is a binary called "pseudo-code" (.vso).
- It can be a .h with the .vso data declared as a DWORD array. Include it.
- In pbKit, function pb_pcode2mcode() will convert it into gpu "micro-code".
- You upload the micro-code into inner registers (see cursors in inner.txt).
- "Vertex feed configuration" registers are like dcl_* (what goes where).
- "Fixed function pipeline" is just a default VS set by official libraries. Useless.
- Pixel shader in xbox is just a few values targetting a few inner registers.
In pbKit, when a VS is used, you will have in comments everything you need to know in order to recreate your own vertex shader with CG toolkit. PS will be just a sequence of inner registers initialization.
Official libraries lose a lots (really a lots) of time, saving previous values, VS, etc... then executing your calls, then restoring stuff to keep on going complex and necessary preriodic tasks such as full screen AntiAliasing. I won't do the same mistake. It will be up to you to know that a periodic useful call needs prepared values in specific inner registers. If you know you didn't change any of them then there won't be any time lost in saving/restoring them. You will be in control of everything and free to optimize speed madly.
I will post here a warning when "Demo 02 - Antialiased Pong" is published (need to create pb_pcode2mcode and master pixel shader related inner registers to have that damn texture mapping work finally). It will demonstrate when and how to call functions in order to do full screen antialiasing once per frame. It won't be automatic code hidden inside pbKit but commented inner registers handling in the game source itself (so you know what inner registers values are needed and need to be preserved or saved/restored if you upload your own VS or change the PS related inner registers between two full screen Antialiasing updates.
