Re: [WINED3D 6/8] Stateblock support for dmap and vtf samplers
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
+ IWineD3DDevice_SetTexture(iface, D3DDMAPSAMPLER, NULL); I don't think wined3d should depend on d3d9 includes. There are currently a number of places in wined3d where we do use d3d9 constants, but at least for new code I don't think we should add dependencies on d3d9 includes.
H. Verbeet wrote:
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
+ IWineD3DDevice_SetTexture(iface, D3DDMAPSAMPLER, NULL); I don't think wined3d should depend on d3d9 includes. There are currently a number of places in wined3d where we do use d3d9 constants, but at least for new code I don't think we should add dependencies on d3d9 includes. This old code/new code pattern doesn't make any sense to be honest. Either we depend on d3d9 includes or we don't. If there is a problem, it needs to be solved now, for the entire codebase. If there isn't a problem, I should be free to use whatever constants are necessary.
There aren't "a number of places" - it's practically the entire dll right now. So, I think it's a lost cause, unless we really try to pursue this, and remove the d3d9.h from the include list so it won't compile.
Ivan Gyurdiev wrote:
H. Verbeet wrote:
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
+ IWineD3DDevice_SetTexture(iface, D3DDMAPSAMPLER, NULL); I don't think wined3d should depend on d3d9 includes. There are currently a number of places in wined3d where we do use d3d9 constants, but at least for new code I don't think we should add dependencies on d3d9 includes. This old code/new code pattern doesn't make any sense to be honest. Either we depend on d3d9 includes or we don't. If there is a problem, it needs to be solved now, for the entire codebase. If there isn't a problem, I should be free to use whatever constants are necessary.
There aren't "a number of places" - it's practically the entire dll right now. So, I think it's a lost cause, unless we really try to pursue this, and remove the d3d9.h from the include list so it won't compile. By the way, I have no problem choosing this second option. If there's interest let me know, and I'll change all the underlying types in one go.
<but this is completely orthogonal to this patch>
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
There aren't "a number of places" - it's practically the entire dll right now. So, I think it's a lost cause, unless we really try to pursue this, and remove the d3d9.h from the include list so it won't compile. By the way, I have no problem choosing this second option. If there's interest let me know, and I'll change all the underlying types in one go. Sure, but as you noted in your previous mail, it's quite a lot of code.
Am Dienstag 03 Oktober 2006 13:11 schrieb H. Verbeet:
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
There aren't "a number of places" - it's practically the entire dll right now. So, I think it's a lost cause, unless we really try to pursue this, and remove the d3d9.h from the include list so it won't compile.
By the way, I have no problem choosing this second option. If there's interest let me know, and I'll change all the underlying types in one go.
Sure, but as you noted in your previous mail, it's quite a lot of code. My experiance from moving the types that didn't exist in d3d.h to wined3d_types is that you need to move them type by type, and you'll still end up with 40k patches. Another issue is that those changes tend to collide will all other patches.
I think we should get rid of d3d9.h (and ddraw.h), especially when looking forward to d3d10. That said, it took me approximately 6 weeks to get the types ready for the ddraw merge. That was with cvs though, with git it should be MUCH easier.
On 03/10/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I think we should get rid of d3d9.h (and ddraw.h), especially when looking forward to d3d10. That said, it took me approximately 6 weeks to get the Yes, d3d10 would be my main concern for not including d3d9 headers, aside from the fact that wined3d simply shouldn't depend on d3d7/8/9 in any way.
H. Verbeet wrote:
On 03/10/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
I think we should get rid of d3d9.h (and ddraw.h), especially when looking forward to d3d10. That said, it took me approximately 6 weeks to get the Yes, d3d10 would be my main concern for not including d3d9 headers, aside from the fact that wined3d simply shouldn't depend on d3d7/8/9 in any way.
I've tried sorting the headers out myself. It took a month and I ended up doing the whole tangle in one attempt (approx. 29,000 lines of code changed) but it's not like a patch of that size is going to be accepted :D
Stefan Dösinger wrote:
Am Dienstag 03 Oktober 2006 13:11 schrieb H. Verbeet:
On 03/10/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote:
There aren't "a number of places" - it's practically the entire dll right now. So, I think it's a lost cause, unless we really try to pursue this, and remove the d3d9.h from the include list so it won't compile.
By the way, I have no problem choosing this second option. If there's interest let me know, and I'll change all the underlying types in one go.
Sure, but as you noted in your previous mail, it's quite a lot of code.
My experiance from moving the types that didn't exist in d3d.h to wined3d_types is that you need to move them type by type, and you'll still end up with 40k patches. Another issue is that those changes tend to collide will all other patches. You guys want to do that now aka before Wine 1.0 especialy if it is that much code. That's why Alexandre wanted to have the Win64 printf format fixes done before 1.0. Those will amount to over 200k of patches ...
I think we should get rid of d3d9.h (and ddraw.h), especially when looking forward to d3d10. That said, it took me approximately 6 weeks to get the types ready for the ddraw merge. That was with cvs though, with git it should be MUCH easier. Can this be done by anybody or does one need to be a Wine D3D guru for that? If the task is easy it would be a good addition to http://wiki.winehq.org/JanitorialProjects .
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
Can this be done by anybody or does one need to be a Wine D3D guru for that? If the task is easy it would be a good addition to http://wiki.winehq.org/JanitorialProjects . It is nothing special. Just remove the #include "d3d9.h", and for every data type D3DFOOBAR that is missing add a WINED3DFOOBAR type to include/wine/wined3d_types.h and modify include/wine/wined3d_interface.h and the code in dlls/wined3d/ to use it. Add typecasts in dlls/ddraw, dlls/d3d8 and dlls/d3d9 as necessary.
On 03/10/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Can this be done by anybody or does one need to be a Wine D3D guru for that? If the task is easy it would be a good addition to http://wiki.winehq.org/JanitorialProjects . It is nothing special. Just remove the #include "d3d9.h", and for every data type D3DFOOBAR that is missing add a WINED3DFOOBAR type to include/wine/wined3d_types.h and modify include/wine/wined3d_interface.h and the code in dlls/wined3d/ to use it. Add typecasts in dlls/ddraw, dlls/d3d8 and dlls/d3d9 as necessary. There are probably a couple of macros as well, but you should be able to just copy those over as well. For the most part it comes down to duplicating code and giving it a slightly different name :-)
participants (5)
-
H. Verbeet -
Ivan Gyurdiev -
Michael Stefaniuc -
Phil Costin -
Stefan Dösinger