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.
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.
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.
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.
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).
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?
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!
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.
If you use VSCode (if you are still using Arduino IDE, you should switch ), then you just need to add this to c_cpp_properties.json in the IncludePath section:
"${workspaceFolder}/config"
This is just so it will correctly handle those includes and show the right stuff everywhere.
Contrary to what the release notes said before (I updated all references) the blinklib configuration file is “blinklib_config.h”, not “blinklib_settings.h”.
A quick note here. I removed a topic that incorrectly presented a policy about alternative Blinks Libraries and I fear can be misleading. I’ve saved the messages in archive, but want to communicate with full transparency.
There was an internal miscommunication about the new games launching on Kickstarter in the next 3 weeks. I had let @danking222 know that these games we are releasing cannot depend on an external library, but did not intend to suggest a more broad policy. Move38 is dedicated to supporting our community and eager to establish rigorous testing and validation necessary for games to be published with new and alternative libraries.
I removed the topic from the forum because it is not representative an official policy or part of our roadmap. I’m also tagging @jrcwest@Freddicus and @Dudepants who were part of the redacted topic.
