hello, i was wondering if anyone would be willing to help with linux support? please note: if you don't want to this shouldn't require a full rewrite of the program thanks to wine, just a few slight modifications really. looking forward to replies! 😀
Two things doing the same thing. Wine already translates D3D into OpenGL calls. Considering their past history with D3D Gallium3d state trackers, I doubt they'd be interested in an outside party' pushing for a major change in architecture.
The same fixes that dgVoodoo 2 applies for earlier D3D APIs could be applied directly to the Wine graphics stack without having to run two compatibility layers. Glide support is somewhat more interesting, as Glide isn't implemented in the Wine stack.
The same fixes that dgVoodoo 2 applies for earlier D3D APIs could be applied directly to the Wine graphics stack without having to run two compatibility layers.
I don't see really see that happening though, do you? Wine D3D11 support on the other hand, I wouldn't be surprised to someday see.
Actually, I consider this feasible. I haven't heard of the Wine devs being hostile to patches unless they involve substantial changes in architecture.
I would certainly also welcome dgVoodoo 2, but i think that might be a large task requiring an excellent understanding of dgVoodoo 2, the Wine translation layer, and possibly Linux graphics driver capabilities. Plus, I doubt the Wine devs would commit a huge amount of time to it as dgVoodoo 2 doesn't bring fundamental new capabilities to the table.
i was thinking more if we found ways around these unimplemented features and just made an alternate wine compatible WINDOWS binary for now? then showing the wine team the overall benefits they could work towards making it a toggle option in winecfg (something like upgrade old directx calls). i mean, if these are all fairly normal workarounds we could just have one universal binary? i know they strive towards an authentic windows feeling but it could be a toggle a bit like how you can choose to have wine windows blend in or have windows style title bars
So, according to the log, D3D11 is not the only problem?
BTW, I don't know Wine's D3D11 support but doesn't dgVoodoo work with that at all?
1fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet #displayed on a lot of working software 2fixme:module:load_library unsupported flag(s) used (flags: 0x00000800) 3fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000000,(nil),0x0002,0x00000000,0x83e958,(nil)): stub #potentially different software 4fixme:advapi:DeregisterEventSource (0xcafe4242) stub #potentially different software 5fixme:advapi:GetExplicitEntriesFromAclW 0x153054 0x93e784 0x93e790: semi-stub 6fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! 7fixme:wbemprox:client_security_SetBlanket 0x7b93d82c, 0x168578, 10, 0, (null), 3, 3, (nil), 0x00000000 8fixme:wbemprox:client_security_Release 0x7b93d82c 9fixme:ntdll:NtLockFile I/O completion on lock not implemented yet #i suspect this is the biggest issue 10fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! 11fixme:wbemprox:client_security_SetBlanket 0x7b93d82c, 0x153dc8, 10, 0, (null), 3, 3, (nil), 0x00000000 12fixme:wbemprox:client_security_Release 0x7b93d82c 13fixme:crypt:ProvStore_release Unimplemented flags 1 14fixme:crypt:MemStore_release Unimplemented flags 1 15(dgVoodooCpl.exe:6487): Gtk-CRITICAL **: gtk_bin_get_child: assertion 'GTK_IS_BIN (bin)' failed 16fixme:winhttp:get_system_proxy_autoconfig_url no support on this platform 17fixme:winhttp:WinHttpDetectAutoProxyConfigUrl discovery via DHCP not supported 18fixme:d3d11:D3D11CreateDevice Unhandled driver type 0x5. #probably an issue 19fixme:dxgi:dxgi_check_feature_level_support Ignoring adapter type. 20fixme:dxgi:dxgi_device_init Ignoring adapter type. 21fixme:d3d11:device_parent_create_swapchain_texture device_parent 0x157fac, container_parent 0x1764c0, wined3d_desc 0x325ce4, texture flags 0, wined3d_texture 0x1be508 partial stub! 22fixme:d3d11:device_parent_create_swapchain_texture Implement DXGI<->wined3d usage conversion. 23fixme:d3d11:device_parent_create_swapchain_texture device_parent 0x1c05a4, container_parent 0x1acdb0, wined3d_desc 0x325ce4, texture flags 0, wined3d_texture 0x176298 partial stub! 24fixme:dxgi:dxgi_factory_IsCurrent iface 0x175770 stub! 25fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x1d6b00, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0x3, mode_count 0x325f90, desc (nil) partial stub! 26fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x1d6b00, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0x2, mode_count 0x325f90, desc 0x1e4a98 partial stub! 27wine: Unhandled page fault on read access to 0x00000000 at address 0x407f46 (thread 0009), starting debugger... 28fixme:uxthemegtk:SetWindowTheme (0x10184, (null), (null))
you might find it a bit less daunting like this. as the actual game loads and deus ex human revolution (pretty sure that's directX11) loads. i'm guessing you're referencing something very particular as the control panel loads up?
you might find it a bit less daunting like this. as the actual game loads and deus ex human revolution (pretty sure that's directX11) loads. i'm guessing you're referencing something very particular as the control panel loads up?
No, nothing special. The CPL is just a standard Win32 application relying on GDI, USER and KERNEL, I'm sure Wine can handle that part.
You can check the API log of the CPL by API Monitor (http://www.rohitab.com/apimonitor), but I extracted and attached the part affecting DX11 (and DXGI).
All the CPL does is enumerates the available adapters and their display outputs through DXGI and creates a D3D11Device. I guess it's the software WARP device tzpe that Wine is complaining about.
But other than that, if (full) D3D11 support is available through Wine then it should handle the rest.
On the other hand, I don't think that wrapping DX/Glide -> D3D11 -> OpenGL would yield a good result (performance). For Linux, the best would be to implement an API output other than DX11, for example Vulkan.