> > We have an > > IDirect3DDevice?_AddRef call in CreateSurface / CreateTexture... Native > > seems to have this AddRef call in IDirect3DResource_AddRef: > > > > if(oldref == 0) IDirect3DDevice8_AddRef(This->myDevice); > > > > I guess this is the first thing we have to change. > > Not sure how you read that from the test. Not from this test, but I had a test which did this:
CreateVertexBuffer(&vb) // ref++ Release(vb) // ref-- AddRef(vb) // ref++ CreateVertexBuffer(&vb) //ref++ SetStreamSource(device, 0, vb); //ref unchanged Release(vb) //ref-- GetStreamSource(device, 0, &vb);//ref++ and check the device refcount after each call, with the results from above. I didn't send the test because it did an incorrect thing(release to 0, then addref). > It could just be that the surface object is only created on the first > call to GetRenderTarget. Note that in this test we don't do any actual > rendering, so it's not impossible that in a typical application the > depth stencil would already be created the moment GetRenderTarget is > called. Yeah, I mentioned that. But I suspect that the surface resources are created with the device, just that the COM object is constructed on the first GetRenderTarget call. > > It could be that the implicit render target and auto depth stencil COM > > objects are not COM objects in d3d's internal management and that they > > are constructed in the first call to GetRenderTarget. But we won't be > > able to do that. Or well, we can do it in d3d8.dll and d3d9.dll, but not > > in wined3d.dll. > > Sure we can. Regular surfaces are currently created with a callback to > d3d8 / d3d9 as well. Yes, but some methods in WineD3D need the back buffer and the front buffer implementation pointer, like Present or LockRect/UnlockRect > I wonder what happens if you release the surface you get from > GetDepthStencilTarget, and then try to do some rendering with the > device. I suspect that it won't have any effect(except that the refcount falls to 0)
pgpqQprvf1tNS.pgp
Description: PGP signature