Direct3DDevice8::Release about d3d8to9

[CookiePLMonster]

I tested that and noticed it in fact crashes on app exit when the device is killed (wrapper's refcount is 0, underlying interface's refcount is 2)... So the question is, where do the refcounts desync?

[CookiePLMonster]

UPDATE: The exit crash seems to solved by re-reading the reference counter after releasing render target/depth target with myRef = InterlockedExchange(&_ref, ref);. Thus, the initial question in the issue is valid once again.

[crosire]

Was done because of the crash you mentioned and at the time this was the quickest solution.

[CookiePLMonster]

Something as simple as inserting this

// Obtain the reference counter after releasing surfaces again myRef = InterlockedExchange(&_ref, ref);

below proxy->Release() seems to work great though. One could just --myRef when releasing rendertargets but I feel re-reading the actual refcount is safer.

[crosire]

Technically it would be better to put it one line above the _proxy->Release() call to keep constistent with all other Release implementations. Should still work.

[CookiePLMonster]

Sure. It matters little but if consistency can be preserved, best to go for it!

[CookiePLMonster]

While you're here, I know it's not really related but I'm not a linkedin user and leaving a message here is probably the best - are you fine with a game specific fork of d3d8to9 maintained in a never-to-be-merged branch? Here it's about a GameMaker generated executable so we don't really have control on how d3d8 calls are issued (and there is a LOT of redundancy which cannot be easily avoided) and it'd be easiest to address from inside this dll.

[CookiePLMonster]

I have identified the root cause of the refcount issue (device release ended up in a would-be infinite loop only bailed from thanks to refcount underflow) and updated #2 to include the fix!

[crosire]

@CookiePLMonster Sure, you can use it however you see fit as long as it follows the license.