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.
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.
@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
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
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!
Changing dim() like you did would be a breaking chance for obvious reasons. 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!
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?..
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.
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 #define
d as either enabled
or disabled
when the core code is compiled.
Thanks. That is high praise coming form you.
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.
Thanks, this was really helpful. I will implement it on the custom blinklib.
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.
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).