[Discuss] Arduboy2 Development Library

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.

1 Like

Perfect, I only wanted you both to know, I don’t mind drawCompressed() getting ditched or replaced.

(Blob Attack is our only game using it …)

Now the vertical/horizontal mirroring sound like something interesting, even more for uncompressed stuff

1 Like

We discussed this before… I think there should be a drawBitmap overload that includes a parameter that can be flipped, rotated, or both. We can define a few keywords for this parameter, too.


Thanks for all the feedback. I almost have finished the draw function optimizations, I hope to publish it tomorrow, then @MLXXXp could tell me the best way to integrate it on Arduboy2 library.

About the parameters (mirroring, rotation, resize) all could be included on uncompressed staff also. This is what I have found about the complexity:

  • Horizontal mirror: Trivial, almost no more code (in fact I did this on my game Bangi).
  • Vertical mirror: Easy, extra work is to flip all the bytes of the image.
  • Rotation: 90º and 270º could be slow to apply in real-time in games running at 30/60 fps.
  • Resize: Similar or even a bit more complex than rotation.

Anyway, I hope that people use compressed staff also during the gameplay. :sunglasses:

1 Like

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?? :confounded:

#include <Arduboy2.h>

Arduboy2 arduboy;

void setup() {
//  arduboy.display(CLEAR_BUFFER);

void loop() {

You are right, it depends a lot of the type of game. It works better if the game has big images/sprites and no masks (you need to decode 2 images).

My draw method is about 500 bytes (it depends of the compiler optimizations), using this could be worth even for a game with only a 128x64 (1 Kb) splash screen image.

I’m working on a demo to test the performance of my decoding/encoding code. I think that a good pixel artist/animator could do better stuff to play in the great Arduino! :wink:


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!)

1 Like

Great work. Thanks Scott.

has anyone used the sBuffer[] command in their game yet? I’d be interested to see how people are implementing it.

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 :astonished: It’s on my todo list. )

Doesn’t this also mean it can be modified? Probably should have a function to return a read-only copy.

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.

How do I switch off the RX/TX LEDs?

When are they coming on? Are you trying to control them?

Not trying to control them in any way right now, they seem to be on by default, with or without the sub connected.

@spinal, Sounds like a hardware problem or a bad sketch has been loaded. Does it happen with all sketches?

my mistake, I was building for micro instead of leonardo.

1 Like

Amazing, thank you for your work!

So nice to gain AGAIN 1 kb with this update !

Thanks @MLXXXp and @Dreamer3


Thanks to @MLXXXp and @Dreamer3

Awesome! Amazing work as always! :taco:

1 Like