Build troubles

[SveSop]

Interesting project, so i thought i would give it a test... Used the same machine i build dxvk with (just built dxvk without errors prior to testing this). Ubuntu 18.04 w/mostly ubuntu release packages.

Attaching log after doing the regular meson config (same as i would do with dxvk) and running "ninja" build.log

[SveSop]

And meson log from build.w64 folder incase it helps. meson-log.txt

[Joshua-Ashton]

Yeah I need to go through and make mingw building and the likes work. Haven't had an opportunity recently, will do soon though 😄

[SveSop]

@Joshua-Ashton How do you build it if not with mingw?

[SveSop]

@Joshua-Ashton And to answer my previous question, i guess it might be a windows VS2017 build? (ref. https://github.com/Joshua-Ashton/dxup/blob/master/appveyor.yml )

Maybe change the howto on the README on front page how to build using VS2017 until you fix Linux mingw build? (Ill probably make a wild stab in the dark trying a VS2007 windows build anyway tho, but..)

[SveSop]

Bah.. that really turned out to be a stab in the dark indeed.

So.. let me just ask: Is this a source intended to be built by other than you, or just a "personal dump of various source files"? :)

Im asking, cos im a total noob. Sure i can follow instructions, but i find it kinda hard here since its not remotely near working. I mean.. have you tested it yourself, and everything works by doing a git clone to a NEW directory and following your own instructions? :)

wine_utils/meson.build:4:0: ERROR: File setup_dx10to11.sh.in does not exist. Skipping building anything in the wine_utils folder ofc ends up in the same error-filled list as before.

Please explain to me in simple steps how to build.. im eager to test dxup with dxvk to see if i can get some dx10 action :)

PS. Please don't go messing it up then complaining :( It makes ME sad (Fun quote from wine_utils/readme.txt)

[pchome]

Possible fixes to build with MinGW on linux:

diff --git a/src/d3d10_original/d3d10_original.h b/src/d3d10_original/d3d10_original.h
index 46974e0..dd2d8fb 100644
--- a/src/d3d10_original/d3d10_original.h
+++ b/src/d3d10_original/d3d10_original.h
@@ -43,6 +43,6 @@ extern "C"
 {
 #undef D3D10_ORIGINAL_ARGS
 #define D3D10_ORIGINAL_WRAP(returntype, name, ...) returntype __stdcall D3D10##name ( __VA_ARGS__ )
-#define D3D10_ORIGINAL_ARGS(returntype, name, ...) { return D3D10OriginalInterface::Get().##name (__VA_ARGS__); }
+#define D3D10_ORIGINAL_ARGS(returntype, name, ...) { return D3D10OriginalInterface::Get().name (__VA_ARGS__); }
 #include "d3d10_original_interfaces.h"
-}
\ No newline at end of file
+}

but not sure about this one.

diff --git a/src/d3d10_1/d3d10_1_base.h b/src/d3d10_1/d3d10_1_base.h
index 65fa035..87c85ac 100644
--- a/src/d3d10_1/d3d10_1_base.h
+++ b/src/d3d10_1/d3d10_1_base.h
@@ -76,7 +77,7 @@ namespace dxup
                        UINT    *pDataSize,
                        void    *pData)
                {
-                       return m_base->GetPrivateData(guid, pDataSize, pData);
+                       return this->m_base->GetPrivateData(guid, pDataSize, pData);
                }

                void SetBase(DX11Interface* pNewBase)
@@ -91,14 +92,14 @@ namespace dxup
                        UINT    DataSize,
                        const void    *pData)
                {
-                       return m_base->SetPrivateData(guid, DataSize, pData);
+                       return this->m_base->SetPrivateData(guid, DataSize, pData);
                }

                HRESULT STDMETHODCALLTYPE SetPrivateDataInterface(
                        REFGUID  guid,
                        const IUnknown *pUnknown)
                {
-                       return m_base->SetPrivateDataInterface(guid, pUnknown);
+                       return this->m_base->SetPrivateDataInterface(guid, pUnknown);
                }
        };

@@ -116,16 +117,16 @@ namespace dxup
                        // I'm so confused. Why does this work?
                        // Wish I could see Crytek's code...
                        d3d10->m_cachedResource11 = pD3D11Tex;
-
+/*
                        if (!d3d10->m_cachedResource10 || !d3d10->m_cachedResource11 || d3d10->m_cachedResource11 != pD3D11Tex)
                        {
                                d3d10->m_cachedResource10 = new D3D10Texture2D(pD3D11Tex);
                                d3d10->m_cachedResource11 = pD3D11Tex;
                        }
-
+*/
                        *ppResource = d3d10->m_cachedResource10;

                        DXUP_Assert(*ppResource);
                }
        }
-}
\ No newline at end of file
+}
diff --git a/src/d3d10_1/d3d10_1_device.cpp b/src/d3d10_1/d3d10_1_device.cpp
index a1c5f97..eee8fcd 100644
--- a/src/d3d10_1/d3d10_1_device.cpp
+++ b/src/d3d10_1/d3d10_1_device.cpp
@@ -44,13 +44,13 @@ namespace dxup

                if (riid == __uuidof(IDXGIDevice) || riid == __uuidof(IDXGIDevice1) || riid == __uuidof(IDXGIDevice2))
                        return m_base->QueryInterface(riid, ppvObject);
-
+/*
                if (riid == __uuidof(ID3D10InfoQueue) || riid == __uuidof(ID3D10Debug))
                {
                        DXUP_Log(Warn, "Couldn't find interface, asked for %s!", riid == __uuidof(ID3D10InfoQueue) ? "ID3D10InfoQueue" : "ID3D10Debug");
                        return E_FAIL;
                }
-
+*/
                DXUP_Log(Warn, "Couldn't find interface!");
                return E_FAIL;
        }
@@ -310,7 +310,7 @@ namespace dxup

                ID3D11DepthStencilView* dsView = nullptr;
                HRESULT result = m_base->CreateDepthStencilView(d3d11Resource, &desc, &dsView);
-
+
                if (dsView)
                {
                        auto* dsv = new D3D10DepthStencilView(pDesc, this, dsView);
diff --git a/src/d3d10_1/d3d10_1_device_child.h b/src/d3d10_1/d3d10_1_device_child.h
index 24b1596..8c8055a 100644
--- a/src/d3d10_1/d3d10_1_device_child.h
+++ b/src/d3d10_1/d3d10_1_device_child.h
@@ -32,7 +32,7 @@ namespace dxup
        public:
                void STDMETHODCALLTYPE GetDesc1(DX10DescType* pDesc)
                {
-                       *pDesc = m_desc;
+                       *pDesc = this->m_desc;
                }
        };

@@ -42,7 +42,7 @@ namespace dxup
        public:
                void STDMETHODCALLTYPE GetDesc(DX10DescType* pDesc)
                {
-                       *pDesc = m_desc;
+                       *pDesc = this->m_desc;
                }
        };
 }
diff --git a/src/d3d10_1/d3d10_1_include.h b/src/d3d10_1/d3d10_1_include.h
index c2764ca..af9bcdf 100644
--- a/src/d3d10_1/d3d10_1_include.h
+++ b/src/d3d10_1/d3d10_1_include.h
@@ -87,3 +87,14 @@ typedef struct D3D11_FEATURE_DATA_D3D9_SHADOW_SUPPORT {
 } D3D11_FEATURE_DATA_D3D9_SHADOW_SUPPORT;
 #endif // __WINE__
 #endif // _MSC_VER
+
+// GCC complains about the COM interfaces
+// not having virtual destructors
+#ifdef __GNUC__
+#pragma GCC diagnostic ignored "-Wnon-virtual-dtor"
+#pragma GCC diagnostic ignored "-Wdelete-non-virtual-dtor"
+#endif // __GNUC__
+
+#define WIN32_LEAN_AND_MEAN
+#include <windows.h>
+#include <unknwn.h>
diff --git a/src/d3d10_1/d3d10_1_main.cpp b/src/d3d10_1/d3d10_1_main.cpp
index 6a141e0..74a17e6 100644
--- a/src/d3d10_1/d3d10_1_main.cpp
+++ b/src/d3d10_1/d3d10_1_main.cpp
@@ -47,7 +47,7 @@ extern "C"

                Flags &= ~D3D10_CREATE_DEVICE_ALLOW_NULL_FROM_MAP;
                Flags &= ~D3D10_CREATE_DEVICE_STRICT_VALIDATION;
-               Flags &= ~D3D10_CREATE_DEVICE_DEBUGGABLE;
+               //Flags &= ~D3D10_CREATE_DEVICE_DEBUGGABLE;
                Flags |= D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT;
 #ifdef _DEBUG
                //Flags |= D3D11_CREATE_DEVICE_DEBUG;
@@ -81,7 +81,7 @@ extern "C"

                Flags &= ~D3D10_CREATE_DEVICE_ALLOW_NULL_FROM_MAP;
                Flags &= ~D3D10_CREATE_DEVICE_STRICT_VALIDATION;
-               Flags &= ~D3D10_CREATE_DEVICE_DEBUGGABLE;
+               //Flags &= ~D3D10_CREATE_DEVICE_DEBUGGABLE;
                Flags |= D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT;
 #ifdef _DEBUG
                //Flags |= D3D11_CREATE_DEVICE_DEBUG;
@@ -100,4 +100,4 @@ extern "C"

                return result;
        }
-}
\ No newline at end of file
+}
diff --git a/src/d3d10_1/d3d10_1_shader.h b/src/d3d10_1/d3d10_1_shader.h
index 63880c8..77b01f8 100644
--- a/src/d3d10_1/d3d10_1_shader.h
+++ b/src/d3d10_1/d3d10_1_shader.h
@@ -12,8 +12,8 @@ namespace dxup
        public:
                D3D10Shader(D3D10Device* device, DX11Interface* dx11)
                {
-                       m_device = device;
-                       SetBase(dx11);
+                       this->m_device = device;
+                       this->SetBase(dx11);
                }

                HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void** ppvObject)
@@ -24,12 +24,12 @@ namespace dxup
                                || riid == __uuidof(ID3D10DeviceChild)
                                || riid == __uuidof(DX10Interface))
                        {
-                               AddRef();
+                               this->AddRef();
                                *ppvObject = this;
                                return S_OK;
                        }

-                       return m_base->QueryInterface(riid, ppvObject);
+                       return this->m_base->QueryInterface(riid, ppvObject);
                }
        };

diff --git a/src/d3d10_1/d3d10_1_state.h b/src/d3d10_1/d3d10_1_state.h
index bf5ef69..9e9e017 100644
--- a/src/d3d10_1/d3d10_1_state.h
+++ b/src/d3d10_1/d3d10_1_state.h
@@ -12,9 +12,9 @@ namespace dxup
        public:
                D3D10State(const DX10DescType* pDesc, D3D10Device* pDevice, DX11InterfaceType* pState)
                {
-                       m_device = pDevice;
-                       SetBase(pState);
-                       m_desc = *pDesc;
+                       this->m_device = pDevice;
+                       this->SetBase(pState);
+                       this->m_desc = *pDesc;
                }

                HRESULT STDMETHODCALLTYPE QueryInterface(
@@ -27,12 +27,12 @@ namespace dxup
                                || riid == __uuidof(ID3D10DeviceChild)
                                || riid == __uuidof(DX10InterfaceType))
                        {
-                               AddRef();
+                               this->AddRef();
                                *ppvObject = this;
                                return S_OK;
                        }

-                       return m_base->QueryInterface(riid, ppvObject);
+                       return this->m_base->QueryInterface(riid, ppvObject);
                }
        };

diff --git a/src/d3d10_1/d3d10_1_view_srv.cpp b/src/d3d10_1/d3d10_1_view_srv.cpp
index 225c379..d4438b1 100644
--- a/src/d3d10_1/d3d10_1_view_srv.cpp
+++ b/src/d3d10_1/d3d10_1_view_srv.cpp
@@ -2,6 +2,7 @@
 #include "d3d10_1_buffer.h"
 #include "d3d10_1_texture.h"
 #include "d3d10_1_view_srv.h"
+#include <cstring>

 namespace dxup
 {
diff --git a/wine_utils/meson.build b/wine_utils/meson.build
index 8029bc7..8d7ebfe 100644
--- a/wine_utils/meson.build
+++ b/wine_utils/meson.build
@@ -3,7 +3,7 @@ conf.set('dlldir', get_option('prefix')+'/'+get_option('bindir'))
 conf.set('arch', target_machine.cpu_family())
 configure_file(
   configuration : conf,
-  input         : 'setup_dx10to11.sh.in',
-  output        : 'setup_dx10to11.sh',
+  input         : 'setup_dxup.in',
+  output        : 'setup_dxup.sh',
   install_dir   : get_option('bindir')
 )

Also dxgi1_3.h and definition of D3D10CreateDeviceAndSwapChain1 from d3d10_1.h missing in MinGW headers.

[enrique556]

@SveSop if you're still watching this and interested: I successfully built the dlls in windows 10, and have successfully used them to run Crysis Warhead in both 32bit and 64bit in DX10 mode.

Quick build instructions for windows 10 / Visual studio community 2017:

1/9 Install VS2017 community edition When choosing modules/features, tick the basic c++ stuff.

2/9 Decide on x64 or x32 DLLs Are you planning on running a 32bit game executable, or 64bit? 64bit: Run x86_x64 Cross Tools Command Prompt for VS 2017 from the Start menu. 32bit: Run x86 Native Tools Command Prompt for VS 2017 from the Start menu. These'll set the default compiler to the appropriate one for the target architecture.

3/9 Install python3 for windows Get from python.org. The download is an exe installer, make sure to tick the box re. adding path. Verify that python3 is installed correctly in the command prompt you opened earlier: python --version pip --version .. those should both return something.

4/9 "Install" meson In the command prompt you opened earlier: pip install meson .. verify that it installed correctly by re-running above command, should say "Requirement already satisfied blah blah".

5/9 Install meson Meson isn't really a first class citizen of windows - you need to create a batch file and put it in the directory you intend to run meson from (or just put in one of your PATH folders). In the command prompt you opened earlier: cd <your dxup path> notepad meson.bat .. Notepad will start, paste following in there and save 'im: @echo off c:\Windows\py.exe %LOCALAPPDATA%\Programs\Python\Python36-32\Scripts\meson.py %*

6/9 Run meson to generate VS2017 solution Do following in the command prompt you opened earlier: cd <your dxup path> meson build --backend vs2017 --buildtype release (The reason you need to specify release as buildtype is because the default is Debug build, and that requires the Debug version of the VS2017 runtime DLLs, which are not redistributable).

7/9 Compile in VS2017 Do following in CMD.exe: cd build start dxup.sln This will open the solution in VS. Build the solution.

8/9 Manual setup of DXUP and DXVK for a single exe under wine The 3x compiled DLLs will be in various folders under dxup\build\src\ The following DLLs need to be added to your game's executable's folder: 64bit: <your dxup path>\build\src\d3d10\d3d10.dll <your dxup path>\build\src\d3d10_1\d3d10_1.dll <your dxup path>\build\src\dxgi\dxgi.dll <your dxup path>\d3d10_original\x64\d3d10_original.dll <your dxup path>\d3dx10_43\x64\d3dx10_43.dll <dxvk dlls>\x64\d3d11.dll <dxvk dlls>\x64\dxgi.dll <<== Rename to dxgi_original.dll 32bit: <your dxup path>\build\src\d3d10\d3d10.dll <your dxup path>\build\src\d3d10_1\d3d10_1.dll <your dxup path>\build\src\dxgi\dxgi.dll <your dxup path>\d3d10_original\x32\d3d10_original.dll <your dxup path>\d3dx10_43\x32\d3dx10_43.dll <dxvk dlls>\x32\d3d11.dll <dxvk dlls>\x32\dxgi.dll <<== Rename to dxgi_original.dll

9/9 Manually configure wine DLL overrides Assuming we're booted into Linux now, and we have those DLLs in the game's exe directory, load up your wine prefix (I used wine-staging 3.7 x64) and.. Run winecfg. Create an application setting for your game's 64bit exe, and for it, add following DLL overrides to native, builtin : d3d10 d3d10_1 d3d10_original d3d11 d3dx10_43 dxgi dxgi_original

I know this is probably a really stupid way of doing it, but it's how I got it working after examining the meson & friends files in the dxup folder cloned from git. The Crysis Warhead 64 bit executable runs in dx10 mode (you can bring down terminal in crysis via tilde key and type r_displayinfo=1 to verify DX mode) following these instructions. The graphics are glitchy in some ways - with my geforce 760 2gb I was able to run most graphics options in enthusiast but had to set the volumetric effects to minimal otherwise had black box covering top left 1/4 of screen. There are other various graphic artefacts but not sure if is DXUP, DXVK, or my ham-fisted compilation of the DLLs to blame. I also tested the 32 bit exe of Crysis warhead with same success, but that is not as exciting to me - I really need this thing to work for mechwarrior online - which just went 64bit-only, is based on crytek engine, and runs like a dog in dx9 mode. Unfortunately for me, I get a black screen with cursor after login when testing this.

[Joshua-Ashton]

@enrique556 You're overcomplicating it. Ninja is not required and you can just use the meson installer online Just meson build --backend vs2017

@pchome Looks similar to the changes I made for another project to get working under MinGW. Could you submit a pull request? 😄

[enrique556]

@Joshua-Ashton Thanks, that's much nicer. I have updated my ham-fisted win10/vs2017 build instructions with (slightly) more accurate info.

[SveSop]

@enrique556 Excellent instructions! Found that i had to use "x64 Native Tools" to build the x64 dll's, as i got a "wrong architecture" when trying a 64 bit app with it.. Possibly something i missed/did wrong tho, but worked fine with dx11 apps with that.

Tested Unigine Tropics in DX10 mode, but crashed, and i tested "Lost Planet".. also crashed. Unigine Tropics does not work with wined3d in dx10 mode either, so that might be a different issue possibly, but Lost Planet works with regular wine. Will see if i can find something else to test tho.

unimplemented function DXGI.DLL.CreateDXGIFactory@8 called in 32-bit code Might be relevant?

[enrique556]

@SveSop Regarding the x64 Native Tools Command Prompt: I re-tested with the one I suggested and that one, and it didn't make a difference, meson built the sln with 64 bitness correctly, and the compiled dxgi.dll was exactly 18,944 bytes in size for both builds.

re. unimplemented function DXGI.DLL.CreateDXGIFactory@8 called in 32-bit code: I did not get anything like that in the output when I ran crysis warhead. Are Unigine Tropics and Lost Planet x64 apps? ie. are you sure you're using the right wine version and build of the dlls? The only other thing I can think of mentioning is that you might need wine-staging 3.7 rather than wine 3.7 - at least I did.

EDIT: Just attempted to run Crysis 2 32bit in a 64bit wine (assumed Crysis 2 had a 64bit exe, but it doesn't, even though Crysis Warhead does) with the 32bit DXUP/DXVK dlls, and I got wine: Call from 0x7bc78569 to unimplemented function DXGI.DLL.CreateDXGIFactory@8, aborting. I moved it to a 32bit wine-staging prefix I had for UT3, and... it doesn't work. It just dies on loading, with next to nothing in the output. Given that Joshua has only been developing this with Crysis Warhead and ?Just Cause? for testing, it may be that these other DX10 games just don't work with DXUP/DXVK yet.

[Joshua-Ashton]

If you are getting unimplemented function DXGI.DLL.CreateDXGIFactory@8 called in 32-bit code you arent using the right arch

[SveSop]

@Joshua-Ashton The only two compiler "shells" in my vs2017 windows 64bit install that would generate win32(x86) code that will NOT give a "Wrong architecture" error is: x86 Native Tools Command Prompt and x64_86 Cross Tools Command Prompt Using those compiled as win32, and give the "unimplemented function" error. x64 Native Tools Command Prompt and x86_x64 Cross Tools Command Prompt produce x64 code and give "wrong architecture".

What am i doing wrong?

PS. Launching 32 bit dx11 benchmarks correctly redirects everything tho dxvk d3d11.dll, so dxgi.dll must be 32-bit "readable" i guess...

[SveSop]

@enrique556 I am using wine-staging-3.7 in a 64-bit prefix. 32-bit benchmarks like Unigine Valley properly redirects to dxvk 32-bit d3d11.dll, and benchmark runs like it should. 64-bit benchmark like Unigine Superposition properly redirects to dxvk 64-bit d3d11.dll as it should. Before using the x64 Native Tools Command Prompt i got a "wrong architecture" when trying to run Unigine Superposition from the dxup dxgi.dll, and thus no redirecting to dxgi_original.dll i guess.

I have not tested Crysis Warhead nor Just Cause, so i can not replicate a "working condition" that way.. I see there is a "weekend sale" on crysis warhead on steam, but meh.. wont play it anyway, so dunno if i cba to buy it just to test :)

Also tested nVidia "tech-demo" Cascades, but same error there.. Although those "feature tests" tend to not be optimal with wine anyway, as it is more a "only works with x.xx version nvidia driver" and such things... So of the "free things to test" i would guess Unigine Tropics would be the best bet as it has DX9/DX10/DX11 modes to test. DX11 mode works with DXVK with some minor texture glitches tho.

[enrique556]

@SveSop Usually the 64 bit executables are marked as such either by being in a separate "bin64" or similarly named folder, or having ExeName64.exe or ExeName_x64.exe kind of suffix. I think it's safe to say that Unigine Tropics and Lost Planet are both 32 bit, in which case you're just having other troubles, as I was with Crysis 2 and MWO. Unless you want to get yourself a copy of Crysis Warhead or that other game Justin tested, just to see this thing work, then it might be better waiting for next release. For your sanity, you could compare your built DLL sizes against mine for 32 bit (others included for reference): Release, 32bit: d3d10.dll: 11,776 bytes d3d10_1.dll: 64,512 bytes dxgi.dll: 16,384 bytes Release, 64bit: d3d10.dll: 14,336 bytes d3d10_1.dll: 78,336 bytes dxgi.dll: 18,944 bytes

[SveSop]

@enrique556 I know.. And yes, Unigine Valley/Heaven/Tropics are all 32-bit, where Unigine Superposition is 64-bit.

Slight difference for me.. dunno why: Release, 32bit: d3d10.dll: 11,264 bytes d3d10_1.dll: 64,024 bytes dxgi.dll: 16,384 bytes Release, 64bit: d3d10.dll: 14,848 bytes d3d10_1.dll: 77,824 bytes dxgi.dll: 18,944 bytes

Any way to check versions of something in vs2017? Some update or whatnot with a different compiler? Edit: Native C compiler: cl (msvc 19.13.26132) Native C++ compiler: cl (msvc 19.13.26132) Same for x86 version aswell.

[enrique556]

@SveSop Yes, in the appropriate command prompt, type cl, it'll tell you which compiler version you're at. Here's my 32 bit compiler output: Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26428.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. .. But I think it's more likely that I'm building an out-of-date copy of the DXUP source. I'll redo tomorrow and see if there's a difference.

Oh BTW (should've remembered this earlier): You can tell the bitness of a linux executable by using the file command, eg: file <filename>

EDIT: cloned latest from git, got exact same numbers for 32bit, so I'm building against latest source for sure.

[SveSop]

@enrique556 Cleared out my local copy and did a fresh git clone. file x32/d3d10.dll d3d10.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows file x64/d3d10.dll d3d10.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows However file x32/d3d11.dll (from dxvk compiled with mingw) d3d11.dll: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows file x64/d3d11.dll d3d11.dll: PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows

"Stripped" does not really mean much, but i am not sure if (GUI) vs (console) is relevant?

Other than that, i cant say i have much more ideas than the error is not happening with warhead or just cause.. Will do some more digging and see what i can come up with :)

[SveSop]

If i run nVidia Cascades with wined3d and wine-3.7, i get this from the log:

0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33da58,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33d9d8,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33dcb8,0x00000000), stub!
0009:fixme:win:EnumDisplayDevicesW ((null),0,0x33dc38,0x00000000), stub!
0009:fixme:dxgi:dxgi_factory_MakeWindowAssociation iface 0x150430, window 0x10062, flags 0 stub!
0009:fixme:dxgi:dxgi_swapchain_GetDesc Ignoring ScanlineOrdering, Scaling and SwapEffect.
0009:fixme:d3d10:D3D10ReflectShader data 0x7c3c78, data_size 988, reflector 0x33e2a8 stub!
0009:fixme:d3d10:d3d10_shader_reflection_GetDesc iface 0x165760, desc 0x33e234 stub!
0009:fixme:d3d10:d3d10_shader_reflection_GetConstantBufferByIndex iface 0x165760, index 0 stub!
wine: Unhandled page fault on read access to 0x00000000 at address 0x4b24e2 (thread 0009), starting debugger...

I dunno.. is "shader_reflection" something that might crash dxup? :) The "GetConstantBufferByIndex" is something that has been bug reported for Assassins Creed, and not fixed. That does not mean it would not work with dxup tho, cos there are from what i gather several things working with dxvk that does not with wined3d :) (Unigine Tropics also crash on this error with wined3d)

[pchome]

@Joshua-Ashton

Could you submit a pull request?

You can take this diff as a guide, since I can't check if this ok for VS, and you (obviously) can't check MinGW with gcc. So please accept changes not breaking VS builds manually.

This is the first step for cross-compilation, because even with this patches MinGW builds won't work.

[enrique556]

@SveSop I downloaded cascades (good free dx10 test you found there) and it did not work for me either, but noticed the two following lines in output: 0009:err:module:import_dll Library win32u.dll (which is needed by L"C:\\Program Files\\NVIDIA Corporation\\NVIDIA Demos\\Cascades\\bin\\dxgi_original.dll") not found 0009:err:module:import_dll Library api-ms-win-dx-d3dkmt-l1-1-2.dll (which is needed by L"C:\\Program Files\\NVIDIA Corporation\\NVIDIA Demos\\Cascades\\bin\\dxgi_original.dll") not found .. It's blaming dxgi_original (which is the DXVK version of dxgi) for needing these 2 windows dlls.

[SveSop]

@enrique556 Well.. wine does not have this .dll, but i found it in the system folders of my Win10 VBOX image..

I believe the .dll's - also the dxgi_original.dll and the other dxup dll's should be installed in their respective /windows/system32 (64 bit) and /windows/syswow64 (32 bit) folders rather than put in the same folder as the .exe file you are running. This was explained to some degree on the dxvk issues page a while back, and is what the install script does. Has to do with some system-loading-dll's or whatnot.

[enrique556]

@SveSop Yes I found it in my win10 vm also, but it was notably absent from my long-in-the-tooth windows7 drive.

Re: putting the dlls in the system folder(s) rather than the exe folder: I didn't think that'd matter (end users' famous last words). I'll test that today.

[Joshua-Ashton]

https://github.com/Joshua-Ashton/dxup/commit/80172043fd6dc46976198d29a21e237104f45dce

[Joshua-Ashton]

Closing this as I believe this is fixed (at least in master rn.) LMK if you have any issues.