Moving swiftly on, delay loaded DLLs are also awesome. My "engine" now supports delay loading of D3D and D3DX and gives pretty errors if either DLL is AWOL. Well, it does for D3DX, I don't have any PCs withouth D3D9.dll on them to test...
Next up, I'd like to get some call stacks logged in my memory manager, which would be nice, and would mean I can get rid of my NEW macro (Which logs the current file, line and function, then calls new) completely.
I also need to get my timer class working, which will use QueryPerformanceCounter. Which means I need to deal with all the associated problems it has, such as the timer skipping backwards or forwards several seconds, it returning different results when running on multiprocessor or dual core systems, etc.
Should I really lock my main thread to CPU 1? That seems to be the usual way to do it, but it sounds like a terrible waste of the main thread...
at application startup, and then:
at termination, good old timeGetTime() returns results that are suprisingly accurate (i.e. to within a couple of hundreths of a second). To my knowledge this does not suffer from the multi-core problems that QPC does.
Could be wrong about that though. Just thought I'd mention it.
Glad to hear you've got your PC working. Painful when they bugger up.