Hi,
if (This->stateBlock != NULL ) { if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] ==
resource) {
TRACE("Vertex buffer released whlst bound to a state block stream %d\n", streamNumber); TRACE("Vertex buffer released while bound to a state block stream %d\n",
streamNumber);
This->stateBlock->streamSource[streamNumber] = 0; } }
This is not your code, but this is wrong, even if the msdn says otherwise. Once I had a hacky test for testing this stuff. What my test did was:
1) Create a Vertex buffer 2) check device refcount: increased 3) Bind to a stream 4) check the vb refcount: unchanged(still 1) 5) release the vb(release returns 0) 6) check the device refcount: decreased 7) GetStreamSource: returns old vertex buffer 8) Check device refcount: increased 9) check vb refcount: 1
It seems that the stream source is not uset if the buffer is released. And it seems that ms implements holding the reference to the device in VertexBuffer::AddRef
if(oldref == 0) IDirect3DDevice9_AddRef(This->device)
or something like that, simmilar to our release. CreateVertexBuffer seems to init the ref to 0 and call VertexBuffer::AddRef.
To be sure I did tested the following too: 1) Create VB 2) Check device refcount: increased 3) Release vb. Device refcount decremented 4) AddRef the just destroyed vb: Device refcount increased
I didn't submit the test because it doesn't contain anything really new, and the GetStreamSource which returns the released buffer works just by chance.
Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as any app depending on that would randomly break on windows.
Or is there some COM magic behind this, which keeps objects from beeing destroyed?
Stefan