Provious code wrongly assumed that direction is not an important part
of conditional effect. Moreover, if there's need to hardcode polar
direction, the default should be 0x4000 (north).
For one axis affects, a direction of 0 means complete lack of force, if
a FFB-enabled device takes direction into force calculation. A sine function
graph can be used to represent the resulting forces where X is the input
direction and Y is the force multiplier (360 degrees equals to 1).
This fixes conditional effect playback on Moza Racing devices, which do
not ignore direction field.
This doesn't affect latency much, but it makes the system usable if the system
drops you down from the bluetooth a2dp profile (headphones) to the handsfree
(I think...?) profile because the bluetooth audio device is also recording,
which would be extremely common in a VoIP app, but also if you're talking
in a different app while also playing audio.
Fixes#8192.
This needs to be preserved while in fullscreen, or leaving fullscreen for the maximized state can cause the taskbar to disappear with borderless windows.
Always restore the base floating size of a window before possibly entering the maximized state, as base size can be lost during the fullscreen transition, resulting in the window de-maximizing to the wrong size.
The results are not defined, and some renderers set 0xFF always and other renderers set the alpha to blend results, even though it won't be used when rendering.
Fixes --filter render_testBlendModes with D3D renderers
When going into a fullscreen space, update mouseConfinementRect once the
transition is done. When going exclusive fullscreen, force a window sync so
the transition is complete before we do the update.
Fixes#9088.
The API states that the related functions must return NULL if the function
called (get the parent tray, or get the parent entry) is invalid for this
menu. Initialising the fields to NULL makes that API correct for Windows.
The test/testtray program would crash on Windows when adding any item and then removing it, because a submenu's parent_entry field was not set.
Additionally, I noticed that some extraneous code copied from the {G,S}etTrayEntryChecked made {G,S}etTrayEntryEnabled work only for checkboxes, which is not the desired behavior.
Both issues were fixed in this commit.
