Fix backlight loop effect crash

[DaanCMP]

Problem

The backlight loop effect (case 255) was causing ESP8266 crashes after completing one full cycle. The issue occurred because:

• loopIndex variable incremented indefinitely without bounds checking
• When loopIndex exceeded BACKLIGHT_NUM_LEDS, it caused array bounds violation
• This resulted in accessing invalid memory, causing the ESP8266 to crash
• The first LED would stay lit at full brightness before the crash

Solution

Added bounds checking and proper loop reset:

• Added bounds check: if (loopIndex >= BACKLIGHT_NUM_LEDS)
• Reset loopIndex to 0 when it reaches the end of the LED array
• Separated array access and increment for clarity and safety

Changes

• Backlight.cpp: Added bounds checking in the loop effect (case 255)
• Prevents array bounds violation when loop completes one cycle
• Ensures continuous looping without crashes

Testing

• Loop effect now safely cycles through all backlight LEDs continuously
• No more crashes or memory violations
• Loop resets properly and continues indefinitely

[Winston-Lu]

use a modulus instead to be a bit more compact and not need to branch (would likely be optimized out anyways)

[Winston-Lu]

appreciate the work though in fixing something i never tested (i got lazy)

[Winston-Lu]

could you also confirm that the changes work? Gave my own shelf away since i was moving to a different country so I dont have a means of testing it myself anymore

resolved

[DaanCMP]

Haha i got the feeling that this was untested already. I might refracture/update it tonight because there are some more things broken. (like the brightness control not working at all).

I'd like to add some functions like a countdown clock or something but i'm right at the edge of IRAM. I'm thinking of moving the grid to progmem, might be slower but i'm wondering what the actual difference will be.
I could also try to calculate the grid on-demand, but idk if thats feasable

[DaanCMP]

could you also confirm that the changes work? Gave my own shelf away since i was moving to a different country so I dont have a means of testing it myself anymore

Will let you know later tonight

[Winston-Lu]

feel free to try whatever, this project was done in my early days of C++ before i had any of my code reviewed before, but likely a lot of memory is being taken up by the arrays of the RGB pixels. We should still have enough budget to calculate things on runtime if needed, the worst one for runtime is the gradient since I calculate each pixel every time instead of caching or saving results, but the rest should run at 30+fps