On Fri, Dec 16, 2016 at 10:13 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 15 December 2016 at 13:45, Józef Kucia jkucia@codeweavers.com wrote:
It's enough to enable this workaround for ddraw.
So would it then also be enough to just fixup things in ddraw7_GetAvailableVidMem()? In fact, the documentation suggests that's actually the proper place, and that this shouldn't be specific to the Windows version. You could probably use wined3d_get_adapter_display_mode() together with wined3d_calculate_format_pitch() to calculate the primary surface size.
Possibly yes, but then memory accounting would be inconsistent. There is also a consideration if the reported memory amount should change when the application switches the display mode. When it comes to whether this should be version specific I think we should enable this workaround only for older Windows versions. It's important to note that these applications aren't expected to work on modern Windows because GetAvailableVidMem() reports more memory than INT_MAX. It's just a workaround to make these buggy applications to work in Wine.