October 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface

by Fabian Maurer

Hi Stefan, > Here I can mostly refer to the other d3d libraries (e.g. d3d8) that do > not use typedefs for structs. We had a discussion about this on > wine-devel a while ago that I could not find in the archive, but here's > e.g. the kernel's guide on this: > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#typedefs . > > I don't think we have an official policy, and as you correctly point out > a lot of Wine code (and Microsoft's headers) use typedefs. But since > Henri is the d3d maintainer his word counts here. Thanks for the explanation, I'm fine with that. I'll rework this. > (It certainly isn't helpful that > https://wiki.winehq.org/Wine_Developer%27s_Guide/COM_in_Wine#Implementing_a_ > COM_interface. contains loads of old suggestions) > > >>> +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, > >>> void **ppv) +{ > >>> + d3dx8 *This = impl_from_ID3DX8(iface); > >> > >> Please use lowercase variable names. > > > > Again, it's like this in 95% of all other cases. I'll change it if you > > want, I just wanted it to remain consistent with the existing code. > > Similarly I can only refer to ddraw/d3d8/9/10/11 here, but other places > in Wine certainly differ. No problem, I'll change that. It's not a problem to use words that are reserved words in C++ since we're using only plain C, right? > > Mind explaining why? The wiki states that "Messages in this class are > > meant to signal unimplemented features, known bugs, etc. They serve as a > > constant and active reminder of what needs to be done." This sounds > > fitting for me. > It's largely because some applications query various (sometimes even > app-internal) interfaces and expect a failure, e.g. as a way to detect > what kind of object they got out of their internal data structures. > Printing a FIXME in QueryInterface is just as likely to mislead a user > or developer into thinking the interface should be supported as it is to > point out a bug. > > If you know an interface should be supported, e.g. through tests or > because the documentation says so, but you don't implement it, that > would be a case for a FIXME. Ah right, I just assume it's required since it's queried, but it makes sense what you say. I'll turn it in to the regular warning in these cases then. > >>> +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8 > >>> *device, + LONG hFont, D3DXFont **retFont) > >> > >> Please use lowercase parameter names, and avoid the stray 'h'. > > > > I mostly just took the official names, want me to edit all of them? > > Wouldn't be an issue for me, just need to know. > > Yeah, we try to keep a distance from Microsoft's formatting as far as > possible without breaking compatibility. Renaming a parameter keeps the > code compatible to Microsoft's headers, but e.g. renaming a struct > member would break things. That's good to know, because I don't like the formatting either. I'll rewrite that into proper names then. > This is mostly an issue for writing our own headers because it is > technically possible (but not allowed) to copypaste them from > Microsoft's headers. > > > Maybe, I'm not good with trace formatting. Is there a list for which type > > I > > should use what? I'd really appreciate that, maybe in the wiki? I didn't > > find anything. > > Flags are ORed bits. so %#x is the canonical way to print them. You'll > get output like 0x105 and see that there are flags 0x100, 0x004 and > 0x001 set. With %i you get "261", which is much harder to read (256 | 4 > > | 1). (the # prints "0x105" instead of "105", which makes it clear that > > it is a hexadecimal number) What about enums/LONG/int, is this all "%d"? Thanks for the detailed explanations. Regards, Fabian Maurer

Oct. 31, 2017

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface

by Stefan Dösinger

Hi Fabian, I'm not Henri, but I'll try to answer your questions: Am 2017-10-31 um 20:48 schrieb Fabian Maurer: >> Please don't typedef structures just to save keystrokes. > > Mind explaining the reason for this? It's like this in a lot of other places, > and I'm curious to why you prefer it to not be a typedef. Here I can mostly refer to the other d3d libraries (e.g. d3d8) that do not use typedefs for structs. We had a discussion about this on wine-devel a while ago that I could not find in the archive, but here's e.g. the kernel's guide on this: https://www.kernel.org/doc/html/v4.10/process/coding-style.html#typedefs . I don't think we have an official policy, and as you correctly point out a lot of Wine code (and Microsoft's headers) use typedefs. But since Henri is the d3d maintainer his word counts here. (It certainly isn't helpful that https://wiki.winehq.org/Wine_Developer%27s_Guide/COM_in_Wine#Implementing_a…. contains loads of old suggestions) >>> +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, >>> void **ppv) +{ >>> + d3dx8 *This = impl_from_ID3DX8(iface); >> >> Please use lowercase variable names. > > Again, it's like this in 95% of all other cases. I'll change it if you want, I > just wanted it to remain consistent with the existing code. Similarly I can only refer to ddraw/d3d8/9/10/11 here, but other places in Wine certainly differ. > Mind explaining why? The wiki states that "Messages in this class are meant to > signal unimplemented features, known bugs, etc. They serve as a constant and > active reminder of what needs to be done." This sounds fitting for me. It's largely because some applications query various (sometimes even app-internal) interfaces and expect a failure, e.g. as a way to detect what kind of object they got out of their internal data structures. Printing a FIXME in QueryInterface is just as likely to mislead a user or developer into thinking the interface should be supported as it is to point out a bug. If you know an interface should be supported, e.g. through tests or because the documentation says so, but you don't implement it, that would be a case for a FIXME. >>> +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8 >>> *device, + LONG hFont, D3DXFont **retFont) >> >> Please use lowercase parameter names, and avoid the stray 'h'. > > I mostly just took the official names, want me to edit all of them? Wouldn't > be an issue for me, just need to know. Yeah, we try to keep a distance from Microsoft's formatting as far as possible without breaking compatibility. Renaming a parameter keeps the code compatible to Microsoft's headers, but e.g. renaming a struct member would break things. This is mostly an issue for writing our own headers because it is technically possible (but not allowed) to copypaste them from Microsoft's headers. > Maybe, I'm not good with trace formatting. Is there a list for which type I > should use what? I'd really appreciate that, maybe in the wiki? I didn't find > anything. Flags are ORed bits. so %#x is the canonical way to print them. You'll get output like 0x105 and see that there are flags 0x100, 0x004 and 0x001 set. With %i you get "261", which is much harder to read (256 | 4 | 1). (the # prints "0x105" instead of "105", which makes it clear that it is a hexadecimal number)

Oct. 31, 2017

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface

by Fabian Maurer

Hi Henry, thanks for the quick reply. > > +typedef struct > > +{ > > + ID3DX8 ID3DX8_iface; > > + LONG ref; > > +} d3dx8; > > Please don't typedef structures just to save keystrokes. Mind explaining the reason for this? It's like this in a lot of other places, and I'm curious to why you prefer it to not be a typedef. > > +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, > > void **ppv) +{ > > + d3dx8 *This = impl_from_ID3DX8(iface); > > Please use lowercase variable names. Again, it's like this in 95% of all other cases. I'll change it if you want, I just wanted it to remain consistent with the existing code. > > + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppv); > > + > > + *ppv = NULL; > > + > > + if (IsEqualGUID(riid, &IID_IUnknown)) > > + *ppv = &This->ID3DX8_iface; > > + else if(IsEqualGUID(riid, &IID_ID3DX8)) > > + *ppv = &This->ID3DX8_iface; > > + else if(IsEqualGUID(riid, &IID_IPersistPropertyBag)) > > + FIXME("No interface for IID_IPersistPropertyBag\n"); > > + else if(IsEqualGUID(riid, &IID_IPersistStreamInit)) > > + FIXME("No interface for IID_IPersistStreamInit\n"); > > + else > > + FIXME("No interface for %s\n", debugstr_guid(riid)); > > Not implementing an arbitrary interface is a WARN at best. Mind explaining why? The wiki states that "Messages in this class are meant to signal unimplemented features, known bugs, etc. They serve as a constant and active reminder of what needs to be done." This sounds fitting for me. > > + if (*ppv) > > + { > > + IUnknown_AddRef((IUnknown *)(*ppv)); > > + return S_OK; > > + } > > + > > + return E_NOINTERFACE; > > +} > > I think Nikolay already hinted at this, but this is fairly different > from the canonical QueryInterface() implementation, especially for an > object that only implements a single interface. But they don't only implement one interface, they have those other GUIDs that are queried, no? > > +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8 > > *device, + LONG hFont, D3DXFont **retFont) > > Please use lowercase parameter names, and avoid the stray 'h'. I mostly just took the official names, want me to edit all of them? Wouldn't be an issue for me, just need to know. > > +static HRESULT WINAPI d3dx8_AssembleShaderFromFile(ID3DX8 *iface, BSTR > > file, LONG flags, BSTR *log, + D3DXBuffer **constants, D3DXBuffer > > **ppVertexShader) > > +{ > > + FIXME("(%s, %i, %p, %p, %p): stub!\n", debugstr_w(file), flags, log, > > constants, ppVertexShader); > I certainly have my preferences when it comes to trace formatting, but > I think "%i" is questionable for flags regardless of preference. Maybe, I'm not good with trace formatting. Is there a list for which type I should use what? I'd really appreciate that, maybe in the wiki? I didn't find anything. > > +static const ID3DX8Vtbl ID3DX8_Vtbl = > > "d3dx8_vtbl" > > > +HRESULT d3dx8_create(IUnknown *outer_unk, void **ppv) > > +{ > > + d3dx8 *object; > > + > > + TRACE("(%p,%p)\n", outer_unk, ppv); > > + > > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > > sizeof(d3dx8)); > > "sizeof(*object)" I too took this from already existing code, but I'll change it. Regards, Fabian Maurer

Oct. 31, 2017

Re: [PATCH 1/4] dx8vb: Add stubs for D3DX8 interface

by Henri Verbeet

Perhaps this is sufficiently far removed from core Direct3D that nobody cares, but for what it's worth: On 31 October 2017 at 03:01, Fabian Maurer <dark.shadow4(a)web.de> wrote: > +typedef struct > +{ > + ID3DX8 ID3DX8_iface; > + LONG ref; > +} d3dx8; Please don't typedef structures just to save keystrokes. > +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid, void **ppv) > +{ > + d3dx8 *This = impl_from_ID3DX8(iface); Please use lowercase variable names. > + > + TRACE("(%p/%p)->(%s,%p)\n", iface, This, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + if (IsEqualGUID(riid, &IID_IUnknown)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_ID3DX8)) > + *ppv = &This->ID3DX8_iface; > + else if(IsEqualGUID(riid, &IID_IPersistPropertyBag)) > + FIXME("No interface for IID_IPersistPropertyBag\n"); > + else if(IsEqualGUID(riid, &IID_IPersistStreamInit)) > + FIXME("No interface for IID_IPersistStreamInit\n"); > + else > + FIXME("No interface for %s\n", debugstr_guid(riid)); Not implementing an arbitrary interface is a WARN at best. > + > + if (*ppv) > + { > + IUnknown_AddRef((IUnknown *)(*ppv)); > + return S_OK; > + } > + > + return E_NOINTERFACE; > +} I think Nikolay already hinted at this, but this is fairly different from the canonical QueryInterface() implementation, especially for an object that only implements a single interface. > +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8 *device, > + LONG hFont, D3DXFont **retFont) Please use lowercase parameter names, and avoid the stray 'h'. > +static HRESULT WINAPI d3dx8_AssembleShaderFromFile(ID3DX8 *iface, BSTR file, LONG flags, BSTR *log, > + D3DXBuffer **constants, D3DXBuffer **ppVertexShader) > +{ > + FIXME("(%s, %i, %p, %p, %p): stub!\n", debugstr_w(file), flags, log, constants, ppVertexShader); I certainly have my preferences when it comes to trace formatting, but I think "%i" is questionable for flags regardless of preference. > +static const ID3DX8Vtbl ID3DX8_Vtbl = "d3dx8_vtbl" > +HRESULT d3dx8_create(IUnknown *outer_unk, void **ppv) > +{ > + d3dx8 *object; > + > + TRACE("(%p,%p)\n", outer_unk, ppv); > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(d3dx8)); "sizeof(*object)"

Oct. 31, 2017

Re: [PATCH] wmvcore/tests: Access IWMDRMReader(|2|3) interfaces on Windows.

by Alexandre Julliard

Jefferson Carpenter <jeffersoncarpenter2(a)gmail.com> writes: > Also, does this mean I can't have your job when you retire? Be careful what you wish for ;-) -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2017

Re: [v3] oleaut32: Add ARM support to DispCallFunc().

by Donna Whisnant

Ah... I hadn't tried it on a platform with soft-FP. And true enough, the compiler wouldn't support the VFP coprocessor instructions without hardware floats. It could be made to work with soft-FP too, but would at least be a different function for the assembly language part to one that excludes the VFP coprocessor instructions. I think the correct answer for now would be to do the !defined(__SOFTFP__) in my code, just as described in the discussion at the link you sent. It seems correct since this code is explicitly written for hard-FP. Please let me know if that's acceptable, and I will add that check and submit a v4 of the patch. Also, another thing you will hit, that I mentioned in a previous discussion, is the test suite for this module. Currently, there is the following in tests/typelib.c: static const BOOL is_win64 = sizeof(void *) > sizeof(int); ... /* the function checks the argument sizes for stdcall */ if (!is_win64) /* no stdcall on 64-bit */ { res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 0, types, pargs, &result ); ok( res == DISP_E_BADCALLEE, "DispCallFunc wrong error %x\n", res ); res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 1, types, pargs, &result ); ok( res == S_OK, "DispCallFunc failed %x\n", res ); res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 2, types, pargs, &result ); ok( res == DISP_E_BADCALLEE, "DispCallFunc wrong error %x\n", res ); } However, the stdcall tests have absolutely nothing to do with whether or not it's win64, but rather if the ABI itself supports stdcall or not. In my opinion, I believe there should be a constant defined at the top according to the ABI. I *think* the only platform that supports stdcall like that is i386, so have something like: #ifdef (__i386__) static const BOOL abi_supports_stdcall = TRUE; #else static const BOOL abi_supports_stdcall = FALSE; #endif And then change the 'if' using it to be: if (abi_supports_stdcall) { ... } I hadn't submitted that patch yet, since I didn't know how you wanted to address it. But, if that's an acceptable solution, I would be glad to make a patch for the test suite too. Donna On Tue, Oct 31, 2017, at 05:02, Martin Storsjö wrote: > On Tue, 31 Oct 2017, Alexandre Julliard wrote: > > > Donna Whisnant <dewhisna(a)dewtronics.com> writes: > > > >> Adds ARM ABI support to DispCallFunc() to allow IDispatch invoke calls > >> to succeed on ARM platforms. This change specifically targets only > >> 32-bit little-endian (ARMEL) platform CPUs. It's believed to likely be > >> compatible with big-endian (ARMEB) platforms, but testing for that > >> platform should be completed before enabling. > >> > >> Tested on Raspbian Stretch 2017-09-07 RPi image using a Qemu systemd > >> container to compile and run it on an x86-64 Host.. When running on > >> Raspberry Pi hardware, a 3G/1G split kernel needs to be used for Wine > >> to function. > > > > It breaks the Android build: > > > > arm-linux-androideabi-gcc -c -o typelib.o ../../../wine/dlls/oleaut32/typelib.c -I. -I../../../wine/dlls/oleaut32 \ > > -I../../include -I../../../wine/include -D__WINESRC__ -D_OLEAUT32_ -D_REENTRANT -fPIC -Wall -pipe \ > > -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ > > -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ > > -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret -D__ANDROID_API__=26 -marm > > {standard input}: Assembler messages: > > {standard input}:32: Error: selected processor does not support ARM mode `vldm r3!,{s0-s15}' > > Makefile:516: recipe for target 'typelib.o' failed > > make: *** [typelib.o] Error 1 > > FWIW, this is the same issue as was discussed before here: > https://www.winehq.org/pipermail/wine-devel/2017-September/118872.html > > // Martin

Oct. 31, 2017

Re: [PATCH 4/4] dx8vb: Implement Direct3D8 methods

by Fabian Maurer

> Regarding the GUIDs, some tests would be great, e.g. showing that d3d8 > does not support them, but dx8vb does. I somewhat doubt this is necessary, but sure, why not. Should be easy enough to add. > You'll have a mess on your hands with various getter functions. Luckily > the IDirect3DResource8::{Get/Set}PrivateData methods are helpful for > textures, surfaces, swapchains and buffers, and in d3d8 shaders are > DWORD handles and vertex declarations don't exist. So you shouldn't have > to maintain your own stateblocks. > > D3DSPD_IUNKNOWN is handy for being notified of the destruction of a > resource. You probably do have to keep your own refcounting and test if > it works the same way as in real d3d8. Yes for now it's easy, but it will get more complicated. I still hope I can deal with that, though. Thanks for the tips. Regards, Fabian Maurer

Oct. 31, 2017

Re: [PATCH 4/4] dx8vb: Implement Direct3D8 methods

by Stefan Dösinger

Am 2017-10-31 um 14:11 schrieb Fabian Maurer: >> Why do you need a proxy IDirect3D8 implementation in dx8vb? Is there any >> difference between dx8vb and d3d8? > > The interfaces in dx8vb are different interfaces, with different GUID and > sometimes slightly different method definitions and behavior. I don't know why > they did it that way, but I don't see another way than to have a wrapper for > all of these. If there is an easier way, I'd love to hear it. Hmm, in this case a wrapper is probably the best choice... Regarding the GUIDs, some tests would be great, e.g. showing that d3d8 does not support them, but dx8vb does. You'll have a mess on your hands with various getter functions. Luckily the IDirect3DResource8::{Get/Set}PrivateData methods are helpful for textures, surfaces, swapchains and buffers, and in d3d8 shaders are DWORD handles and vertex declarations don't exist. So you shouldn't have to maintain your own stateblocks. D3DSPD_IUNKNOWN is handy for being notified of the destruction of a resource. You probably do have to keep your own refcounting and test if it works the same way as in real d3d8.

Oct. 31, 2017

Re: [PATCH 4/4] dx8vb: Implement Direct3D8 methods

by Fabian Maurer

> Why do you need a proxy IDirect3D8 implementation in dx8vb? Is there any > difference between dx8vb and d3d8? The interfaces in dx8vb are different interfaces, with different GUID and sometimes slightly different method definitions and behavior. I don't know why they did it that way, but I don't see another way than to have a wrapper for all of these. If there is an easier way, I'd love to hear it. Regards, Fabian Maurer

Oct. 31, 2017

Re: [PATCH 4/4] dx8vb: Implement Direct3D8 methods

by Stefan Dösinger

Hi Fabian, Why do you need a proxy IDirect3D8 implementation in dx8vb? Is there any difference between dx8vb and d3d8? Stefan > Am 31.10.2017 um 00:31 schrieb Fabian Maurer <dark.shadow4(a)web.de>: > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/dx8vb/Makefile.in | 2 +- > dlls/dx8vb/directx8.c | 112 ++++++++++++++++++++++++++++++++++++++----------- > 2 files changed, 89 insertions(+), 25 deletions(-) > > diff --git a/dlls/dx8vb/Makefile.in b/dlls/dx8vb/Makefile.in > index 8438d022f4..33fe651503 100644 > --- a/dlls/dx8vb/Makefile.in > +++ b/dlls/dx8vb/Makefile.in > @@ -1,5 +1,5 @@ > MODULE = dx8vb.dll > -IMPORTS = uuid ole32 > +IMPORTS = uuid ole32 d3d8 > > C_SRCS = \ > d3dx8.c \ > diff --git a/dlls/dx8vb/directx8.c b/dlls/dx8vb/directx8.c > index 338862a4ff..dd50c86008 100644 > --- a/dlls/dx8vb/directx8.c > +++ b/dlls/dx8vb/directx8.c > @@ -21,6 +21,9 @@ > #include "config.h" > > #include "dx8vb_private.h" > +#define __WINE_D3D8TYPES_H > +#define __WINE_D3D8CAPS_H > +#include "d3d8.h" > #include "ocidl.h" > > #include "wine/debug.h" > @@ -36,6 +39,7 @@ typedef struct > typedef struct > { > Direct3D8 Direct3D8_iface; > + IDirect3D8 *direct3d8; > LONG ref; > } direct3d8; > > @@ -95,7 +99,10 @@ static ULONG WINAPI direct3d8_Release(Direct3D8 *iface) > TRACE("(%p/%p)->(): new ref %d\n", iface, This, ref); > > if (!ref) > + { > + IDirect3D8_Release(This->direct3d8); > HeapFree(GetProcessHeap(), 0, This); > + } > > return ref; > } > @@ -104,91 +111,145 @@ static ULONG WINAPI direct3d8_Release(Direct3D8 *iface) > > static HRESULT WINAPI direct3d8_RegisterSoftwareDevice(Direct3D8 *iface, void *initializeFunction) > { > - FIXME("(%p): stub!\n", initializeFunction); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_RegisterSoftwareDevice(This->direct3d8, initializeFunction); > + > + FIXME("(%p) -> (%x)\n", initializeFunction, ret); > + > + return ret; > } > > static int WINAPI direct3d8_GetAdapterCount(Direct3D8 *iface) > { > - FIXME("(): stub!\n"); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + int ret = IDirect3D8_GetAdapterCount(This->direct3d8); > + > + FIXME("() -> (%i)\n", ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_GetAdapterIdentifier(Direct3D8 *iface, int adapter, > LONG flags, D3DADAPTER_IDENTIFIER8 *identifier) > { > - FIXME("(%i, %i, %p): stub!\n", adapter, flags, identifier); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_GetAdapterIdentifier(This->direct3d8, adapter, flags, identifier); > + > + FIXME("(%i, %i, %p) -> (%x)\n", adapter, flags, identifier, ret); > + > + return ret; > } > > static int WINAPI direct3d8_GetAdapterModeCount(Direct3D8 *iface, int adapter) > { > - FIXME("(%i): stub!\n", adapter); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + int ret = IDirect3D8_GetAdapterModeCount(This->direct3d8, adapter); > + > + FIXME("(%i) -> (%i)\n", adapter, ret); > + > + return ret; > } > > static HRESULT WINAPI direct3d8_EnumAdapterModes(Direct3D8 *iface, int adapter, int mode, D3DDISPLAYMODE *displayMode) > { > - FIXME("(%i, %i, %p): stub!\n", adapter, mode, displayMode); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_EnumAdapterModes(This->direct3d8, adapter, mode, displayMode); > + > + FIXME("(%i, %i, %p) -> (%x)\n", adapter, mode, displayMode, ret); > + > + return ret; > } > > static HRESULT WINAPI direct3d8_GetAdapterDisplayMode(Direct3D8 *iface, int adapter, D3DDISPLAYMODE *displayMode) > { > - FIXME("(%i, %p): stub!\n", adapter, displayMode); > + direct3d8 *This = impl_from_Direct3D8(iface); > + HRESULT ret; > > - return E_NOTIMPL; > + ret = IDirect3D8_GetAdapterDisplayMode(This->direct3d8, adapter, displayMode); > + > + TRACE("(%i, %p) -> (%x)\n", adapter, displayMode, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceType(Direct3D8 *iface, int adapter, D3DDEVTYPE checkType, > D3DFORMAT displayFormat, D3DFORMAT backBufferFormat, LONG bWindowed) > { > - FIXME("(%i, %u, %u, %u, %i): stub!\n", adapter, checkType, displayFormat, backBufferFormat, bWindowed); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + LONG ret = IDirect3D8_CheckDeviceType(This->direct3d8, adapter, checkType, > + displayFormat, backBufferFormat, bWindowed); > + > + FIXME("(%i, %u, %u, %u, %i) -> (%i)\n", adapter, checkType, displayFormat, backBufferFormat, bWindowed, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceFormat(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT adapterFormat, LONG usage, D3DRESOURCETYPE rType, D3DFORMAT checkFormat) > { > - FIXME("(%i, %u, %u, %i, %u, %u): stub!\n", adapter, deviceType, adapterFormat, usage, rType, checkFormat); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return 0; > + LONG ret = IDirect3D8_CheckDeviceFormat(This->direct3d8, adapter, deviceType, > + adapterFormat, usage, rType, checkFormat); > + > + FIXME("(%i, %u, %u, %i, %u, %u) -> (%i)\n", adapter, deviceType, adapterFormat, usage, rType, checkFormat, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_CheckDeviceMultiSampleType(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT renderTargetFormat, LONG windowed, D3DMULTISAMPLE_TYPE multiSampleType) > { > - FIXME("(%i, %u, %u, %i, %u): stub!\n", adapter, deviceType, renderTargetFormat, windowed, multiSampleType); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = IDirect3D8_CheckDeviceMultiSampleType(This->direct3d8, adapter, deviceType, > + renderTargetFormat, windowed, multiSampleType); > + > + FIXME("(%i, %u, %u, %i, %u) -> (%i)\n", adapter, deviceType, renderTargetFormat, windowed, multiSampleType, ret); > > - return 0; > + return ret; > } > > static LONG WINAPI direct3d8_CheckDepthStencilMatch(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, > D3DFORMAT adapterFormat, D3DFORMAT renderTargetFormat, D3DFORMAT depthStencilFormat) > { > - FIXME("(%i, %u, %u, %u, %u): stub!\n", adapter, deviceType, adapterFormat, renderTargetFormat, depthStencilFormat); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = IDirect3D8_CheckDepthStencilMatch(This->direct3d8, adapter, deviceType, adapterFormat, > + renderTargetFormat, depthStencilFormat); > + > + TRACE("(%i, %u, %u, %u, %u) ->(%i)\n", adapter, deviceType, adapterFormat, > + renderTargetFormat, depthStencilFormat, ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_GetDeviceCaps(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, D3DCAPS8 *caps) > { > - FIXME("(%i, %u, %p): stub!\n", adapter, deviceType, caps); > + direct3d8 *This = impl_from_Direct3D8(iface); > > - return E_NOTIMPL; > + HRESULT ret = IDirect3D8_GetDeviceCaps(This->direct3d8, adapter, deviceType, caps); > + > + TRACE("(%i, %u, %p) -> (%x)\n", adapter, deviceType, caps, ret); > + > + return ret; > } > > static LONG WINAPI direct3d8_GetAdapterMonitor(Direct3D8 *iface, int adapter) > { > - FIXME("(%i): stub!\n", adapter); > + direct3d8 *This = impl_from_Direct3D8(iface); > + > + LONG ret = (LONG)IDirect3D8_GetAdapterMonitor(This->direct3d8, adapter); > + > + TRACE("(%i) -> (%i)!\n", adapter, ret); > > - return 0; > + return ret; > } > > static HRESULT WINAPI direct3d8_CreateDevice(Direct3D8 *iface, int adapter, D3DDEVTYPE deviceType, HWND hFocusWindow, > @@ -235,6 +296,9 @@ HRESULT direct3d8_create(Direct3D8 **ppv) > > object->Direct3D8_iface.lpVtbl = &Direct3D8_Vtbl; > object->ref = 1; > + object->direct3d8 = Direct3DCreate8(D3D_SDK_VERSION); > + if(!object->direct3d8) > + ERR("Can't create D3D8 object\n"); > > *ppv = &object->Direct3D8_iface; > > -- > 2.15.0 > > >

Oct. 31, 2017