Keep compatibility with MS PSDK ddraw.h file by using WINNT instead of
_WINNT_ in the preprocessor conditional test.
Incidentally this allows also removing those #define NT_BUILD_ENVIRONMENT
in the win32ss modules.
See commit 5fcfaf2e1 (r42346).
Use two longs instead of one for the first parameter of EngCreateBitmap export. Make it same as win32k export.
MSDN documentation says that 1st parameter is SIZEL (SIZE) structure, which actually contains 2 longs inside. Sice it is passed by value, it needs to take enough memory when export in dxgthk and redirect to win32k (since it's actually a win32k function).
Fixes the compilation of our dxg.sys when calling dxgthk!EngCreateBitmap from it.
Found during my DirectX investigations.
CORE-17561, CORE-17932, CORE-18221
Do it at each system startup instead: Remove old DirectX initialization code.
It's now outdated and not needed anymore.
Previously, the corresponding hackish intEnableReactXDriver() function
did two things: load dxg.sys and enable DirectDraw.
Now loading DirectX graphics is done during WINSRV initialization, and
enabling DirectDraw is called during each (and also first) display mode
switch, as in Windows. As debug analysis proves, there are no any other
calls in NtGdiDdCreateDirectDrawObject, besides the corresponding DXG
function.
CORE-17932
[ENG] Implement DirectDraw management in switch display mode functions
(e.g. resolution change, color depth, display frequency etc.):
- Switch DirectDraw instances between the two PDEVs (the current one and
the new one allocated by ourselves) by calling dxg!DxDdDynamicModeChange
function.
- Suspend them before and resume after the display mode switch, by calling
dxg!DxDdsuspendDirectDraw and dxg!DxDdResumeDirectDraw appropriately.
We currently don't have these functions implemented, but MS DXG has, so
it allows to properly manage DirectDraw PDEVs using this driver, similarly
to Windows.
My analysis confirms that these functions are always called in XP/2k3 on
display mode switch, even when there is no any DirectX app running at the
moment. Analyzing their prototypes show that my guesses are correct.
- Initialize hDev and dhpdev members for EDD_DIRECTDRAW_GLOBAL for newly
created surfaces, switch them during mode change and re-initialize after
it also. They are commonly used by DirectDraw stack.
In addition, enable DirectDraw for old and new PDEVs, by calling
dxg!DxDdEnableDirectDraw function.
[NTDDRAW] Additionally, fix usage of DirectDraw lock count in the PDEVOBJ
structure.
- Enable cDirectDrawDisableLocks member for storing its value, instead of
DxDd_nCount, which is marked as ROS-specific.
- Use it in win32k!DxEngGet/SetHdevData for getting/setting DirectDraw
count appropriately.
My analysis also shows that in Windows, the PDEVOBJ::cDirectDrawDisableLocks
method calls DxEngGetHdevData with type 8, which corresponds to our DxDd_nCount.
So there are no doubts that this member is used there.
- Rename DxEngGetHdevData_dd_count alias of type 8 to DxEngGetHdevData_dd_locks,
to match more accurately an actual member name. Update the enumeration
and fix all code parts appropriately.
All these changes allow to properly change display mode during executing
DirectDraw applications, when they try to switch in full-screen mode.
At least a bugcheck that happened before my changes, does no longer appear.
There are still some games that don't run correctly, as if there is no
3D acceleration (which actually exists). This requires further investigations.
Implement the following DxEng* functions:
- DxEngAltLockSurface
- DxEngDeleteSurface
- DxEngReferenceHdev
- DxEngSelectBitmap
- DxEngSetBitmapOwner
- DxEngUnreferenceHdev
Update their prototypes and call the appropriate win32k functions
inside them, since they are already implemented. Also get rid of
now unused IntGdi(Un)ReferencePdev, whose were called only by dxeng,
and whose are not used anymore. In Windows, DxEng(Un)ReferenceHdev calls
PDEVOBJ_vReferencePDEV and PDEVOBJ_vDeferencePDEV directly (those
correspond to our PDEVOBJ_vReference and PDEVOBJ_vRelease accordingly).
Required by MS DirectDraw stack (ddraw.dll & dxg.sys). CORE-17561
- Use the REGION_Complexity() function to get the actual region complexity instead of just number of rectangles.
- Don't use prgnRao at all, because it is always uninitialized when passed to the function. So in condition between prgnRao and prgnVis, the 2nd one always succeeds.
- Update the comment accordingly.
- Additionally, add a DPRINT to the end of the function, which displays the returned value.
This allows to properly enable and use DirectDraw and Direct3D hardware acceleration with the following MS DirectX components: ddraw.dll, d3d8.dll, d3d9.dll and dxg.sys. As in VM, same on real hardware.
But note that now the bugcheck 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) occurs when executing fullscreen DDraw apps, after switching display mode. It's unhidden by this fix.
Addendum to 855bf46.
CORE-17561
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.
This nice patch of Jerome Gardou improves palette
when VBEMP & inbuilt Mesa is used for
Diablo II, MS Age Of Empires 1, Anno 1602
to the state we had in SVN r75060 and below.
We already committed this fix into 0.4.8-release before.
