Mistakes and What I learned
(I'm writing this down in the hope that I will learn from my mistakes)
I was explicitly told not to remove several lines of test code from a terrain brush. I thought I was careful and removed everything, but found 3 or 4 cases where I didn't change it. Maybe I didn't save it or something. Triple check everything fucker, you wasted someone's valuable time.
I set an override flag to true but never set it false again. Testing probably wouldn't have caught it. A code verification, and a step-by-step run through of the debugger would have.
Merge error - I made a merge but didn't test it afterwards. Don't do it again.
Mismatched object functionality. I had an object add a pointer to a list. But the removal of that pointer from the list took place not in the same object's destructor but in a different class. The mismatching of responsibilities resulted in some items never getting freed from the list. If one class does something, then that class is also responsible for undoing it.
Commited a bug where a bad access would be found in the destructor. Mistake: didn't run a debugger through all functions
Made an assumption that files were being dumped into the correct INV section. Document assumptions if they are made.
Remember to always check when writing delete, am I deleting an array? Use []
Divison - ALWAYS check for divide by zero! It won't always crash right away!
Made an assumption that pad bytes in IFF can be anything. That was incorrect. IFFCheck misses that as well.
Make sure everything is filled out in the header comments and duplicated in the functions
THESE ARE THE BUGS I'VE MADE:
1. The NOS effect was not showing up on the RX7 during the E3 demo. Konrad figured out that although the geometry was placed in the right spot, the pivot point for that geometry was in the middle of the car! So you would never see that. Good thing to check if something in the world isn't showing up even though it appears correct in Max
2.Make sure to check for warnings. I've broken the PS3 build by not checking for a type conversion.
3. _CrtCheckMemory() is fucking awesome. Wrap it in an assertion. Also note that
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_CHECK_ALWAYS_DF|_CRTDBG_CHECK_CRT_DF|_CRTDBG_DELAY_FREE_MEM_DF);
is a powerful checking system as well.
4. I didn't realize that a struct actually contained a union when I changed it. Its rare but when it happens, all hell can break loose
5. I could have caught a bad threading error if I initialized my values to something besides zero (e.g. 0xFFFFFF) Instead, 0 was being passed around
6. eD3DBufferManager - I had a variable that used a variable thats shared on two threads. BAD! Use a mutex lock
7. DrawIndexedPrimitive - when I moved to using the baseVertexIndex parameter. I missed one call to fixup. And then that made trees at the center of the world
8. When I made the XSpriteTemplate stuff, I had 3 buffers, but I didn't make a second array for basVertexIndex. Luckikly an assertion later caught it
9. Ok. You made the assumption that eSystem.hpp was in all platforms which it wasn't. Fair enough.
Specifically. You checked the PLAT_PC option which is good. But not the include. Made sure to check the includes on each platform and if there is any doubt then wrap it up in an ifdef
10. Not testing the game in fullscreen mode. It was 1/3 the windowed framerate!!!
11. hex codes for memory
0xcdcdcdcd - Created but not initialised
0xdddddddd - Deleted
0xfeeefeee - Freed memory set by NT's heap manager
0xcccccccc - Uninitialized locals in VC6 when you compile w/ /GZ
0xabababab - Memory following a block allocated by LocalAlloc()
12. unitialized variables, these can cause release / miletone problems that are fine in debug. Note that /RTC1 doesnt detect unitinizatl class variables
13. always assert that input is aligned before using sse!
14. AppVerifier - use it. Always
15. D3DXMatrixMultiplyTranspose, and SetRawMatrix - much better than SetMatrix
16. AVOID CALLS INTO DLLS! Dave Wall got a huge speedup by not calling into the DLLs and using the D3DSetStateManager ~20%!!!!!
17. Konrad had a nice fix to some bad code. We couldn't replace the pointers with smart pointers, so by using a slotpool, the pointers would always point to valid memory
18. I SSE optimized a block of code without realizing what was going on. By realizing that the code is called with the same parameters again and again, stuart could cache these values and not do the calculation over and over
19. spot the error:
D3DRECT* etc = NULL;
while(etc == NULL)
ForceRunRenderThread();;
etc needs to be volatile! Otherwise it wouldn't reload it!
14. Ok, Im impressed with Stuart. Milestone-opt crash in function HUFF decompress. Look at memory start, look at where the chunk ends. Look at raw memory, it will show you where valid ram ends and another page begins. Is the acsess beyond that point? Bingo!!
15. Msvsmon. To get this working takes a few tricks. First zip up the whole x86 folder from c:\program files\microsoft visual studio 8\common7\remote debugging and give it to the remote guy
Have him unzip it and run msvsmon with /noauth /anyuser
In Visual Studio, go tools->attach to process->remote debugging and put in the computer name from msvsmon, like eac-1009022-xp for instance
16. Not sure about this case, but in general process explorer (using find -> find handle or dll ) can pick up what process is holding onto a particular file
http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
17. Load-Hit-Store (LHS) - a slowdown that occurs when load instructions occur after stores to the same memory location
18. Dont do the color exponent in the .a component. Its slow on the PS3
19. For god's sake, always initialize variables in the CTOR!
20. qSafePointer<SimObject, KartEffectsComponent> - the first parameter is supposed to be a base pointer of the second. They are unrelated and this code stomped the vtable. Check your code carefully and don't use C casts. This was a brutally hard to track down crash!