I hadn't noticed this when I was working on my tessellated terrain, but looking back at some screenshots I took in wireframe mode, that tessellation scheme does show up.
At the time, I was working about half the time on a DX10-grade card that couldn't do hardware tessellation, so I wound up spending a fair amount of time doing an adaptive cpu-side LOD system. It's more work, particularly stitching up the edges, and the performance wasn't as good, but if controlling the tessellation is essential, that way you can subdivide however you choose.
Out of curiosity, why would the alternate tessellation be better for your heightmap? I don't really know anything about Havok
Nice work with the hieghtmap LODs, back in my dx9 days i did something like that. If i don'f find some hardware based solution, I'm going to use a similar method. I have all the heightmap data for physics near the camera, i upload them for the for the gpu, maybe only for the close chunks, and use the tesselation for distant parts.
Havok has a very simple hieghtfield shape I'm using, the 'hkpTriSampledHeightFieldCollection'. It only needs the heightmap dimensions,cellsize, and the triangle winding. So all the cell must be divided into triangles from topright-bottomleft or topleft-bottomright. It is quite fast to create, fully dynamic because it uses the heightmap data the user has, no need for uploading or preprocessing. My game is procedurally generates terrain, so i need all the speed.
I found GDI+'s Bitmap class extremly easy to use, it can load images from more formats (i use it to load png's to create texture arrays for dx11). It is supported from winXP and above. No need for external lib, but for windows only ofc.
Do you see the triangles without this blending turned on?
If not, then 2 quick tips: forgot to transpose the viewprojection matrix, or forgot to set some constant buffer to the proper shaders. At least those are my main 2 sources of pain nowadays.
You can turn on dx debug in sdk->utilities->Directx control panel, if you haven't already. I got some usefull info about not setting the proper patch type for my hull shader, which made the driver reset, so it can be usefull,but not a magic bullet.
Because you can play one sound buffer more than one at a time (ie. many ppl shooting with the same gun), i would separate the storage and the sounds playing in the 3d/2d space. Basicly i would add an extra class with 3d position etc. and a pointer/index to an 'Audio' class. This would represent a playing sound instance in the game.
Basicly the only difference between the running and the not running version is the 'playAudio' function ends, and THEN the sound is not playing anymore. That suggest that something on the stack gets freed what is not supposed to. My tip is the "Wave buffer" object's destructor is the culprit. I think you must store your sound data until you playing it.
Try making 'buffer' global for example, see if it works.
'memcpy(&pVoid..' has a (big) problem: pVoid is a pointer, and you wanto to copy data to where it points, not where the pVoid variable is stored. Use pVoid instead of &pVoid. With your current code, you overwrite pVoids value, so it points somewhere else, and trash some remaining memory after pVoid, so you end up with that mean message.