@igvina,
Sorry for taking so long getting back to you on this. I’ve spent some time considering the options and experimenting. I was going to send you a private message about it but I think what I have to say may be of interest to others (if they don’t find it TL;DR 
)
The ArdBitmaplib functions could be added to Arduboy2 in a number of ways:
- As new main functions, so you would use them like
arduboy.drawBitmapResized(...). This approach would require renaming at least some of the functions because there are already existing drawBitmap() and drawCompressed() functions with different behaviour.
- As a subclass in the main class, like the audio class, so you would use them like
arduboy.ardBitmap.drawBitmapResized(...).
- As a separate class included in the Arduboy2 library, similar to the Sprites class, so you would use them as you do now:
ArdBitmap ardbitmap;
ardbitmap.drawBitmapResized(...);
I would likely choose using the separate class approach. It makes things easier to maintain and, personally, I think it makes the code in the sketch a bit clearer and more structured.
The advantages of adding these functions to Arduboy2 are:
- They would be instantly available to any sketch using the Arduboy2 library. You wouldn’t have to copy the library files into your sketch or include a separate library.
- The functions could access the screen buffer directly, like the current Sprites class does, instead of using a pointer to the buffer. This would eliminate the need to pass a pointer as an argument to the constructor. It would likely generate a bit less code as well. (More on this later.)
- The functions could use the defined WIDTH and HEIGHT screen dimensions instead of needing the matching definitions that your separate library requires. (Again, more on this later.)
The disadvantages of adding these functions to Arduboy2 are:
- Adding more bitmap drawing functions could increase confusion with using the library. There are already the main drawBitmap(), drawSlowXYBitmap() and drawCompressed() functions, plus those in the Sprites class. I kind of regret even adding the Sprites class for this reason.
- The new functions would be an additional thing that had to be maintained and documented. If bug fixes were required, or you wanted to make enhancements, it might not happen as fast as it could with a separately maintained library under your control.
- The compressed bitmaps require the use of a separate program to compress them. This would either have to be included and maintained in the library, or it’s location would have to be made known in the documentation. (This is already a problem with the existing bitmap functions in Arduboy2.)
I feel that the above disadvantages outweigh the advantages, so I think you should just keep ArdBitmaplib as a separate library. I have some suggestions for you that would address much of the above advantages.
This would allow you to have it included in the Arduino Library Manager, making it easy for users to install in the Arduino IDE.
I also suggest that you drop lib from the end of ArdBitmaplib and just call it ArdBitmap. It’s not common to put lib at the end of an Arduino library’s name. Almost none of the existing Arduino libraries do.
To make your exiting repository Arduino Library Manager compatible you mainly just need to:
- Move the files into appropriately named folders.
- Add library.properties and keywords.txt files.
- Remove the local copies of the library files from the included example sketches. They will then use the installed library.
- (I’ve done all this. See below.)
Make the library a template class
This is a bit radical for an Arduino library but it would allow it to directly access the screen buffer. It would also allow you to specify the screen width and height as parameters instead of having to hard code matching values in the library’s header file.
Creating an instance of a template class is a bit more work than a regular class, but it’s still pretty straight forward.
Another advantage of using a template is that code can be conditionally compiled based on macro definitions provided by the sketch. Regular classes in Arduino libraries are logically “compiled” separately, before the sketch code, so a sketch can’t pass a #define to them. However, templates are logically “compiled” when the sketch includes the header file that contains them, so they can see any #define that comes before the #include.
Your library uses two macro values, SPEED_HACK and RESIZE_HACK to optimize for speed or code size. With a template class, a sketch could set these or similar macros to influence the generated code, without the need to edit the library source code.
My tests have shown that generated code size, using a template class in a separate library, is the same or sometimes even smaller than having the class included in the Arduboy2 library.
I’ve already forked your library and made the above changes. My fork is at:
Edit: I’ve deleted my fork because its changes have been merged into @igvina’s original repository.
-
ArdBitmaplib has been renamed ArdBitmap everywhere. You would probably want to rename the repository itself on GitHub, as I did with my fork.
- I changed the library version number to 2.0.0, in accordance with SemVer rules, since using a template changes the API. Since the library hasn’t been previously released as an official Arduino library, this strictly isn’t necessary. You could leave it at version 1.x.x if you wish.
- I changed the SPEED_HACK macro to NO_SPEED_HACK and used #ifndef instead of #ifdef, since a sketch can’t undefine a macro that’s been defined in the library. You can change the name or logic if you wish. I didn’t document the use of these macros in README.md because I don’t know if you want them to be “officially” available to the user as part of the API.
- I changed README.md with instructions on using it as an Arduino library and as a template class.
- I set architectures=* in library.properties, meaning all CPU architectures are supported, since there’s no AVR specific code in the library. I tried your CompleteTest example sketch on my ARM based prototype and it ran fine. The fps remained above 60 for all the tests
I can create a pull request from my fork to your repository on GitHub. Or, you could pull my changes to a local working repository, make any desired changes, and then push to your GitHub repository.
If you want to submit the library for inclusion in the Arduboy Library Manager, I can help with that. I’ve already done Arduboy2, ArduboyTones and ArduboyPlaytune.
For anyone else who’s read through this whole thing, I hope you didn’t find it a complete waste of time 
