mirror of
https://github.com/reactos/reactos.git
synced 2024-12-28 01:55:19 +00:00
e034377b51
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. |
||
|---|---|---|
| .. | ||
| i386 | ||
| alphablend.c | ||
| bitblt.c | ||
| bitblt_new.c | ||
| clip.c | ||
| copybits.c | ||
| debug.c | ||
| device.c | ||
| device.h | ||
| driverobj.c | ||
| driverobj.h | ||
| drvdbg.c | ||
| eng.h | ||
| engbrush.c | ||
| engevent.c | ||
| engevent.h | ||
| engmisc.c | ||
| engobjects.h | ||
| engwindow.c | ||
| error.c | ||
| float.c | ||
| floatobj.h | ||
| gradient.c | ||
| inteng.h | ||
| ldevobj.c | ||
| ldevobj.h | ||
| lineto.c | ||
| mapping.c | ||
| mapping.h | ||
| math.c | ||
| mdevobj.c | ||
| mdevobj.h | ||
| mem.c | ||
| mouse.c | ||
| mouse.h | ||
| multidisp.c | ||
| paint.c | ||
| pandisp.c | ||
| pathobj.c | ||
| pdevobj.c | ||
| pdevobj.h | ||
| perfcnt.c | ||
| rlecomp.c | ||
| semaphor.c | ||
| sort.c | ||
| stretchblt.c | ||
| string.c | ||
| stubs.c | ||
| surface.c | ||
| surface.h | ||
| transblt.c | ||
| umpdstubs.c | ||
| xlateobj.c | ||
| xlateobj.h | ||