With update to 15.x many vars got changed to unsigned.
Wipe relies on truncation (of an uint16_t) for modulo operation, and was therefore broken.
Using directly an uint16_t like my proposal *should* be overall faster than using an unsigned and then doing a modulo. (Not an expert)
- previous fix worked but there was still an overflow after some time passed. there were still missing roll-overs apparently: reverting these two variables back to 16bit/8bit should fix it for good.
- sin/cos calls with incrementing numbers can lead to bad outcomes, the functions (_approx or original sinf/cosf) return bad values for very large float inputs
- rotation scale is now exactly 180° (divide slider input by 255 instead of 256)
- removed shift offset: offset is now zero at slider 0, to hit 128 on touch input devices is really hard
- added a 90° shift to input rotation, enabling to rotate from 0 to 180° instead of +90 to -90 (which is not useful in 1D)
- changed default settings values to more closely match the old 1D effect
- `sin16_t() / cos16_t()` are faster and more accurate than fastled versions
- `sin_approx() / cos_approx()` are float wrappers for `sin16_t() / cos16_t()` and are accurate enough to replace `sinf()/cosf()`
- `atan2()` is used only in octopus to calculate center offset, new approximated version saves flash
- `tan(), atan(), asin(), acos(), floor(), fmod()` are used only for sunrise/sunset calculation, using wled_math version saves flash
- `beatsinx()` replacements are to make use of new `sin16_t()/sin8_t()` functions to reduce flash size
- Extensively tested surnise/sunset calculation: deviation is 1min. max
- Tested some of the relevant FX and found no visual difference: Julia, 2D Drift, Drift Rose, Ghost rider, Rotozoomer, Palette, Arc 1D expansion
- total flash savings: 7.4k
* speedup: add functions to only blur rows or columns (50% faster)
* fire2012: tinkering with bur options. Vertical blur only when slider < 64 (faster); extra blur for slider values >192 (bush burn)
before a x=32 (n times of 16) had not equal sized bars, but first was
a single pixel and later a bar had 3 pixel width. This solves it to
have always 2 pixel sized bars.
I have to admit that I did not test with other pixel dimensions.
- update NeoPixelBus to v2.8.0
- use single/mono I2S + 4x RMT for 5 outputs or less
- use parallel x8 I2S + 8x RMT for >5 outputs (limit of 300 LEDs per output)
