It had been missed in d09160a8b6 and broke compilation
for those platforms.
Took the opportunity to run clang-format on the code base to fix some corner cases
that went through our static tests/were overlooked recently.
Schlick's approximation and GGX are orthogonal concepts.
Furthermore, it's usage so far has been inconsistent: we don't even use it with anisotropic SchlickGGX, and Burley (Disney) diffuse does use it while its name doesn't indicate it.
The use of Schlick's approximation in Burley and GGX is an implementation detail and doesn't need to be reflected to the namig.
Prior to this, the value assumed for the interval between the start of the track and the first frame would be the one of the first key if
- *seeking/playing a continuous track*;
- *seeking a discrete track*.
And the first key would be ignored until reached -thus not modifying the target property/transform- in the remaining case; namely, *playing a discrete track*.
In other words, the inner workings of the animation system considered the unreached first key for interpolation but not for a query of every key inside a time range.
With this changes, the first key is only considered is the animation is looped and ignored otherwise. That way, in order to have a start value, you'll need an explicit key at the very beginning of the track, while having the flexibility of the animation player not touching the target value until the first key is reached.
This corresponds to the point 1) of #10752.
I am fixing the issue by adding DATA_PAD to the return pointer as
suggested by hi-ogawa
When using set_data in AudioStreamSample in PoolByteArray, the data is set
using a DATA_PAD to pad the pointer to the correct place as such
uint8_t *dataptr = (uint8_t *)data;
copymem(dataptr + DATA_PAD, r.ptr(), datalen);
data_bytes = datalen;
godot/scene/resources/audio_stream_sample.cpp#L473
All I am doing is adding a DATA_PAD to the return pointer to
get_data() in AudioStreamSample to change
godot/scene/resources/audio_stream_sample.cpp#L48
PoolVector<uint8_t>::Write w = pv.write();
copymem(w.ptr(), data, data_bytes);
to
PoolVector<uint8_t>::Write w = pv.write();
uint8_t *dataptr = (uint8_t *)data;
copymem(w.ptr(), dataptr + DATA_PAD, data_bytes);
Please review whether or not set or get is correct.
Because this issue seems to be fixable by removing DATA_PAD in set_data()
instead of adding DATA_PAD to get_data(). I have not tested the latter
fix
Fixes #issue, 11873
