progress() is called in setPixelColor(), calculating the transition progress for each pixel. Replaced that call with an inline function to get the new segment variable.
The progress is updated in service() when handleTransition() is called.
The new variable is in a spot where padding is added, so this should not use more RAM.
Result: over 10% increase in FPS on 16x16 matrix
* removed IRAM_ATTR: `updateTransitionProgress()` is called only once per frame, no need to put it in RAM.
* changed transitionprogress to static, private variable, this is now more aligned with other variables using the same logic
* added inline: the function is only used in one place
Processing of received button command is no longer processed in the callback, instead the value is saved to a variable and processed in the main loop.
The actual fix is to not access the file system while data is being sent out: even just trying to open a non-existing file causes glitches on the C3. Waiting for the bus to finish fixes this BUT it causes a frame-delay which is the lesser evil than random color flashes.
- 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.
When adding a new bus, the numeric current limit field was not being
initialized; this was causing it to save 0 when saved instead of the
default 55mA value.
- 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
- code is a bit cleaner and faster as well
- chaning array access to pointer access in bus_manager makes it a few instructions faster
- changed getNumberOfPins and getNumberOfChannels to return 32bit values, saving the unnecessary 8bit conversion
NeoPixelBus requires that all parallel I2S bus members be constructed
before any of them call Begin(). Implement this by deferring the
call to the end of bus construction.
Fixes#4301.
- all palettes are defined in palettes.h
- access to fastled palettes as an array to remove the switch cases
- palette createn in json.cpp in a loop instead of repeaded calls to save flash
- 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
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>
-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.
* fixed the positioning of the download button
* fixed space after "Download the latest binary:" disapering after building
* fixed typo
---------
Co-authored-by: maxi4329 <maxi4329>
- `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
- changes to `setPixelColorXY` give an extra FPS, some checks and the loops are only done when needed, additional function call is still faster (force inlining it gives negligible speed boost but eats more flash)
- commented out the unused `boxBlur` function
- code size improvemnts (also faster) in `moveX()` and `moveY()` by only copying whats required and avoiding code duplications
- consolidated the `blur()` functions by enabling asymmetrical blur2D() to replace `blurRow` and `blurCol`
- compiler warning fixes (explicit unsigned casts)
- removing WS2812FX::setMode()
- removing WS2812FX::setColor()
- removing floating point in transition
- color handling modification in set.cpp
- replaced uint8_t with unsigned in function parameters
- inlined WS2812FX::isUpdating()
- (MAY BE BREAKING) alexa & smartnest update
- Added pre-calculation for segment brightness: stored in _segBri. The impact on FPS is not huge but measurable (~1-2FPS in my test conditions)
- Removed `bool unScaled` from `setPixelColor()` function again (it has no/minimal impact on speed but huge impact on flash usage: +850 bytes)
- Removed negative checking in `setPixelColorXY()` and replaced it with a local typecast to unsigned, saves a few instructions (tested and working)
- Changed int8_t to int in `moveX()` and `moveY()`
- Removed a few functions from IRAM as they are now not called for every pixel but only once per segment update
- Removed a `virtualWidth()` call from `ripple_base()`
- Bugfix in `mode_colortwinkle()`
uint16_t to unsigned to make it consisten throughout the hand-down.
colorFromPaletteWLED now returns uint32_t which saves the conversion to CRGB and back to uint32_t (in most uses at least).
also added (preliminary) CRGBW struct. I tried to use it in place of uint32_t colors but it adds a lot of overhead when passing the struct so reverted to uint32_t in most places.
updated a few FX to use the CRGBW struct and also cleaned some code to improve flash useage.
- also added a struct to handle HSV with 16bit hue better (including some conversions, can be extended easily)
- the functions are optimized for speed and flash use. They are faster and more accurate than what fastled offers (and use much less flash).
- replaced colorHStoRGB() with a call to the new hsv2rgb() function, saving even more flash (new function is untested!)
- the 16bit hue calculations result in an almost perfect conversion from RGB to HSV and back, the maximum error was 1/255 in the cases I tested.
Damian Schneider