* Added FX to copy a segment in 1D or 2D
- copies the source segment
- brightness of segment is relative to source segment
- optionally shifts the color hue, saturation and brightness
- invert, transpose, mirror work
- if source or targets do not match in size, smallest size is copied
- unused pixels fade to black (allows overlapping segments)
- if invalid source ID is set, segment just fades to black
- added a rgb2hsv conversion function as the fastled variant is inaccurate and buggy
- 1D to 2D and vice versa are supported
Particle System depends on linear brightness distribution, gamma corrected values are non-linear.
- added invers gamma table
- reversing gamma after brightness distribution makes it linear once again
- Photoshop-style segment/layer blending
- return of strip ABL
- remove global LED buffer in favour of segment-local buffer
- new effect blending modes/transitions
- custom palettes moved out of WS2812FX class
- increased limits (matrix size, LED RAM)
- added "rainbow"-mode colorwheel
- replaced palettes with gamma unmodified ones
- move gamma adjustment to last step before sending to LEDs
- Segment & WS2812FX class reorganisation (mutable members, reordered members, protected members)
Break the actual JSON assembly apart from the file writing code. This
permits calling it in other contexts, allowing us to pull the live
config data even if the filesystem is out of date.
* added bitwise operation based sqrt16
- replacement for fastled, it is about 10% slower for numbers smaller 128 but faster for larger numbers. speed difference is irrelevant to WLED but it saves some flash.
* updated to 32bit, improved for typical WLED use
- making it 32bits allows for larger numbers
- added another initial condition check for medium sized numbers
- increased the "small number" optimization to larger numbers: the function is currently only used to calculate sqrt(x^2+y^2) which even for small segments is larger than the initially used 64, so optimizing for 1024 makes more sense, although the value is arbitrarily chosen
- Implement vector in bus manager
- Memory calculation according to explanation from @Makuna
- Prefer 8 RMT before 8 I2S on ESP32 (fixes#4380)
- speed improvements in ABL
- verbose debugging
- get bus size from NPB (prototype)
- Parallel I2S output bugfix
- automatic selection of appropriate I2S bus (`X1xxxxxxMethod`)
- removed I2S0 on ESP32 (used by AudioReactive)
- renumbered internal bus numbers (iType)
- added buffer size reporting
This is purely a "clean code" thing, no impact on function - it helps to avoid confusion when reading the code.
C++ allows declaration and implementation to use different variable names.
* changed some parameters to "pointer to const", so compiler can better optimize code size and performance - because data behind a const pointer will never be modified by the called function.
* made setPixelColor `const`
* fixed a few potentially uninitialized local vars (the may have random values if not initialized)
* avoid shadowing "state" in handleSerial()
* plus a few very minor improvements
Redesign the usermod system so that usermods are implemented as
PlatformIO libraries instead of headers. This permits them to call for
dependencies, and eliminates the compiler flags for enabling each one,
allowing the build cache to behave better.
The usermod list is built using some linker magic to construct a static
list in ROM memory. This eliminates the need for wasting SRAM on
something fixed at build time.
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
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
