[Discuss] Arduboy2 Development Library

I recompiled RogueBoy and gained over 1k bytes, Great work!


Yes great work @MLXXXp - now I can remove the setRGBled() code that you lent me with the real version!


Super! Great work! I regained 106bytes in my project. :star_struck:

1 Like

Does this have any impact on existing software titles?

I don’t think so … the changes to existing functionality is just performance enhancements / code size reductions.

1 Like

The major version was increased so there should be at least one thing that breaks backwards compatibility.

That said, I can’t find it.
As far as I can tell all the changes are either bugfixes, new features or optimisations

The impact will be smaller/faster code.
(Assuming the games are recompiled with the new library.)

1 Like

There isn’t really. However, the boot logo has been sped up, so sketches won’t behave exactly as before :slight_smile:

Also, the refactoring of setRGBled() broke Circuit Dude by @crait, although this actually just caused an already exiting problem in the sketch to manifest itself in a different, more severe, way.

The main reason I bumped the major version number, though not strictly adhering to guidelines, is due the the large number of changes. Plus, it’s easier to remember and state things like:
If you want users to be able to use the system EEPROM flag to suppress the boot logo, you must compile with version 5 or higher.
Rather than remembering and stating: between 4.1.0 and 4.2.0

1 Like

You could argue that’s a bugfix. :P

For people used to using semver it’s not that hard,
but I guess since we get a lot of beginners here that makes sense.

Is this still an issue? Part of not going back to fix up Circuit Dude was the sound/LED conflict. Is there a suggested way to fix this on my end? I wouldn’t mind updating Circuit Dude to fix it and also touch up the graphics to include his new look.

1 Like

Thinking of making a low-memory / lower speed version of the library… any interest in that being in core and determined with defines? I’m not completely sure I actually want to support the exact same API anyways, but just thought I’d float the idea here.

I always tried to optimize the main library for small size/high speed. But now I’m thinking about really small size/small RAM footprint being the main drivers, which means taking quite a few things in entirely different directions.

But I think such a “sister” library would be perfect for some of the slower paced games we’re seeing that would benefit from more flash storage or more RAM.

It’s probably better to fork and maintain it separately. Using defines can get complicated if there are many changes. Also, it’s not easy to pass defines to an Arduino library, since the libraries are pre-compiled separately from the sketch code.

1 Like

Yeah, I was kind of thinking that. Its is possible (see what Gamebuino does), but it’s kind of a royal pain. :slight_smile:

1 Like

Its an interesting idea - as you say, a lot of games actually do not need the performance or even all of the bells and whistles of the current library and would benefit from extra memory savings.