The thing about standard libraries, like Arduboy2, is that if you remove a documented API function that has been used in a sketch, then that sketch will break when compiled with the new library release. It’s better to leave the old function there even if the new function is improved in a way that leaves no reason to use the old one for new development.
In the specific case of drawCompressed(), one could argue that there are currently very few sketches using Arduboy2 so far, and the chances that any are using drawCompressed() is very likely zero, so nothing would break by removing it.
However, it’s unknown if there are some games in development and are near completion in which the author has chosen to use Arduboy2 with drawCompressed(). If the function were removed it may cause the release of a game to be delayed because the developer would have to spend time recompressing the bitmaps and switching to the new function.
It’s also possible that someone may wish to modify or extend a Team A.R.G. game but wants to take advantage of something that Arglib can’t do but Arduboy2 can, such as playing multi-tone effects using the ArduboyTones library instead of the simple single tone function in Arglib. Since I’ve made Arduboy2 highly Arglib compatible, replacing Arglib with Arduboy2 is generally quite easy (as I found with the 4 that I quickly converted). If drawCompressed() were removed, it may make doing this kind if thing a more difficult.
If it turns out that drawCompressed() has no benefit whatsoever over the new function then I would note that fact in the documentation, recommending the new function be used for all new development.
This will depend on how fast it runs and how much code space is saved. It will probably end up to be a decision made for each game, depending on its requirements. In some cases it might not be obvious if using compressed or uncompressed bitmaps is better, so just experimenting and observing the results will be required. Some people may also wish to use the dedicated Sprites class in the Arduboy2 library due to its masking and frame handling capabilities.
The compiler can produce some pretty strange output sometimes. For instance, the following sketch will compile to 7670 bytes but if you uncomment the second arduboy.display(CLEAR_BUFFER); so that there are now two identical calls in a row, the code size is REDUCED by 10 bytes to 7660! Huh??
Thanks so much for this library - it’s been really helpful. (But it was a bad/inconsiderate idea to call it arduboy2 - it’s unnecessarily stomping on the name of the official library. Also I was confused when I got the arduboy first what library to install - I would have called it something like “arduboy_plus” - it’s too late to rename now I guess, but I would recommend making it clear in its description in the arduino database that it’s an unofficial fork, not just a fork - people may not know what ‘fork’ means. But, to reiterate, I’m grateful that it’s out there, and I’m using it in several WIP projects, so thank you!)
External display libraries can use it. For instance, ArdBitmap needs to be given an expression to access the screen buffer. Previously, for ArdBitmap you would use:
#define ARDBITMAP_SBUF arduboy.getBuffer()
but now you could use
#define ARDBITMAP_SBUF arduboy.sBuffer
which would create less code and be a bit more efficient.
My ArduboyLife sketch directly accesses the screen buffer, though it does it via a pointer obtained using getBuffer(). I haven’t yet updated it to use sBuffer directly. (I haven’t even switched it over from Arduboy to Arduboy2 It’s on my todo list. )
Yes, but it doesn’t really matter. frameCount is only used by everyXFrames(), so if a developer wants to mess with writing to frameCount (for reasons that are beyond me) then that’s on them. Other than affecting everyXFrames() it won’t cause any other problems with library frame handling.