The first two patches here address an issue I encountered when using Wine's d3dx9 with DXVK in the game Command and Conquer 3. The game calls `D3DXLoadSurfaceFromMemory` on a multisampled render target. This ends up going through the `lock_surface()` helper in d3dx9, which eventually calls `UpdateSurface()` in `unlock_surface()` to copy the staging surface back to the multisampled render target. This succeeds on wined3d even though it shouldn't, and fails on DXVK like it should.
The second two patches address an issue reported in Empires: Dawn of the Modern World, where the game expects a device reset to reset the scene state.
--
v4: wined3d: Clear scene state on device state reset.
d3d8/tests: Add a test for device reset after beginning a scene.
d3d9/tests: Add a test for device reset after beginning a scene.
ddraw/tests: Add tests for preserving d3d scene state during primary surface creation.
d3d9: Return failure if a multisampled surface is passed to IDirect3DDevice9::UpdateSurface().
d3d9/tests: Add tests for IDirect3DDevice9::UpdateSurface() with a multisampled surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6042
--
v3: setupapi: Fix testing for a non-empty string in get_source_info().
setupapi/tests: Test installing an INF file with architecture-specific SourceDisks* sections.
setupapi: Use SetupGetSourceInfo() in get_source_info().
setupapi: Use SetupGetSourceFileLocation() in get_source_info().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6089
On Wed Jul 17 17:12:01 2024 +0000, Tim Clem wrote:
> Filing a bug is probably the right thing to do. I don't know offhand who
> would know best - I'm not very familiar with that area myself. In
> ntdll/unix/virtual.c, the address space limit is hardcoded to
> 0x7fffffff0000 for x86_64, but on ARM it looks like we try to detect it
> (see `get_host_addr_space_limit`). For the bug, it would be interesting
> to attach a +virtual log, so we can see what `get_host_addr_space_limit` returned.
The issue I am having is when fully emulating x86_64 wine on arm64 using the likes of box64/fex/qemu. So the hardcode makes sense why the problem is happening. Thanks for the info, I'll look into using `get_host_addr_space_limit` for all architectures.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_76437
On Wed Jul 17 17:12:01 2024 +0000, theofficialgman wrote:
> Thanks Tim. Should I file a bug for this then or are you aware of who
> might be more knowledgeable about the allocation system and why its
> attempting to allocate memory outside of address limit?
Filing a bug is probably the right thing to do. I don't know offhand who would know best - I'm not very familiar with that area myself. In ntdll/unix/virtual.c, the address space limit is hardcoded to 0x7fffffff0000 for x86_64, but on ARM it looks like we try to detect it (see `get_host_addr_space_limit`). For the bug, it would be interesting to attach a +virtual log, so we can see what `get_host_addr_space_limit` returned.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_76436
Somehow the field is not present for sound capture devices, at least on my Win11.
Fixes Tom Clancy's Splinter Cell: Conviction not finding any sound devices and refusing to start.
--
v2: dxdiagn: Fill szHardwareId for sound render devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6097
This is part XX1 of cmd engine rewrite.
It covers:
- tests & fixes for success/failure of changing current drive,
- tests & fixes for success/failure when using pipes,
- new implementation of CHOICE command.
Notes:
- CHOICE is not a builtin command in native cmd.exe,
but I kept it builtin for simplicity,
- CHOICE was (partially) implemented using syntax from
MS-DOS days; it has been moved to use Windows' syntax.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6090