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

Iā€™m not using datagrams, just the face values. That would be nice to free up even more space for that if possible.

I juts hacked this up. When datagram support is disabled, any calls to datagram related functions will return the zero value for the return type or will symply do nothing in case of void functions.

Here is my current custom blinklib with datagrams enabled:

Sketch uses 1504 bytes (25%) of program storage space. Maximum is 5888 bytes.
Global variables use 683 bytes (66%) of dynamic memory, leaving 341 bytes for local variables. Maximum is 1024 bytes.

And here is it with datagrams disabled.

Sketch uses 1362 bytes (23%) of program storage space. Maximum is 5888 bytes.
Global variables use 473 bytes (46%) of dynamic memory, leaving 551 bytes for local variables. Maximum is 1024 bytes.

Non-negligible storage savings and a considerable memory saving. Considering the amount of games that only use face values around, this might be worth it.

4 Likes

Another real world test. Now I used the new Move38 game, Crownfall. Again, no modifications whatsoever in the game:

Original Blinklib:

Sketch uses 5654 bytes (96%) of program storage space. Maximum is 5888 bytes.
Global variables use 725 bytes (70%) of dynamic memory, leaving 299 bytes for local variables. Maximum is 1024 bytes.

Custom Blinklib:

Sketch uses 5230 bytes (88%) of program storage space. Maximum is 5888 bytes.
Global variables use 718 bytes (70%) of dynamic memory, leaving 306 bytes for local variables. Maximum is 1024 bytes.

Custom Blinklib with datagrams disabled:

Sketch uses 5096 bytes (86%) of program storage space. Maximum is 5888 bytes.
Global variables use 508 bytes (49%) of dynamic memory, leaving 516 bytes for local variables. Maximum is 1024 bytes.

Hey @jbobrow, in case there was something that was left out from Crownfall due to space constraints, maybe it can be added now. :slight_smile:

3 Likes

@BGA how do you disable datagram support from a project using this library? or do you have that exposed, yet?

I need to do a new release. I was waiting to do it in a proper way (currently it is hacked together) but if it will help you, I can do a release as is. One I do it, you just need to enable a define in your sketch to disable datagrams completely.

This is amazing :open_mouth:

I installed this and switched Terrarium over to use it. Not only did it work without issue, it shaved off almost 400 bytes from my compiled sketch size :astonished:

The project went from 5612 bytes (95%) to 5238 bytes (88%). Data space also saved ~10 bytes, which was welcome.

I am now rethinking future plans in a good way. For instance, using all eight bits of the IR interface will let plants grow larger because I can easily transmit larger packets of plant energy.

I did apply my own mods as mentioned in my post on optimizing space. Namely changing dim() to be a nop (saves ~100 bytes) and changing setColorOnFace() to accept a pointer to the color instead of the color struct itself (saves 80 bytes).

Great work @BGA!

3 Likes

Changing dim() like you did would be a breaking chance for obvious reasons. :slight_smile: The setColor change can be done by simply adding a new variant without breaking things so I might as well do that.

Oh yeah, totally understand about keeping dim. Other games surely use it so it canā€™t be changed. The issue I see is that blinklib itself uses dim, which forces that function to be included regardless of whether the game uses it. Ideally blinklib would use a lighter-weight algorithm.

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!

4 Likes

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.

4 Likes

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

Have you seen the Arduino ā€œcare variantsā€ feature?..

https://arduino.github.io/arduino-cli/platform-specification/#core-variants

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.

image

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!

2 Likes

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