I’ve added @Mr.Blinky to the release notes on GitHub and in the post above. I’m sorry I can’t add him to the commit log because I don’t like to “rewrite history” after publicly and officially releasing.
The post above was all I was expecting.
Whoa! My game went from this 10489 to 10368 bytes from recompile! thanks!
Great and detailed release notes!
Awesome to see a major update on the the Arduboy2 library @MLXXXp and thanks for the credits. Pleased that I could contribute. Looks like I have some work to do for the homemade version now
Another appology: I realised I forgot to credit @Dreamer3 for the concept of how to remove the USB code. This has been corrected in the release notes (but unfortunately, again, I can’t add it to the git logs).
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.
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.
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.)
There isn’t really. However, the boot logo has been sped up, so sketches won’t behave exactly as before
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
You could argue that’s a bugfix.
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.
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.
Yeah, I was kind of thinking that. Its is possible (see what Gamebuino does), but it’s kind of a royal pain.
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.