I painstakingly created the equivalent C++ once (as literally as possible).
It’s here if anyone wants to see it, but I don’t think I’d be prepared to guarantee that it’s bug free.
(On second thought, it was actually this that Adafruit used,
and I never got round to putting this into my other port.)
Indeed. There’s a lot more functions that use hardware-specific code.
Of those, things like
generateRandomSeed() are likely to be overlooked.
Interesting… It looks like they’ve used the
SpritesB code as a base and modified it.
Those should more or less work out-of-the-box unless
long is a different size on your system.
I have ported as much of avr-libc as Arduboy uses,
but there’s probably the odd game that uses something that isn’t covered.
srandom, if you’re on a 32-bit system (with access to the C or C++ standard libraries) you can cheat by using
Indeed I have.
There was (and still is) code in
Sprites.cpp that depends on 16-bit integer overflow and it breaks when
int is suddenly 32-bit.
ofs + WIDTH causes overflow, and the code relies on that.)
When I finally figured out the problem I wrote a longwinded tirade about solving it because it took me at least a few hours to get to the bottom of the issue.
For future ports I recommend just using the contents of
SpritesB instead because it’s less hassle.
(If the CPU is powerful enough that is.)
I’m fairly certain that’s the only case though.
I can’t speak for other libraries of course, but for Arduboy2 that’s all.
I’ve never encountered a case like this, but I wouldn’t be surprised if one exists.
This is one of the reasons I try to encourage people to use the fixed width types instead.