Custom Blinklib V1.3.7 Released

Another small release, this time just so I can save another 1% of storage space. The actual change was pretty simple but interesting so I will mention it here. This was the dim() function in the previous Custom Blinklib version (pretty close to the one in the official Blinklib):

Color dim(Color color, byte brightness) {
  return {1, (byte)((color.r * brightness) / MAX_BRIGHTNESS),
          (byte)((color.g * brightness) / MAX_BRIGHTNESS),
          (byte)((color.b * brightness) / MAX_BRIGHTNESS)};


One way to do faster division is using bit-shifts instead, but that has the annoying property of only working with powers of two, which 255 is not. BUT it is close enough that we can do a simple approximation taking advantage of the fact that integer divisions always rounds the number down. Here is the new version:

Color dim(Color color, byte brightness) {
  return {1, (byte)((color.r * (brightness + 1)) >> 8),
          (byte)((color.g * (brightness + 1)) >> 8),
          (byte)((color.b * (brightness + 1)) >> 8)};

One simple way to show how this performs is testing the bounds (as it is easy to see that the middle ranges would be ok). Let’s assume we are dealing with a mid-brightness white. Each of the colors components will be 15 (it is 5 a bit color component, so it goes from 0 to 31):

brightness = 0 : {0, 0, 0}
brightness = 255 : {15, 15, 15}

Which is what we expected.

New In This Release

  • Reduce storage requirements by another 1% by slightly rewriting the dim() and lighten() functions.
1 Like

BTW, while working on this release I played with doing some changes to the IR transmission. I actually got another 1% of storage back out of it but the changes I was doing resulted in more data being transferred in average and this had a negative impact on general perceived performance (not to mention that faces would timeout all the time in pathological cases.

I am now trying to figure out what is an actual reasonable size for datagram packets (currently it can be up to 16 bytes) as bigger datagrams actually end up breaking communications virtually all the time.

Another thing is something I already mentioned before: Using arbitrary types for face values (so they could be bigger than 1 byte). That has the same issue of increasing the amount of data transferred through IR so needs more careful consideration on how to do it.