Arduboy & Homemade Development and Compatibility

I’m bookmarking this incident because I think it’s an excellent ‘real-world’ example of why people should avoid relying on hardware-specific details unless they’re hidden behind a library/API.

(Also this means I’ll be able to get this game to run on other consoles in the future.)

1 Like

I am not normally concern with others efforts if they want to migrate it in the future. I use the gcc extensions without any second thoughts …

I keep forgetting about that…

No ports for you! :P

1 Like

I am glad you picked up that (subtle) reference …

I was grimacing for the opposite reasons. This feels very close to “shaming” an author (or you can see where it could quickly lead down that road) for doing something that (in my mind at least) is perfectly reasonable given that Arduboy is (so far) a clear and well defined hardware spec, and a single official device.

Clarification: I don’t think Pharap intended any personal shaming, but I think the idea as stated can quickly lead to that: IE, You’ve been a “bad boy/girl” because you accessed the hardware directly - even if the library provided no API for what you wanted to do. Hardware platforms often support much more than winds up in the official libraries.

It’s fine to point out that “porting can be harder” once you step outside of a clear API, but something here is just bothering me because I feel like we’re trying to say a bit more than that. Maybe I’m just reading between the lines, but I don’t think I am.

Relying on hardware specific details is great if you’re designing to a clear and well defined hardware spec. I think we need to make it clear there is a choice here. Designing for an official specification (which has a very clean niceness and advantages of it’s own) vs designing more generically with the goal of making it easy to do ports to other platforms.

Building to the API is encouraged but people are welcome to code however they like!

1 Like

I didn’t take it that way but I know what you mean. I couldn’t care less about someone else’s problems migrating my code to another platform. If I did, I wouldn’t use the little GCC-specific additions and I would probably comment my code …

As it turns out, I was easily able to change this and Turtle bridge to a different solution that was probably just as fast. I had ideas of painting a textured background on the games as part of the display() function but these never game to fruition. I have changed the code for @FJNM as he asked nicely but not for any other reason.

1 Like

In programming every decision is a trade off. Every decision has its benefits and its drawbacks.

Writing hardware-specific code can sometimes make the code smaller or faster,
but in exchange it makes porting harder.

Both options are valid options, and which option is better depends mainly on the author’s intent.
That is partly why there are so many academic arguments in programming - there’s rarely a single clear-cut answer, but rather many different solutions with very subjective benefits.

I am choosing to remember this specific case because it’s a good real-world example - something that’s often hard to come by.

Usually when explaining concepts to less experienced programmers people have to resort to theoretical examples or anecdotes without evidence and thus the less experienced programmer just has to take their mentor’s word for it.
This is compounded by the fact a lot of development happens ‘behind closed doors’,
so the trials and tribulations involved are hidden.

Writing code in a generic or portable way doesn’t inherantly make it ‘not nice’ or ‘unclean’,
nor does it preclude designing for an official specification.

After all, the Arduboy2 library is designed around the Arduboy hardware.
For example, the graphics manipulation functions require the graphics format to match the format used by the SSD1306.

Remember that an API is also a ‘specification’ of a sort.

With that all said, it should hopefully be clear that I have no intent of ‘shaming’ the author.
There is no shame to be found.

The merits of each approach could be argued ad absurdum,
but what I am interested in is merely the fact that this is a tangible example rather than mere anecdote.


… and late at night!

If I ever get back to our car racing game (no comments please @vampirics !) I will probably use an overridden function of the Arduboy display() library due to the unique rendering I wanted to achieve. In this example, I will be breaking compatibility knowingly and with abandon :slight_smile:

1 Like

As I know the details of the game you’re talking about,
I think that case would probably be far more justified,
purely because it’s actually pushing speed to the limits rather than memory.

Yep … its also pushing my concentration limits.


That isn’t what I said at all. I meant only there is a certain pleasure and simplicity in designing for a very specific spec and NOT having to worry about other concerns. When it works on the target hardware, it’s done, period.

Sure, but let’s not confuse or conflate the library with the hardware itself thought, because they are very different things - the library only supports a fraction of the OLED hardware features, just to pick one example.

Remember that an API is also a ‘specification’ of a sort.

Sure, but if the implication then becomes “code only to the Arduboy2 API, not the hardware” that’s where I’d take issue (and that’s kind of how I read your original post, and what made me respond) . There are a lot of innovative things the screen can do that we’ll never see done if everyone steers clear of them and focuses instead on a “generic 8-bit vertical OLED/LCD interface”.

The one(?) game published that’s greyscale uses custom OLED commands to do the fading between screens. Does that work on other LCD/OLED controllers? I’m not sure if it does. I’m not sure it matters. I think it’d be WORSE to have never seen that innovation happen because someone was too concerned it wasn’t in the core library.

With that all said, it should hopefully be clear that I have no intent of ‘shaming’ the author.
There is no shame to be found.

Yeah I should have been clearer. I wasn’t accusing you per se, just saying I think it’s too easy to go down that road if we’re not careful - even if the intentions are good. Hence me adding my viewpoint to the discussion.

It’s cool to have a “homebrew” community (and I’m the last person who’d try and shut that down) but I also think there is real harm if it leads to avoiding super cool things that ONLY the REAL Arduboy can do - just for the few building custom units from scratch: units that don’t match the hardware spec.

[Note: Yes, I’m very clearly aware that isn’t what was happening in this specific case… it’s the sentiment I’m discussing, not this one particular case.]

Would it also be a good excuse then if someone wanted to use all assembler because they wanted to reduce CPU cycles to push battery to the limits? :wink:

Context always matters when programming, and there isn’t necessarily a right or a wrong way (just different ways). For timing or application critical programming like medical, space or military we tend to shy away from libraries because then you have to fully analyze the static and dynamic performance to ensure that no matter the situation it behaves in a known and deterministic manner. Additionally there’s overhead when using libraries that can throw a monkey wrench into tightly constrained real time systems so sometimes it is best to get low level and deal directly with bare metal. But for something like the arduboy where we need to keep some level of consistency in providing an easy to use platform/environment it makes perfect sense to trade some efficiency for structure. But this structure isn’t mandatory and if a programmer has a specific goal that is hindered by using it then there’s no shame in doing things low level.

I have changed the subject name on this … its really got nothing to do with my game.

1 Like

Wow so many points here. I think the first is to define what “the platform” is. It can get very confusing if you never do that. Is it the REAL Arduboy hardware? Is it the homebrew units also? Is it the emulator?

Because if it’s the actual REAL authorized hardware there shouldn’t be any issue is dealing directly with the bare metal… flash the HEX file to your Arduboy and it will work perfectly - because the hardware is the platform. Doesn’t matter if you use Arduboy2 library at all - or if you write your whole game in machine code.

Now if you’re thinking about Arduboy 2 you might have a different set of concerns… but the library has always been a “volunteer” effort… if the hardware changes vastly there isn’t necessarily a guarantee that games who use 100% library code will easily compile on a new hardware platform. This would be a good question for the Gamebuino people… have they learned anything by producing a second set of hardware? I think someone wrote a “lowest common denominator” compatibility layer (for Gamebuino Classic compiling against Gamebuino Meta).

While if the platform is say the online emulator, then you have a whole different set of concerns/restrictions. (no audio for one)… that’s why I get a little concerned when I see emulators pushed very heavily vs buying real units… you risk redefining what the platform is, and that reduces creativity and pushing the limits of the hardware (since it’s now no longer the hardware, only the limitations of the emulator - which is often FAR more restrictive than what the real hardware does - since it’s often only coded to what people are doing at the time - vs trying for full 100% hardware emulator).

It’s a best practice for sure, but imposing your best practices on someones hobby doesn’t make any sense.

Nobodies incompatible code is going to stop a pace maker or shut down a power plant in this circumstance so it’s mostly just a point to try and “play nice” among other developers.

What if… Arduboy was a… pace maker!

Oh right, no real time clock.


You’d die :skull_and_crossbones: after 6-8 hours :stuck_out_tongue:

What if Arduboy was an actual credit card where you could check your debt real time?

1 Like

If I checked my debt real time, I would also be dead (from shock) in 6-8 hours.