Mutes the logging:
fixme:(dll/directx/wine/ddraw/utils.c:584) Unhandled flags 0x20.
gets logged many times per second.
It does affect several applications, e.g. the game 'Anno 1602' from 1998, and the 'Diablo 2 demo' from rapps,
For both games it can be observed with both: our VBEMP driver and the VBox4.3.12 3D-accelerated-driver.
Muting may improve performance a bit in such apps.
It gets logged although no missing features can be perceived visually in the rendering.
The regression was introduced to master by 0.4.9-dev-155-g 9987f02917
Fix it by importing Wine-commit
b943c7910b
ddraw: Handle DDLOCK_WRITEONLY in wined3dmapflags_from_ddrawmapflags().
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
fix picked from 0.4.15-dev-5070-g 305aae75f5
It regressed by 0.4.12-dev-1064-g 09c4d0a74b
when we tried to mute compiler warnings in the GCC Release configuration
for all modules, that do contain .y files.
In master we switched to use flex+bison to process those files at build-time
in 0.4.15-dev-2277-g 28dadda8be and at the same
time reverted the guilty rev.
In the backport to the old releases we do only revert, but do not introduce
flex+bison. This will reintroduce the warnings in GCC Release configuration.
Many 3D applications crashed with 'WineD3D fake window' msgbox
if they were used in VirtualBox with graphics driver
'VBoxDisp.sys from VM guest additions + installed 3D acceleration'
That was a regression of SVN r75847 == git
3d13ed394e
Contrary we had no such issues with the SW emulation.
The reason for the bug is that
VBoxDisp only supports OpenGL 2.1 (GLSL 120) and WineD3D
tried to use shaders for OpenGL 3.2 (GLSL 150).
This workaround disables the usage in a hard-coded way for
all graphics adapters. Should be ok for now, as ros does not
really support any modern GPU drivers yet.
Proper working runtime detection would be better ofc.
Thx to Doug Lyons & Fabian Maurer
cherry picked from commit 0.4.14-dev-113-g
082f230ac7
GCC Linux build had no issues with the last commit in D3DCOMPILER_43 but
MSVC x86 & x64 v18.0.31101.0 choked on it with
error C4133: 'function' : incompatible types - from 'D3D_PRIMITIVE *' to 'DWORD *'
and similar.
MSVC v18.0.31101.0, target x86 and x64, flagged C4133 as error
MSVC v16.0.40219.1, target x86, flagged C4133 as warning
cherry picked from commit 0.4.14-dev-8-g
36d9e80add
This brings us back to before guilty commit 0.4.10-dev-55-g
7af3969e9f
and therefore downgrades
dll/directx/wine/
D3D8,D3D9,DDRAW,D3DCOMPILER_43
to WineStaging 3.3 for this rls.
Also downgrades related header sdk/include/reactos/wine/wined3d.h
and for the first time also media/doc/README.WINE
Same versions of these dlls we had in every ros rls since 0.4.10rls.
Purpose of this revert is to fix crashes when Ddraw apps switch
into fullscreen with VBEMP and inbuilt Mesa.
I tested, before:
DxDiag crashed when switching to fullscreen (CORE-14955),
Diablo II crashed immediately (CORE-15652),
Monster-Truck-Madness 2 demo crashed after main menu
Afterwards all of these apps do run.
DXTN does still work after that, even with VBEMP and inbuilt Mesa.
This will be the interim fix, which I will keep for rls at least
until someone manages to fix CORE-14955 properly in master with current Wine.
analog to 0.4.10-RC-17-g
bb4c55d650
- Do not use hardcoded ordinals, add missing '-private'.
Except for MSXML3, OLE32 and RSAENH, see commit bff824b2 for more details.
- SHSVCS: The 6 first exports are nonamed with ordinals. Replace exported
commented stubs by actual exported stubs instead.
Co-Authored-By: Timo Kreuzer <timo.kreuzer@reactos.org>
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
Spinning here is supposed to improve performance by avoiding scheduling
overhead, but because ReactOS's Win32 subsystem does not deal with this well,
it causes the system to freeze on ROS.
As a workaround, we disable spinning and jump directly to the wait.
It should become obvious when this starts actually causing performance issues
again and it's time to undo.
