during testing at low brightness I noticed that gradients can be "jumping" in colors quite wildly, turning a smooth gradient into a flickering mess. This is due to the color hue preservation being inaccurate and a bit too aggressive. This can be seen for example using a gradient palette and "Running" FX.
Removing the hue preservation completely fixes it but leaves color artefacts for example visible in PS Fire at very low brightness: the bright part of the flames gets a pink hue. This change is a compromise to fix both problems to a "good enough" state
accroding to the docs of setBufferSize() and svbuf():
> setBufferSize() has to be called right after opening file before any other operation!
so changing buffer sizes on an already opened and partially read file can cause file corruption as the internal buffer is exchanged "mid-flight".
Fix: move all f.setBufferSize() so they appear directly after f.open().
- fixed inconsitencies in size rendering
- fixed palette being wrapped in color by position and color by age modes
- Fixed bug in memory layout: for some unknown reason, if flags come before particles, last flag is sometimes overwritten, changing memory laout seems to fix that
- New color modes in PS Fireworks 1D:
- custom3 slider < 16: lower saturation (check1: single color or multi-color explosions)
- custom3 slider <= 23: full saturation (check1: single color or multi-color explosions)
- custom3 slider > 23: color by speed (check 1 has not effect here)
- custom slider = max: color by age or color by position (depends on check1)
- removed local buffer for ESP8266 in 1D system to save on RAM
- increased particle brightness in PS Impact
- minor tweak in collision binning (might improve speed)
- removed comments and some other unused stuff
- fixed a few compiler wranings
* moving color_blend, color_add, and color_fade to a seperate file, to allow the compiler to inline the functions.
* inlining slightly increases firmware size - original non-inline functions get used on 8266, or when WLEDMM_SAVE_FLASH is defined.
Seems like a 10 microsecond delay on boards like the ESP32-P4 may not be enough, causing some issues with UDP audio sync being delayed or appearing "buffered". Oddly 10 microseconds was fine with the ESP32 and ESP32-S3, so it may also be an underlying IDF v5.3 change.
Practically, 10 microseconds or 100 microseconds isn't a real difference when we're dealing in frames per second.
* use a more meaningful max universes limit of 112 (safe up to 128x128 pixels)
* accept more universes, but only track sequences for the configures max universes
* made e131LastSequenceNumber[] local (its only used in e131.cpp)
