Squashed commit of FXparticleSystem

[DedeHai]

FX particle system ready for review.

[blazoncek]

Unfortunately on my dev build:

Linking .pio/build/wemos_d1_mini32_debug/firmware.elf
Retrieving maximum program size .pio/build/wemos_d1_mini32_debug/firmware.elf
Checking size .pio/build/wemos_d1_mini32_debug/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
Error: The program size (1578750 bytes) is greater than maximum allowed (1572864 bytes)
RAM:   [===       ]  26.6% (used 87072 bytes from 327680 bytes)
Flash: [===*** [checkprogsize] Explicit exit, status 1
=======]  100.4% (used 1578750 bytes from 1572864 bytes)

[blazoncek]

A bit long names...

[blazoncek]

Suggestions:

• fire tends to burn on the left side of the matrix
• waterfall tends to splay on the right hand side
• rotating spray would benefit of random alternating rotation
• volcano never fills entire height
• fireworks might be better to have white firing pojectile

[blazoncek]

Looks extremely good.
The only downside is hefty increase in image size and slow FPS.
None of the effects achieve more than 50-58FPS on 20x20 matrix on ESP32 (desired FPS was 80).

[DedeHai]

-On my build (ESP 32 S3 with AR) the increase in code is 1% or about 16kB. Do you have a map file of sorts? 1.5MB of code is huge for an embedded system... do you know what uses the largest slices of space? Maybe there is room to optimize somewhere else to make it fit?
-FPS can be increased by limiting the number of particles. I did not target 80FPS but 40FPS which IMHO is enough for the effects to look smooth. But parameters can be adjusted to increase it. Should I take a look at that? I can test on ESP32 S3 with 32x16.
-Effect Names are TBD I put 'particle' in every name just so I can easily filter them in the list. Open to suggestions.
-I will take a look at your suggestions (some may be bugs: fire, waterfall)
-Fireworks in white is a good idea, as 'exhaust' is only orange if using rainbow palette (I added this effect before adding the possibility to set saturation)
-Volcano: I can adjust the settings range, I tested on 16x16 where it goes to top. Any matrix target size to optimize for? I assumed 8x8 as a minimum but no maximum height. suggestion: slider settings such that 32x32 (I can test on w16 x h32) is still filled (some other animations may also need adjustment for that)

[DedeHai]

I looked at your other points:

• fire tends to burn on the left side of the matrix

cannot reproduce. any specific settings this happens?

• waterfall tends to splay on the right hand side

this is something I already noticed, 'inequality' happens also in other animations.
I think the reason is somewhere in the collision handling and integer math favouring that direction. So far I could not figure out what it is exactly. but it has nothing to do with the 'pushing' part as it also happens if I disable particle pushing.

• rotating spray would benefit of random alternating rotation

There is an option checkbox left in that animation, so I can add it. I put it on my todo list.

[blazoncek]

any specific settings this happens?

no. fire was definitely more prominent on the left side of the matrix. default values.

[DedeHai]

• volcano never fills entire height

I set my 32x16 matrix to vertical (w15 x h32) and volcano fills to the top easily if particles speed is set high. But depends on collision settings and bounceX setting.

[DedeHai]

I looked at the possibility to limit the total amount of particles to make transistions faster but that is not really an option. fire on a wide matrix (32 pixels in my case) uses A LOT of particles to make it look good, over 1000 (this may be excessive, can probably be somewhat optimized). Also the rotating particlespray uses 700 particles (I tuned this with 16x16 matrix). So it could be limited to about 1000 but that will not help if transitioning between effects that use collisions and less particles (like particle box and volcano for example). So not a good solution without crippling some of the FX...

[blazoncek]

Let's see if @Aircoookie agrees on this PR. It gets my approval, except for the long names.

IMO the next iteration would be to try to replace older effects (1D) with particle system if the resulting code size or performance would be better.

[DedeHai]

any specific settings this happens?

no. fire was definitely more prominent on the left side of the matrix. default values.

I was able to reproduce this now. I think I fixed it, will be in upcoming updates. Turns out random16() is not random enough for some things

[softhack007]

Unfortunately on my dev build:

Linking .pio/build/wemos_d1_mini32_debug/firmware.elf
Retrieving maximum program size .pio/build/wemos_d1_mini32_debug/firmware.elf
Checking size .pio/build/wemos_d1_mini32_debug/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
Error: The program size (1578750 bytes) is greater than maximum allowed (1572864 bytes)
RAM:   [===       ]  26.6% (used 87072 bytes from 327680 bytes)
Flash: [===*** [checkprogsize] Explicit exit, status 1
=======]  100.4% (used 1578750 bytes from 1572864 bytes)

Similar observation on the 8266 github build - this feature pushed FLASH (program) size over the limits.

I think it would be best to have a build flag to disable the particle system feartures - similar to WLED_DISABLE_2D.

This would allow to build some environments without particle system, and have some program space left for other things like usermods.

[blazoncek]

The latest push will not build successfully on ESP8266.

[DedeHai]

I think it would be best to have a build flag to disable the particle system feartures - similar to WLED_DISABLE_2D.

I added WLED_DISABLE_PARTICLESYSTEM that can be used as a build flag.

[blazoncek]

Please undo changes in platformio.ini and FX_fcn.cpp as they are irrelevant for this PR.