DDP Transmit RGBW Fix #35
Conversation
| @@ -771,7 +771,7 @@ uint8_t realtimeBroadcast(uint8_t type, IPAddress client, uint16_t length, uint8 | |||
|
|
|||
| // write the colors, the write write(const uint8_t *buffer, size_t size) | |||
| // function is just a loop internally too | |||
| for (size_t i = 0; i < packetSize; i += 3) { | |||
| for (size_t i = 0; i < packetSize; i += (isRGBW?4:3)) { | |||
| ddpUdp.write(scale8(buffer[bufferOffset++], bri)); // R | |||
| ddpUdp.write(scale8(buffer[bufferOffset++], bri)); // G | |||
| ddpUdp.write(scale8(buffer[bufferOffset++], bri)); // B | |||
There was a problem hiding this comment.
if isRGBW, should the function write out the fourth value, too? Or not needed in this case?
There was a problem hiding this comment.
Yes, that's the idea. It will write 3 or 4 values depending on RGB or RGBW.
Right now it's always increasing by 3, but if RGBW is in use, it's going to write 4 values.
If you have 100 RGB, that's 300 values.
If you have 100 RGBW, that's 400 values.
The 300 and 400 are calculated correctly above the loop.
If it's trying to get to 400 values in steps of 3, the loop will have written 400 values by the time i is at 300 (because of the if statement) - so everything where i>300 is ??? for RGBW
There was a problem hiding this comment.
bufferOffset++ self-increments so it'll keep incrementing possibly past the actual data available if we're in RGBW mode.
I'm gonna assume DDP RGBW needs this because of the optional 4th packet for white. I did this in Art-Net Transmit as well.
Untested (and, frankly, unlikely to be used by anyone), but seems more gooder.