So that ddraw isn't always loaded, esp. for app not requesting vmr7.
Could lower memory pressure on 32bit.
Note: on win10, the native 32bit and 64bit quartz DLL delay imports ddraw.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4753
On Fri Dec 22 23:04:14 2023 +0000, Petrichor Park wrote:
> OK, and this is because the code is *compiled* in `compile_shader`, but
> it's only checked for validity in the `STATE_PREPROC`? So it's showing
> the line where the preprocessing is done even though it "should" be
> showing the line where the compiling is done?
I'd say the point is rather that, independently of whether you're testing compilation or preprocessing, while the parser is scanning the code section the code itself [is only copied line by line in buffer `shader_source`](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a9146c43c859c3/tests/shader_runner.c#L1464). Only then the following line beginning with `[` is found the parser knows that the section is finished and [can preprocess/compile it](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a…. By that moment the line number is that of the beginning of the following section, which might result in a misleading error message, unless you set a different context while the parser is [within the scope of `if (!ret || line[0] == '[')`](https://gitlab.winehq.org/wine/vkd3d/-/blob/78343dcf87d3a911264c6c9a87a9146c43c859c3/tests/shader_runner.c#L1161).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/516#note_56610