Search names in fonts in the order of Microsoft, Mac and finally Unicode platform. This is also the
order win32u uses to load font names.
Fix Granado Espada Japan (1219160) launcher crashes at start in the Japanese locale. The game ships
a font with a broken name record of Mac platform and encoding ID 0 (Roman) but the name string is in
code page 10001 (Japanese). This broken name record is placed before the name records for the
Microsoft platform so it gets selected first. Then the name string in the name record doesn't get
converted correctly to Unicode because of the wrong code page. Thus the EnumFontFamiliesExW()
in GdipPrivateAddMemoryFont() fails to find the font and causes game crash.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5421
Adds the registry key
`HKEY_CURRENT_USER\\Software\\Wine\\Wayland Driver\\unaccelerated_pointer`
witch allows raw input. This makes it easier
to calculate the same sensitivity in different games,
use sensitivity calculators, and easily change values
when changing DPI and do not depend on the compositor or OS.
For example, you want to set the sensitivity to half as much,
and sensitivity curves in libinput are more difficult
to calculate than in the games themselves.
--
v6: winewayland.drv: Add unaccelerated pointer support
https://gitlab.winehq.org/wine/wine/-/merge_requests/4698
Francisco Casas (@fcasas) commented about libs/vkd3d-shader/hlsl.y:
> if (!(modifiers & HLSL_STORAGE_STATIC))
> var->storage_modifiers |= HLSL_STORAGE_UNIFORM;
>
> - if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM) &&
> - type_has_object_components(var->data_type, true))
> + if (ctx->profile->major_version < 5 && (var->storage_modifiers & HLSL_STORAGE_UNIFORM)
> + && var->data_type->class == HLSL_CLASS_STRUCT && type_has_object_components(var->data_type))
I think we would lose coverage for when we have an array of structs with object components.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745#note_66419
HLSL_CLASS_OBJECT does not really have much in common, and a lot of code currently uses it assuming that all objects are resources, which is not actually true. Most users of HLSL_CLASS_OBJECT want to check for specific types, and so we can simplify code a fair amount by promoting all object "base types" to top-level classes.
This series is a first step, comprising some cleanup towards that goal.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/745
I am still working on parsing the remaining features of the effects framework, such as the FX functions for the state block entries -- such as SetBlendState() -- and the "compile" and "Compileshader()" syntax. However, after adding the many tests included in 2/7 and reading the feedback from !708, I think that this first batch of patches are going in the right direction in terms of parsing the state blocks and how to represent them internally.
As Nikolay mentioned in https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64421 and https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/708#note_64444 there are many types of state blocks entries, which should be identified for writing the effect metadata.
A part that may cause discussion on this series is that I kept the representation of `struct hlsl_state_block_entry` using a `hlsl_block` to keep it general enough to represent all these types of state block entries, thinking on later implementing a helper to identify which type of entry we are dealing with.
Even though, as Nikolay pointed out, the instruction set of fx shaders is different, I still think that HLSL IR should be enough to represent the rhs of state blocks, and hopefully we won't need to pollute it too much (apart from the introduction of hlsl_ir_undeclared_load in 4/7 to avoid creating a new variable) if we find operations that are fx-specific, since I intend to represent calls to FX functions with the same `struct hlsl_state_block_entry`, given that they cannot be called in regular HLSL code. There are many validations that are applied on regular HLSL that still should be applied to state blocks, such as the use of valid swizzles and the correct use of operators.
--
v4: vkd3d-shader/hlsl: Allow KW_PIXELSHADER and KW_VERTEXSHADER as stateblock lhs.
vkd3d-shader/hlsl: Store state block on pass variables.
vkd3d-shader/hlsl: Parse list of state blocks.
vkd3d-shader/hlsl: Introduce hlsl_ir_stateblock_constant.
vkd3d-shader/hlsl: Parse and store state blocks on variables.
tests: Add tests for "compile" and CompileShader() syntax.
tests: Add tests for fxgroup syntax.
tests: Test function call syntax for state blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/739