On 28/07/2020 16:26, Henri Verbeet wrote:
On Tue, 28 Jul 2020 at 16:35, Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
On 28/07/2020 13:37, Henri Verbeet wrote:
On Mon, 27 Jul 2020 at 22:06, Gabriel Ivăncescu gabrielopcode@gmail.com wrote:
On 27/07/2020 19:30, Stefan Dösinger wrote:
This will either create a video or system memory surface depending on the whims of the driver. Since we already explicitly test offscreen sysmem surfaces, shouldn't this one request video memory explicitly and skip some tests if creation fails? That might make your broken(hr == DD_OK) /* WinXP */ go away.
You're right, sorry, I'm not very familiar with ddraw. I tried with DDSCAPS_VIDEOMEMORY (and even DDSCAPS_LOCALVIDMEM, though it shouldn't be necessary), unfortunately it's still broken on Windows XP so that broken check has to stay.
Why do you consider the Windows XP result broken? DD_OK is what I would expect for DDSCL_NORMAL.
Well, I thought it's broken because it only applies to ddraw1 and on Win XP (not on Windows 7). The other ddraw have the same behavior as other Windows OSes and fail, too. So it seemed like the odd one out.
I see. The other ddraw versions are probably missing a Restore() call though. I.e., my understanding of the expected behaviour is the following:
- In DDSCL_EXCLUSIVE mode, changing the foreground window makesthe device lost. - In DDSCL_NORMAL mode, this does not happen.
A more subtle implication of that is that switching from exclusive fullscreen to the normal cooperative level loses surfaces, due to the order of the fullscreen/windowed change relative to the exclusive/normal change. This is currently a todo_wine. On the other hand, inserting a change to the normal fullscreen cooperative level in between avoids losing surfaces.
After the change from exclusive fullscreen to normal, we recreate the primary to make it non-flippable. This avoids a call to RestoreAllSurfaces()/restore_surfaces(), but only because before this patch the primary is the only surface that can get lost. Restoring surfaces after recreating the primary should get rid of many of the todo_wine/DDERR_SURFACELOST introduced in this patch.
The part that is unusual for ddraw1 compared to the other versions is that surfaces do not appear to get lost during the change from exclusive fullscreen to normal. This may be due to slight ordering differences compared to the other versions (see also above). Seemingly that's not entirely consistent between Windows versions or drivers though, as the existing broken() seems to hint at. But once we're in the normal cooperative level, we wouldn't expect window changes to lose surfaces. In any case, I'd expect restoring surfaces after recreating the primary to make the ddraw1 behaviour consistent again with the other ddraw versions, and across Windows versions.
Last, and for what it's worth, the behaviour of older Windows versions like Windows XP and Windows 98 is generally much more in line with what ddraw applications expect. It's not unusual for older ddraw applications in particular to simply not work on e.g. Windows 10 unless specific compatibility settings (or in some cases patches) are used.
That makes sense, thanks for the explanation. Restoring it did indeed solve it, I'll send updated patches shortly.