Opening Explorer And Selecting A File

Can be done one of two ways.

ShellExecute(hwnd, 0, "explorer.exe", "/select,pathandfilename", NULL, SW_SHOWNORMAL);

Or:

wchar_t wpath[MAX_PATH];
MultiByteToWideChar(CP_UTF8, 0, path, -1, wpath, MAX_PATH);
ITEMIDLIST* hIdList = SHSimpleIDListFromPath(wpath);
SHOpenFolderAndSelectItems(hIdList, 0, 0, 0);
ILFree(hIdList);

Not sure as I'm a fan of the newer shell APIs.

Sign Extention For Fun And Profit

An unexpected bug may come from code that looks like the following:

S32 My32BitInt = somenumber;
U32 Other32BitInt = anothernumber;
U64 MyLargeNumber = (U64)Other32BitInt + (U64)My32BitInt;

Spot the bug?

The code might not execute as expected - I don't know if this is spec or not, but the cast to U64 might not be a zero extend as you might expect - as the target is unsigned. In the above instance, we encountered a bug where the compiler was using cdq (sign extend), which when the value happens to be large enough, ends up adding a very large number.

To ensure zero extend, cast to unsigned of the same bit size beforehand:
U64 myval = (U64)(U32)My32BitInt;

Clamping isn't enough

Sometimes you might think that its enough to clamp an uninitialized variable to a known range, for instance [0, 1]. You might then think that you don't need no stinkin initializer, I got this handled.

I'm here to tell you that this is not sufficient.

Turns out floating point values have Special Places, where you can't ever touch. For instance, QNAN. Any operation on a QNAN is a QNAN, so these tend to migrate, and what's more, is since the number of possible 4 byte values that will give you a QNAN is fairly small, this bug will appear quite sporadically.

In my case, it would turn the entire game world black (or white, depending), as the value in question was the desaturation lerp parameter. Nominally clamped to [0, 1], when passed as a QNAN, it makes it all the way to the pixel shader, to turn the color of anything affected by the material to QNAN. Sweet action.