Fixed point calculation for improved accuracy, dithering in debug builds only.
Averaging and optional multiplier can be set as compile flags, example for speed testing with long averaging and a 10x multiplier:
-D FPS_CALC_AVG=200
-D FPS_MULTIPLIER=10
The calculation resolution is limited (9.7bit fixed point) so values larger than 200 can hit resolution limit and get stuck before reaching the final value.
If WLED_DEBUG is defined, dithering is added to the returned value so sub-frame accuracy is possible in post-processingwithout enabling the multiplier.
* keep FRAMETIME_FIXED as a fixed value
* remove WLED_FPS_SLOW and FRAMETIME_FIXED_SLOW
* explicit test "(_targetFps != FPS_UNLIMITED)" for debug messages
* don't modify _lastServiceShow in show()
* test for "fps == FPS_UNLIMITED" explicitly, so we could pick a different
magic number later
* separate fps calculation (strip.show) from framerate control (strio.service)
* improved condition for early exit in strip.show
* make MIN_SHOW_DELAY depend on target fps
* strip.show consideres complete time for effect calculation + show; old code wrongly used the time between completion of last show and start of next effect drawing, causing unexpected slowdown
* add "unlimited FPS mode" for testing
* increase warning limits for "slow strip" and "slow effects"
- increase WLED_MAX_BUSSES for C3 (fixes#4215)
- fix for #4228
- fix for very long running effect (strip.now, strip.timebase)
- C++ API change to allow `seg.setColor().setOpacity()`
Fix for LED and Scenes uncontrollable using Alexa.
Weird behavior regarding to the device names and shared scenes fixed with this.
Seen in issue Aircoookie/Espalexa#228 and fixed from @ams-hh
Tested by myself and works just fine. Created second pull request here because the library seems to be a bit different from the official Espalexa repo.
---------
Co-authored-by: Frank <91616163+softhack007@users.noreply.github.com>
Co-authored-by: Blaz Kristan <blaz@kristan-sp.si>
This is a platform feature that asks forgiveness for PROGMEM misuse:
it adds a handler such that incorrectly used PROGMEM will work without
crashing, just really, *really* inefficiently.
Given that most of our real-world use cases for PROGMEM strings are
relatively infrequent text calls, we can err on the side of developer
convenience and address performance problems if and when they arise.
-replaced all PI references with M_PI version
-there is no need to do the angle-modulo in float, casting it to an integer does the same BUT it has to be cast to an `int` first, see comment.
