Custom Blinklib v1.0.0 Beta 1 (v1.2.1 Released)

V1.1.0 has been released.

New In This Release

  • Saved a bit more storage space, now down to 1432 bytes (compared to 1500 bytes from the previous release and 1888 bytes from the original one).
  • Added way to completely disable datagrams and save another 100 bytes or so. Unfortunately this is an advanced feature as I could not find he time to make it work right so you have to manually edit the “blinklib_settings.h” file and uncomment the line that says “#define BGA_CUSTOM_BLINKLIB_DISABLE_DATAGRAM”. This will be improved and simplified in later versions.

Get it while it is hot!


Probably goes without saying but we are definitely following along. For the time being, I think @BGA has the right idea of keeping this going in its own branch and making it easy to install either version. Looking forward to trying out games developed with this version and playing around with it more myself.


All amazing stuff! I think this will enable a new wave of creativity in the blinkverse!

Have you seen the Arduino “care variants” feature?..

This might be a good way to give users a menu option for enabling/disabling of the datagram code.

The “custom board options” might make for an even cleaner solution, but I am not sure how you can have one of the menu options end up as a macro define to the compiler. Seems like it should be possible by maybe passing a -D in platform.txt, but might take some effort to figure it out.

1 Like

OK, I think I figured out how this can work. Check out these minor changes to platform.txt and boards.txt

These create a new menu option in the IDE called Datagrams that can be set to either Enabled or Disabled.


Depending on which option the user picks, the macro DATAGRAM will be #defined as either enabled or disabled when the core code is compiled.

1 Like

Thanks. That is high praise coming form you. :slight_smile:

I saw some discussions about it but for some reason I did not really though of it as an actual solution. But now that you mentioned it I went to check again and yes, that might work. Currently i moved form a specific include to using platform.local.txt which was already better, but definitelly a user menu would be easier. I wonder how the Arduino extension in VSCode handles this.

1 Like

Thanks, this was really helpful. I will implement it on the custom blinklib.

1 Like

Been following this progress for a while, but never tried it until today! I’m loving the space it’s saving me for Ghost Hunters.

1 Like

Great! Let me know if you see any issues. Not sure this would help your game but remember the full 8 bits are now available for face values.

Also, I noticed you are only using face values. If you disable datagram you will get back almost 200 bytes.

I actually think your platform.txt.local solution is superior to my menu-based one! With yours the datagram selection travels with the code that depends on it, whereas with mine you have to remember to manually check and possibly change the menu choice whenever you open a different sketch. Yea, yours is much cleaner.

I never knew about the platform.txt.local before! Thanks again!


Oh awesome! Right! I’ll definitely do that. As for the full 8 bits, I’m embarrassed to say my knowledge of computer science is lacking enough that I’m not sure how that would change things.

No worries. In the end this just means that you can use 256 (0-255) values as face values instead of the usual 64 (0-63).

Also, in your game you are doing bit-shifts to add specific information to the face value (i.e. using << and >>). In this case this also happen to mean that you can add more information to the face value in case you need (or it would help your game).

1 Like

Maybe I am missing something, but wouldn’t they be equivalent? As i understand it, the platform.local.txt file has to stay next to the platform.txt one so not shipped with individual projects. Or maybe I am wrong?

Arg, I just tested it and looks like you are right - the platform.local.txt does not work from the sketch folder.

Frustratingly semi-documented here…

Oh well. Maybe you could implement the extra datagram storage as an optional class, sort of like the way `Serial`` is done? Probably has to waste a byte of RAM so the IR code can check if datagrams are loaded at runtime, but at least clean.

V1.2.0 has been released. This is a feature release but only with minor features. The most relevant one being a better way to enable/disable datagrams (not the menu solution yet as it does not work with VSCode).

New In This Release

  • Better (but still not ideal) way to enable/disable features. Just edit platform.local.txt in the package directory.
  • Added option to enable/disable Blinklib datagram checksums. Disabled by default.
  • Added resetPendingDatagramOnFace(), which resets any pending datagram on the given face, allowing an immediate call to sendDatagramOnFace() to succeed.
  • Fully deprecated markDatagramReadOnFace(). It is now an actual not and you do not need to call it at all. Receiving a datagram automatically consumes it.

V1.2.1 has been released. This version includes a solution for per-project configuration of the Custom Blinklib, libraries that are aware of it and even submodules as I have been using for Hexxagon.

In fact, this is an example of how to generally do this for any Arduino IDE boards and by the amount of people asking about this everywhere wiuthout anyone giving a good answer, this is kind of a big deal. On Blinks first! :slight_smile:

New In This Release

  • Added method for per-project blinklib configuration. Projects might have a config subdirectory now with a blinklib_config.h file that can be used to configure the Custom Blinklib by setting relevant defines.
  • Refactoring of the datagram disabling code. It is now easier to maintain if a bit more complicated to read.
  • Small storage savings for programs that use datagrams.

See my latest release. I managed to find a solution for this.

If you use VSCode (if you are still using Arduino IDE, you should switch :slight_smile: ), then you just need to add this to c_cpp_properties.json in the IncludePath section:


This is just so it will correctly handle those includes and show the right stuff everywhere.

1 Like

Contrary to what the release notes said before (I updated all references) the blinklib configuration file is “blinklib_config.h”, not “blinklib_settings.h”.