At the early dawn of the 4th of July, @jbobrow posted his fireworks challenge on twitter, and I had a take at it Sharing the code in case you find anything useful there.
Here is the readme:
My first Blinks app! I tried to reproduce the fireworks that Jon Bobrow tweeted in the 4th of july (here), hopefully you find it useful. Some notes:
This was developed on VSCode (thread to setup here).
Review the config files and adjust based on your environment.
This is my first attempt at Blinks, and last time I used C++ was ~15 yrs ago! So take it with a piece of salt and let me know if there is a better way of doing things.
I was trying to create sort of a framework for easier future expriments…not sure if I succeeded though. Files under fx folder.
StateMachine based, with support for delayed state transitions allowing you to control speed of animation.
Keep in mind I am just starting with all of this Blinks thing, but I did learn a few things since then.
1 - Using classes ends up wasting precious bytes and, I would say close to a 100% of the time, it is not worth it. My strategy for this has been using namespaces, normal typedefs to integral types (or structs, if needed) and functions that take as a first parameter my typedefed types.
2 - Sometimes you do not even need the functions that take your type as there will be only a single instance of it anyway throughout your program. In this case, I simply use namespace-scoped static variables to be the attributes of this single instance.
3 - Because of the nature of Blinks programming (there is a loop that is executed all the time so you can not really wait for anything in a single loop iteration), the state machine approach is definitely the way to go. But using function pointers for the state machine will also waste precious bytes so my approach has been creating the state machine using a switch dispatcher for the functions I need. Seems to be working ok.
4 - Unless you have a function/method that is called only in a single place of your code, inlining will also waste precious bytes (storage in this case) and in a platform like blinks, the performance you would gain with inlining would be completely unnoticeable.
This is all anecdotal evidence, so take it with a grain of salt.
Thanks a lot @BGA for reviewing! These are great comments especially for a platform with memory constraints like Blinks. I had the feeling that what I’m doing will be expensive and memory consuming but I decided to do it anyway and optimize on the first sign of trouble. Not a good strategy for library/framework code though, if at all
I’ll incorporate your feedback once I have some free time and will report back the results.
Tried this! Using namespaces seems to reduce the size in general but at some point size started to increase again not sure why. Looks like multiple factors can be in play here and more investigation or trial and error may be needed. Or perhaps some tools exist that can help guide this code optimization process?
So I’d say having fun and getting quick results, then optimizing at first sign of trouble is a reasonable strategy to begin with
For this specific code, things like state machine, state manager, debug utility, comm utility, are all singletons and namespace will make sense for these (but perhaps having all class members static makes classes not that bad?..can’t tell for sure!)
Sharing the code in case you find anything useful there.