Why abort it when you can remove it and not have to deal with it in the first place?
The RIGHT button method was there before I added the EEPROM flag. I didn’t want to remove it, for backwards compatibility. Plus, some people may wish to have the logo when showing off the Arduboy to a friend but still be able to abort to get to the game quickly otherwise. Or, maybe two people share the unit and one likes the logo but the other doesn’t.
But the EEPROM flag is so new that if the reason for removing the logo is “to develop quicker” rather than “to gain program memory”, some people may change their mind once they are aware of this.
Also, adding the option to not use the LEDs may influence people who find them annoying but otherwise like or don’t mind the logo.
Then like I said, take a copy of the gist, edit it to include the relevant information and then upload it as another gist.
How do I use the eeprom flag to get rid of the logo?
As stated in a previous post in this topic (and in the Arduboy2 library documentation):
I won’t have time during the next 5 hours or so, or maybe quite a bit longer.
Then perhaps you should either unlist the thread to stop more votes rolling in or just forget it and let it be.
One of the polls already has 10 votes.
Too… many… polls…
IMO begin should be used in most cases and I see the led flashing and Logo animation is part of arduboy. Just as the Gameboy has it’s logo animation and jingle. The animation is short and waiting for it is neglectible compared to modern gaming platforms anyway.
The only reasons when boot should be used is when one of the other drawing methods is used or some extra code needs to be executed. The logo should only be omitted if there is not enough PROGMEM available.
If the logo animation is annoying for developers they could use an #ifdef directive to disable it (and splash screens) during development. With the new 5.0.0 release of the Arduboy2 library the logo can be disabled by an EEPROM preference as a choice.
I see the right button press to skip logo feature as a legacy development aid and can be removed to free some PROGMEM
I really don’t want this topic to be buried without an outcome.
I wonder if anyone has ever used the Arduboy in this way. Apart from @eried who has a suitcase ful of Arduboys that he takes to work and back, I bet most Arduboys have never left the house.
Also as it wasn’t unlisted I think it’s too late to add those changes given the number of votes that have been placed.
To be honest I think the real thing to take away from all this is this poll.
88% of 8 voters said "just let people use what they want"
Which is kind of the point I was hoping to prove in the first place.
We can debate it until the cows come home, but at the end of the day people will just go with what they like using, so why bother trying to convince anyone otherwise?
(That said, I’m kind of surprised at the support for a
bootNoLogo function. Perhaps that one really is worth considering?)
Guilty as charged.
The difference is that actually couldn’t be removed.
The Gameboy wouldn’t run if the cartridge didn’t have that bitmap stored correctly (or at least part of it in the earlier models).
I agree with that one, I don’t think many people were even aware that was a thing.
Personally, I don’t think so. I don’t think this survey emphasized enough that the logo can now be suppressed by an EEPROM flag on a per unit basis. One thing the survey shows is that a main reason for removing the logo is It helps me develop/test quicker. So with having the EEPROM flag, the main reason for developers to leave it out is now to gain code space. Developers who are developing such large sketches are likely to be competent enough to know or learn how to use boot() + feature calls properly.
Plus, when looking for code space, sketches that don’t use sound will likely want to remove the systemButtons() and audio.begin() functions in addition to the logo. Sketches that do have sound, but include a menu or other way to toggle sound, will still want to remove systemButtons(). And, for more savings, they’ll want to replace flashlight() with safeMode(). So again, since now the primary reason for removing the logo is to gain code space, having only a beginNoLogo() function, which doesn’t remove other unneeded functions, doesn’t make sense.
Now, it appears that the polls show that many people are fine with the logo except they don’t like the use of the RGB LED. I think the extra 22 bytes of code required to add an EEPROM flag, that causes the LEDs to stay off in the logo sequence, are acceptable to allow this. I’ve already written the code to do this but it needs to be documented, and the setSystemEEPROM example sketch needs to be updated to allow people to actually set the flag. (I may also be able to save a few bytes elsewhere to reduce the overall size added.) I’ll try to get a release out fairly quickly, that will allow suppressing the logo LEDs.
The trick, as usual, will be making developers aware of how to properly use boot(), and everyone aware of how to tailor their Arduboy(s) with the desired EEPROM settings. And, getting sketches released as .hex files recompiled and re-released.
I think you’re giving the people who answered the survey too little credit here.
When I edited that information into the post there were still less than 10 votes on most things and I’m willing to believe most people who voted already knew, or it wouldn’t have skewed their answer anyway.
I could throw in another poll to ask, but I think that would make @eried scream in horror.
Some people opt to do that prematurely in anticipation of having to do it later.
Large memory use doesn’t necessarily imply complexity.
Some games naturally take up more space, and some less experienced programmers don’t know much about compression tecniques and as a result end up with larger programs than what an experienced programmer would produce (e.g. not realising they can shoehorn two numbers into a single byte, one per nibble).
Again, not necessarily. They may want to provide both as an option for the sake of usability.
Experience would indicate that the best place for this would be the forums. I get the impression people tend not to bother with the documentation and prefer to just ask on the forums or read examples on the forums.
In fact I think mentioning the 5.0.0 release on the forums meant more people were aware of it and the added features than had it just been updated on the github page.
“prematurely” being the key word here.
So we should help and educate them on how to gain more space, and possibly avoid removing the logo, rather than making it easy by providing a bootNoLogo() function.
And that’s fine. Using boot() or just sticking with begin() allows this. I still don’t think it justifies bootNoLogo().
Agreed. This is why I continually ask “Why are you using boot() to suppress the logo?”. It’s not nagging so much as wondering if they are aware of why they did it and if they know there are other options (such as, now, the EEPROM flag). And, in a sense, it’s my own personal poll on the matter.
I still dont really know how to suppress the boot logo from eeprom, and wouldnt i still have to deal with the leds?
To be more explicit:
- Load the setSystemEEPROM sketch into the IDE.
File > Examples > Arduboy2 > setSystemEEPROM
- Upload and run the sketch.
- Press LEFT for the flags menu.
- Press RIGHT to change show boot logo to NO.
- Press B to save.
- Press DOWN and it should tell you that the show boot logo flag is off.
Now, you shouldn’t see the boot logo for any sketch compiled using the Arduboy2 library version 5 or higher.
Not if the EEPROM is set to not show the logo at all. As mentioned above, I’m planning to add another flag to leave the LEDs off during the logo sequence.
As for the use of the LEDs in the sketch itself, I can’t do anything about that. Perhaps suggest to the authors that they provide a user option to leave the LEDs off.
Personally I think the boot logo and LED adds a little nostalgia but at the same time I would bin it an instant if a game required the extra space.
There’s never going to be a perfect solution and when some refuse to share code and only release a .hex there’s little choice, making the whole thing moot.