This is just a quick post about a couple of silly bugs I found.
std::vector<FAIL>
In experimenting with the Ballmer Peak yesterday, I finally realized what was corrupting my serialized data. It was frustrating, because Every other value besides my animation key frames were serialized correctly. In viewing their data, only corrupt values could be seen. The correct number of keyframes were being serialized, but not the internal data.
I would watch it serialize out in one function call, and come back in in another. Different. What was different? My binary importer/exporter for my model system isn't a full-fledged serializer like my typical serialization systems. It's meant to be quick and dirty, and it bit me. It didn't support a Serialize() method on the object for recursive object definitions, it simply assumed POD types for everything hi-level which allowed what is tantamount to a memcpy.
The problem is, my data-structure contained an std::vector. I was serializing the pointers / junk members of the std::vector. This problem would have been hidden if it weren't for the fact that I was serializing data out and reading it right back it. That's because with deterministic execution and "dynamic base" turned off in your compiler, your pointers will usually end up being the same until user-input or random values interfere.
Only on the Surface
I always forget this... whenever you have any crashes related to DirectX, the HRESULTs only say "Invalid Call", crank up your DirectX warnings output in the control panel after switching to Debug runtimes.
I was getting a device reset crash in WM_EXITSIZEMOVE and for the life of me couldn't figure out what I wasn't reseting. After remembering to turn on debug runtimes, DirectX told me immediately: my render target surface wasn't being released and reacquired.
No comments:
Post a Comment