"Ann and Jason Edmeades" us@the-edmeades.demon.co.uk writes:
I have changed the design so only the Direct3D<interface><8/9> ones extend IUnknown, and so there is no reference counting of the IWineD3D objects.
I don't think that's a good idea. If you are using COM interfaces then you need to use them the COM way, this means IWineD3D should derive from IUnknown and freeing it should be done through the Release method. If you don't want to use standard COM then don't declare COM interfaces at all, create your own mechanism.
Instead, when any Direct3D<interface><8/9> is Released to zero, then it calls a Free method in its WineD3D equivalent interface. I also changed the IWineD3D interface to contain, as a void *, a pointer to its 'parent' (by which I mean the Direct3D8/9 interface) plus a function (GetParent) which returns that pointer.
This is bad too, you shouldn't use void*, you should use proper types, at the very least IUnknown*, but preferably define an IWineD3DUser interface or something like that.
I have changed the design so only the Direct3D<interface><8/9> ones
extend
IUnknown, and so there is no reference counting of the IWineD3D objects.
I don't think that's a good idea. If you are using COM interfaces then you need to use them the COM way, this means IWineD3D should derive from IUnknown and freeing it should be done through the Release method. If you don't want to use standard COM then don't declare COM interfaces at all, create your own mechanism.
Well I have an interface, it just doesnt extend IUnknown. Aside from that it is identical to any other com interface - I dont want to export all the functions provided. Is it 100% required to extend IUnknown (and would this mechanism not be equivalent to creating my own :-) )?
I really dont want reference counting on the objects either as it needs to be forced that the reference counting is done on the IDirect3D* versions. I ran out of ideas, and just dropped IUnknown!
Instead, when any Direct3D<interface><8/9> is Released to zero, then it calls a Free method in its WineD3D equivalent interface. I also changed
the
IWineD3D interface to contain, as a void *, a pointer to its 'parent' (by which I mean the Direct3D8/9 interface) plus a function (GetParent) which returns that pointer.
This is bad too, you shouldn't use void*, you should use proper types, at the very least IUnknown*, but preferably define an IWineD3DUser interface or something like that.
I would be happy with IUnknown *, but cant see any way to use my own type other than a straight typedef to either void * or IUnknown. The problem is wined3d needs to deal with both d3d8 and d3d9 interfaces and cannot #include both d3d8 and d3d9 header files due to conflicts. We must store a pointer which can go from the IWineD3D<interface> object to the IDirect3D<interface>Object. I am happy to change it to anything, IUnknown * is as good as any - Would this be ok?
Jason
"Ann and Jason Edmeades" us@the-edmeades.demon.co.uk writes:
Well I have an interface, it just doesnt extend IUnknown. Aside from that it is identical to any other com interface - I dont want to export all the functions provided. Is it 100% required to extend IUnknown (and would this mechanism not be equivalent to creating my own :-) )?
No, you really should extend IUnknown, it's going to be massively confusing otherwise.
I really dont want reference counting on the objects either as it needs to be forced that the reference counting is done on the IDirect3D* versions. I ran out of ideas, and just dropped IUnknown!
Please do proper reference counting, it doesn't cost anything, and someday we might need it. If you can't use standard ref counting it probably means you are doing something wrong.
I would be happy with IUnknown *, but cant see any way to use my own type other than a straight typedef to either void * or IUnknown. The problem is wined3d needs to deal with both d3d8 and d3d9 interfaces and cannot #include both d3d8 and d3d9 header files due to conflicts. We must store a pointer which can go from the IWineD3D<interface> object to the IDirect3D<interface>Object.
You don't have to include any of the headers, that's the whole point of interfaces. Just have wined3d export an IWineD3DUser interface and have both d3d8 and d3d9 implement it. wined3d doesn't have to know anything about the implementation, just like d3d8 and d3d9 don't have to know anything about the implementation of IWineD3D.
No, you really should extend IUnknown, it's going to be massively confusing otherwise.
Ok, so if I put back the IUnknowns, are you happy if the AddRefs in the d3dx calls AddRef on the WineD3D version?
Please do proper reference counting, it doesn't cost anything, and someday we might need it. If you can't use standard ref counting it probably means you are doing something wrong.
The problem I was trying to avoid was someone doing an addref for the wined3d object, but not the d3dx equivalent, as there really is a strict mapping between instances. If I put back the IUnknown, then addref/release in wined3d should NEVER be called from within wined3d - Does this make sense?
You don't have to include any of the headers, that's the whole point of interfaces. Just have wined3d export an IWineD3DUser interface and have both d3d8 and d3d9 implement it. wined3d doesn't have to know anything about the implementation, just like d3d8 and d3d9 don't have to know anything about the implementation of IWineD3D.
I may have misunderstood what you mean by this paragraph and I think I am getting confused. The wined3d layer needs a way of passing back the d3dx equivalent, and therefore it needs to store it in the _impl structure. Here, I dont care what it is called, but since internally to wined3d it only ever needs the IUnknown methods, that does make sense. However, it needs to expose it somehow, which is why I added a GetParent call to each of the interfaces. I *think* you mean I could define a wined3d interface with just that method in, and then have IWineD3D inherit from IWineD3DGetParent inherit from IUnknown. If this is right, for a single method is it worth it?
Sorry ig I missed your point here Jason
"Ann and Jason Edmeades" us@the-edmeades.demon.co.uk writes:
Ok, so if I put back the IUnknowns, are you happy if the AddRefs in the d3dx calls AddRef on the WineD3D version?
I don't really understand why you'd need that.
The problem I was trying to avoid was someone doing an addref for the wined3d object, but not the d3dx equivalent, as there really is a strict mapping between instances. If I put back the IUnknown, then addref/release in wined3d should NEVER be called from within wined3d - Does this make sense?
Well, you have to follow the rules: when a pointer to the interface is returned you AddRef it, and when you no longer need the pointer you Release it. If all you ever do is store the pointer in the d3d interface and release it when the d3d interface is freed, then you'll never have other AddRef/Release calls. Just don't try to invent new rules, that won't work right.
I may have misunderstood what you mean by this paragraph and I think I am getting confused. The wined3d layer needs a way of passing back the d3dx equivalent, and therefore it needs to store it in the _impl structure. Here, I dont care what it is called, but since internally to wined3d it only ever needs the IUnknown methods, that does make sense. However, it needs to expose it somehow, which is why I added a GetParent call to each of the interfaces. I *think* you mean I could define a wined3d interface with just that method in, and then have IWineD3D inherit from IWineD3DGetParent inherit from IUnknown. If this is right, for a single method is it worth it?
No, it's not IWineD3D that inherits from it, it's the users, so in this case the d3d8 and d3d9 interfaces. So IWineD3D::CreateDevice will take a IWineD3DParent* pointer, and IWineD3DDevice::GetParent will return the same IWineD3DParent*, and the interface that d3d8/d3d9 are passing as parent needs to implement IWineD3DParent.
If you are sure you'll never want to do anything with the parent other than AddRef/Release then it can be an IUnknown* instead, but defining a separate interface lets you add methods later on that will allow wined3d to call functions in d3d8/d3d9 without having to know about these dlls.
-
Alexandre Julliard -
Ann and Jason Edmeades