He is trying to debug things however it appears that the dot product function isn't working. We looked at it for a few moments, decided something odd was going on and he went home saying he'd get our lead to look at it tomorrow.
Tomorrow became today and as always I rolled in at 10am, after about 30mins I wandered over to the same coder to find him and our lead looking at the code.
The code was this;
float value = vector.Dot(vector);
Single stepping passed this code in the debugger didn't show any change to the variable 'value' at all. And yes, it was in debug mode as this was the first thing I checked.
In the end we had 4 coders working on this;
Brooksy who first found the problem, Barry our lead, Ben another coder and myself.
Brooksy has no experiance in assembler at all, Barry has limited and myself and Ben had done a bit.
This was important to note because the dot product was written in assembler to take advantage of the PS2 hardware.
Having looked at the function it seemed like it couldn't work because of the op codes being used, so changes were made and things were tried all the time I was trying to get up to speed on how the PS2 assembler worked.
The break through came when we started looking at it in mixed mode (assembler and C++ together) to see what the compiler was spitting out. At this point I pretty much left both my lead the brooksy in the dust as old knowledge started to combine with new.
In the end, it turned out the original function was correct, given away by what was happening post call site.
Having looked at the code it became clear that the compiler was using two floating pointer registers to do a comparison after the assignment, however it was only loadiing one value in (from the 'this' pointer) and comparing it with a value already in a floating point register.
A quick look at the dotproduct shows that the code was indeed using the register but it was saving and restoring it because we'd told it to. This change came about because the local variable for the result was never changed in the debugger either.
What infact was happening was the compiler had decided to bypass memory all together; so while space was allocated on the stack for the variables both in the function and at the return site, it was never infact used. Instead the value was kept in the floating point register and used directly.
Good for speed; yes.
But if you are debugging and you want to find out whats going on it wasn't all that useful.
Now, Codewarrior's debugger can tell you what is going on at the register level with variables as well, yet for some reason in this instance it didn't bother tracking things as we'd have liked making the whole thing a nightmare to figure out.
Granted, this didn't solve the problem Brooksy had to start with with the lighting, however I gained some understanding of how the hardware works, got to look awesome and got a nice little chemical rush as I solved the problem [grin]
Still, so much hate for Codewarrior...
