If I do add this feature, I was thinking of maybe displaying the ID near the bottom of the screen during boot up, below the ARDUBOY logo, if the game uses the Arduboy2 class and begin() (not Arduboy2Base because it doesn’t support text). I think it would be nice to have your initials, or whatever, displayed during boot.
This would be another “startup feature” function, separate from bootLogo(), so it could be left out when using boot(), as another option for saving space.
Pretty nifty idea, but with the simplicity of the Arduboy, it may look cluttered. Are we using a smaller boot logo? If so, it may work.
In general, I really like the idea of customizing the Arduboy somehow with universal settings. I love the global sound on/off feature.
I do too, but I also don’t want to get complaints that it’s too short, so I’d like to get some consensus before I do it.
Maybe we can compromise and make it 4. This way the set/get functions could use an ASCII packed uint32_t (a long) for the parameter, instead of needing some kind of string pointer or something.
I’m thinking I would display the ID only for a second or so, horizontally centred at the very bottom of the screen, and only after the ARDUBOY logo finishes scrolling down. The logo would scroll down and stop at the centre, the blue RGB LED would go out, then only after this would the ID be displayed for a short time.
If that looks too cluttered, we could see how it looks to clear the screen after the logo stops and then display the ID by itself for a second or so, centred both vertically and horizontally where the logo was.
Yeah, we can definitely play around with it and see what looks best.
The feature can be simulated, to see what looks best, even before adding it to the library. The ARDUBOY logo doesn’t automatically get cleared, so a sketch can set the cursor and write text anywhere on the screen with the logo still there. Or, you can clear the screen first, to see how it looks without the logo.
Personally I would keep more than just a few bytes free for this idea. Perhaps 8 or 16. That way it could be used for other user settings also, screen contrast (if that’s possible), sound on/off etc.
@spinal, we’ve already set a good amount of memory aside for stuff like that, but the only setting we’ve really ever come up with was sound on/off.
P.S. - There’s no contrast on the Arduboy. 
Only black and white!
adding text to the boot, means adding a font, means more bytes used …
Because we do everything sprite based (even text), we probably won’t take advantage of it.
BUT on the other hand if you’re already using highscore with a font, it won’t take much extra bytes.
And besides all of that I would go for 5 bytes.
(OT, so to discuss this further start a new topic.)
Actually, the display does have a contrast setting but its range is so narrow that it’s hardly worth changing.
Yes, that’s why I said it would only be available if the sketch used the Arduboy2 class, which pulls the font table and much of the text generation code in anyway.
The ideal length is going to depend on the actual purpose. (“stored” means stored in a non-volatile way, in this case in EEPROM, such that it survives power cycles):
A text ID stored in multiple places, such as in each entry of a high score table. This should be long enough to allow many unique combinations but short enough not to take up too much space. 3 bytes is a common length used for this.
An ID used only to differentiate between multiple units for multi-unit/multi-player gaming, as discussed in this topic. This doesn’t even have to be human readable. It should be long enough to uniquely identify a fair number of units but short enough to allow any code written to compare them to be small and efficient. A 16 bit (2 byte) binary value would likely be sufficient for this. Even using only 1 byte would be good for up to 256 units but may require frequent changing to avoid conflicts.
How does this sound?:
Have both a 6 byte text ID and a 2 byte binary ID, making 8 bytes total stored in system EEPROM.
For the text ID, the get/set library functions would each accept a pointer to a null (0x00) terminated string array in RAM provided by the sketch. The allocated array would have to be at least 7 bytes long, to hold up to 6 characters plus a null terminator. It would probably be a good idea to disallow 0xFF, treating it as a null, since that’s the value of an erased EEPROM byte.
If a sketch wanted to pre-populate a high score entry, it could use the first 3 (or whatever) characters of the text ID then allow the user to change it if desired. This is no more difficult for the user than having to enter into a blank field.
For the binary ID, the get function would return a uint16_t and the set function would accept a uint16_t.
// prototypes in Arduboy2.h:
void setUnitName(uint8_t* name);
uint8_t getUnitName(uint8_t* name); // returns the actual length of the string
void setUnitID(uint16_t id);
uint16_t getUnitID();
// usage in sketch:
#include <Arduboy2.h>
Arduboy2 arduboy;
byte unitName[7];
unsigned int unitID;
arduboy.getUnitName(unitName);
arduoby.setUnitName(unitName);
unitID = arduboy.getUnitID();
arduoby.setUnitID(unitID);
I know and I still think 5 is ok 
BUT I agree with [quote=“MLXXXp, post:20, topic:2638”]
Have both a 6 byte text ID and a 2 byte binary ID, making 8 bytes total stored in system EEPROM.
[/quote]
Sounds absolutely perfect!
Woah! I’ve been gone for a while and this idea has escalated into a full-on discussion with people theorizing and posting scripts into the chat! I’m very new, and have no idea how to do something like this, with a very basic knowledge of hardware and software in my 7th grade mind. I would love to see this idea become reality, as me and my friends would love to set nicknames to our arduboys. 
I’ve started working on this in the Arduboy2 library. I hope to release it soon.
The only difference from what I proposed above is that I’m using read and write in the function names instead of get and set.
uint16_t readUnitID();
void writeUnitID(uint16_t id);
uint8_t readUnitName(uint8_t* name);
void writeUnitName(uint8_t* name);
I’ll be adding a utility, as an example sketch in Arduboy2, for setting the IDs.
Wow! Really?
Awesome!
I think I might make a sketch that allows you to change your nickname as well.
Though, one thing I would like to know is what would happen if you set the nickname to something longer than 3 characters? Will the sketch not compile? or, will the first the letters in that nickname be the only ones that appear?
writeUnitName() will save up to 6 characters from the start of the array that you pass to it as a pointer. The array is treated as a null (0x00) terminated string. Only the number of characters found before the first null will be saved if less than 6 characters. If the string is longer than 6 characters, only the first 6 characters will be saved.
readUnitName() will fill the provided array with a null terminated string containing up to 6 characters. In addition, the return value will be the length of the string. The array that you provide as a pointer must be at least 7 bytes long to allow up to 6 characters plus the null terminator. What a sketch does with the returned string is up to it.
The Arduboy2 library’s Arduboy2 class begin() function will display the unit name at the bottom of the screen, for a short time, under the ARDUBOY logo, after the logo finishes scrolling down. The Arduboy2Base class begin() function won’t display the name because there is no text capability in this class.
If you write your own sketch that allows you to set the unit name:
So, How’s the progress with the Nicknames?
@User5115
I’m just finishing up the example sketch that allows you to set the name and ID. I plan to release in a couple of days or so, after testing and documentation is complete.
The unit name and unit ID functions, as discussed above, are now available in Arduboy2 library version 3.1.0
A minor change from my proposal above for the unit name functions:
The name is a char array instead of uint8_t
Using char is more suitable for the purpose and prevents some compiler warnings and other issues.
http://community.arduboy.com/t/arduboy2-an-alternative-to-the-arduboy-library/1887/51