Both ESP8266 and ESP32 have a hardware random register. This update makes use of that. It is slightly faster than the fastled variants but mostly it is truly random, even when the timing limitations stated in the datasheet are disregarded. Also saves a bit on code size.
- Replaced all random8() and random16() calls with new hw_random() versions
- Not replaced in FX where PRNG is required
Improvements & merges of FX
- Scrolling Text: Gradient Palette support added
- Waving Cell: Improved with higher temporal resolution (smoother at lower speeds) and added additional mode setting and optional blurring
- Julia: added blur option
- Squared Swirl: added fade option
- Added smearing option to:
- DNA
- DNA Spiral
- Drift
- Drift Rose
- Crazy Bees
- Ripple
- Colored Bursts
- Frizzles
- Lissajous
- Sindots
- Spaceships
- Added palette support to:
- Crazy Bees
- Polar Lights
- Drift Rose
- Changed default palette handling (no more special treatment for some FX)
- Merged puddles and puddlepeak
- Merged Gravcenter, Gravcentric, Gravfreq and Gravimeter (saves 1.2k of flash)
- Merged meteor and meteor smooth
- Renamed police_base into mode_two_dots as that was just an alias
- Added 'Traffic Light' palette (originally defined in Polar Lights FX)
- Firenoise: removed local palette, use fire palette -> slight change in looks (+bugfix)
- Some code cleanup (removed unused / commented stuff)
- Moved dev info for AR to the top so ist easier to find as a reference, also added link to KB there
Removing the bool saves on code size and makes the function a tiny bit faster. Also this is a cleaner solution IMHO.
-updated blend function to optimized 8bit calculation
- efficient color blend calculation in fews operations possible
- omitting min / max checks makes it faster on average
- using 8bit for "blend" variable does not significantly influence the resulting color, just transition points are slightly shifted but yield very good results (and better than the original 16bit version using the old fastled math with improper rounding)
- updated drawCircle and drawLine to use 8bit directly instead of 16bit with a shift
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
- 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
