On 29.04.2016 12:16, Aaryaman Vasishta wrote:
On Fri, Apr 29, 2016 at 12:56 PM, Stefan Dösinger <stefandoesinger@gmail.com mailto:stefandoesinger@gmail.com> wrote:
> Am 28.04.2016 um 20:17 schrieb Aaryaman Vasishta <jem456.vasishta@gmail.com <mailto:jem456.vasishta@gmail.com>>: > > + if (texture->d3drm && texture->initialized) > + IDirect3DRM_Release(texture->d3drm); I thought the idea was to use AddDestroyCallback instead of a flag to control the Release call. Do I remember this incorrectly, or what's the reason for going back to a flag? Also, what's the difference between image != NULL and initialized? Or, in a later stage when you have initFromTexture or what it is called, image != NULL || ddraw_texture != NULL?AddDestroyCallback would be used to destroy the image struct, which will be used when InitFromFile will be implemented. Since the image here is provided by the application, there wasn't any need to use a destroy callback right now.
texture->initialized is only used to indicate whether InitFrom* was called on texture or not. As you can see from the tests, d3drm AddRef's IDirect3DRM only after InitFrom* is called. (I had initially thought that CreateObject would do that, but the tests say otherwise).
Since we needed the reference to IDirect3DRM when AddRefing it during the InitFrom* calls, I decided to initialize texture->d3drm at CreateObject without AddRefing it there. So if someone decides to release a texture created using CreateObject but not initialized using InitFrom*, the texture->initialized member will prevent d3drm from releasing texture->d3drm.
What will happen if you release IDirect3DRM before calling InitFrom*, and then call InitFrom* expecting already released IDirect3DRM to be valid?
> IDirect3DRM_AddRef(texture->d3drm); > + > + if (texture->image) > + return D3DRMERR_BADOBJECT; Afair the ref leak here is intentional. If it is, I think it's worth adding a comment.Right, I will add comments above the related test as well.
Cheers, Aaryaman