November 2023 - wine-gitlab

[PATCH v2 0/1] MR4350: rpcrt4: Remove DECLSPEC_HIDDEN usage.
by Alistair Leslie-Hughes (＠alesliehughes) 14 Nov '23

14 Nov '23

-- v2: rpcrt4: Remove DECLSPEC_HIDDEN usage. https://gitlab.winehq.org/wine/wine/-/merge_requests/4350

3 2

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Rémi Bernon (＠rbernon) 14 Nov '23

14 Nov '23

On Tue Nov 14 09:21:35 2023 +0000, Anton Baskanov wrote: > > Although they look fine, 20ab5954 (and ec219ce1 even more) cut some > notes early in FF VIII intro. > Looks like note-off queuing for DMUS_PMSGT_NOTE needs to be handled > differently. I'll drop these for now. > > Haven't really looked into the details but 0ff26da7 feels a bit > complicated, I'm wondering if there's a better way to do this. > It depends on whether we need to support arbitrary connections. > > Regarding 2e226c26, is this what native does? > Yes, there is no fallback for melodic instruments for some reason, only > for drums. Though now I see that I handle missing regions incorrectly > (these should also fall back to Standard). I'll update the request. > I was also thinking about adding some tests, though I'm not sure how to > compare the output. The generated waveforms are quite different (e.g. > native produces a linear attack slope with some discrete steps, while > FluidSynth produces a smooth exponential one). > ![Screenshot_20231114_155825](/uploads/e46a2662792a0452350b8384b7eea0a6/Screenshot_20231114_155825.png) The attack time looks different but were it the same I think the shape difference can be ignored by having some leeway in the test. I added a couple of similar tests for MF audio transform output where we check that the total sample diff does not exceed a small percentage of the total, maybe reusing it here can work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52207

1 0

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Rémi Bernon (＠rbernon) 14 Nov '23

14 Nov '23

On Tue Nov 14 09:21:35 2023 +0000, Anton Baskanov wrote: > If we don't need to support arbitrary connections, then yes, your > proposed solution looks like the way to go. > I don't currently plan to add more fixups. What do you mean by arbitrary connections? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52206

1 0

[PATCH 0/1] MR472: vkd3d-shader: Add a helper to check for a numeric type.
by Nikolay Sivov (＠nsivov) 14 Nov '23

14 Nov '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/472

3 2

[PATCH 0/1] MR4367: winmm/tests: Use calloc instead of HeapAlloc.
by Alex Henrie (＠alexhenrie) 14 Nov '23

14 Nov '23

Fixes: bb6bcaf83e91882e0a523a4455ed7174b3ce3ad4 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4367

3 2

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Anton Baskanov (＠baskanov) 14 Nov '23

14 Nov '23

> Although they look fine, 20ab5954 (and ec219ce1 even more) cut some notes early in FF VIII intro. Looks like note-off queuing for DMUS_PMSGT_NOTE needs to be handled differently. I'll drop these for now. > Haven't really looked into the details but 0ff26da7 feels a bit complicated, I'm wondering if there's a better way to do this. It depends on whether we need to support arbitrary connections. > Regarding 2e226c26, is this what native does? Yes, there is no fallback for melodic instruments for some reason, only for drums. Though now I see that I handle missing regions incorrectly (these should also fall back to Standard). I'll update the request. I was also thinking about adding some tests, though I'm not sure how to compare the output. The generated waveforms are quite different (e.g. native produces a linear attack slope with some discrete steps, while FluidSynth produces a smooth exponential one). ![Screenshot_20231114_155825](/uploads/e46a2662792a0452350b8384b7eea0a6/Screenshot_20231114_155825.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52200

1 0

Re: [PATCH v2 0/7] MR4375: dmsynth: Various fixes 2
by Anton Baskanov (＠baskanov) 14 Nov '23

14 Nov '23

On Mon Nov 13 13:16:56 2023 +0000, Rémi Bernon wrote: > Instead of a dynamic list, could we have just a simple structure like: > ```c > struct gen_increments > { > float env_hold; > float env_decay; > float vol_hold; > float vol_decay; > }; > ``` > Which we would pass around down to `add_mod_from_connection` which would > set the needed adjustments (it's actually only needed there, > `set_gen_from_connection` won't have to add increments), and then after > the loops we would call `fluid_voice_gen_incr` for each of these? > Or do we need the generic version for more fixups that are not in this MR? If we don't need to support arbitrary connections, then yes, your proposed solution looks like the way to go. I don't currently plan to add more fixups. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52199

1 0

[PATCH 0/1] MR4368: gdi32/tests: Free what GdiConvertToDevmodeW returns with HeapFree.
by Alex Henrie (＠alexhenrie) 14 Nov '23

14 Nov '23

This partially reverts commit 0b7eed0310a2d1272a97d8a45ec37fa03a9c26c8. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4368

3 2

[PATCH v2 0/6] MR461: vkd3d: Implement ID3D12Device2::CreatePipelineState().
by Conor McCarthy (＠cmccarthy) 14 Nov '23

14 Nov '23

-- v2: vkd3d: Support depth bounds test. tests: Test CreatePipelineState(). vkd3d: Implement ID3D12Device2::CreatePipelineState(). vkd3d: Use struct d3d12_pipeline_state_desc for compute pipelines. vkd3d: Introduce struct d3d12_pipeline_state_desc for graphics pipelines. include: Add a D3D12_RT_FORMAT_ARRAY typedef. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/461

2 7

[PATCH 0/1] MR4384: ntdll: Don't use sysconf(_SC_PHYS_PAGES) on macOS.
by Brendan Shanks (＠bshanks) 14 Nov '23

14 Nov '23

`sysconf(_SC_PHYS_PAGES)` returns an error for i386 Mac binaries on any machine with more than 4 GB of RAM. From [the source code](https://github.com/apple-oss-distributions/Libc/blob/c5a3293354e22262… it's clear why--it calls `sysctlbyname()` to put the `hw.memsize` sysctl into a long, which is only 32-bits on i386. This returns an error on any Mac with more than 4GB: the value is too large for a 32-bit long. The `sysctl` man page documents that an int64 should be used for `hw.memsize`, do that and divide by the page size ourselves. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4384

2 1

2025

2024

2023

2022

wine-gitlab November 2023