It’s from LoaD Register Byte, lifted directly from ARM assembly, though I guess the R could stand for raw in this context. It’s supposed to be an ugly wart in the code, precisely so nobody else would try to use it directly. Want to crash a Pokitto? It’s as easy as LDR(1).
Tsk, tsk, that’s not very DRY. 
That’s an odd choice on ARM’s part.
In fairness, anyone who isn’t afraid of the word pointer is probably capable enough to not misuse it.
That is, assuming they’re not afraid of pointers because they know how to use them.
If they aren’t afraid of pointers and they don’t know how to use them then it’s time to dig out the book of horror stories. :P
Come to think of it, what about ((StringPair)null).key = "";?
If exceptions aren’t implemented yet then anything that would normally be an exception would crash, right?
Or at the very least this probably translates to nullptr in C++.
Consider it an oasis in the desert. :P
Is it? It does what it says on the tin: loads something into a register.
They have to specify because there is also an LDM instruction, which loads multiple registers.
Initially, all references were wrapped in a __ref__ and that would check if its valid or not. Exceptions are implemented, but since they’re disabled in C++ I’ve been replacing them with a print call or simply letting it crash.
It is when the usual convention is that merely LD or LDB would suffice.
(MIPS uses LDB.)
Kind of makes a bit more sense, but even so.
Crashing is what I’ve come to expect from embedded systems.
It’s kind of a shame exceptions are disabled for C++.
A context sensitive help ! 
That is my favourite screen mode (110"88, 16 colors), but I am not going to change it any more 
Mine too!! What a coincidence!
Is there any way to format a float value to string for printing on the screen? Looks like String.Format() is not supported.
I didn’t implement String.format because it’s much more expensive than it may appear.
The signature is this:
public static String format(String format, Object... args);
Ignoring the fact that I haven’t implemented support for Object... args, let’s have a look at:
String.format("%d", 5)
This would result in something like this (pseudo-code):
String::format(new String("%d"), new Object[]{ new Integer(5) });
Then there’s the new String instance created inside format itself.
It would be nice to have some way to print formatted strings without calling new 5 times. If the user were to do this manually, it would probably fine, but I’m avoiding having the compiler/lib do these things in places you wouldn’t expect.
Edit: I have an idea for removing that new String, just haven’t gotten around to it yet.
This is why C# has a String.Format(String, Object) overload.
There’s still boxing involved, but no wasteful array allocation.
In fairness it probably uses a StringBuilder at least, so that means it’s just the one string created and not the potential long list of strings using string concatenation would.
You could make a format(String, int) overload to avoid the new Object[] and new Integer.
The outer new String could be avoided by coming up with a special type that binds to string literals and has ‘value semantics’ (i.e. behaves like a built-in as opposed to a GC’ed type).
A pointer could work, but that’s not a very typesafe option.
The inner new String could possibly be avoided by forgoing format and having some print(String format, int value) overload.
By the way, if the compiler has C++17 support then to_chars might be a more efficient under-the-hood way of implementing certain formatting operations.
There’s also to_string from C++11 onwards, but obviously that’s going to result in an allocation for larger values.
If std::string uses the small string optimisation then the chance of allocation is probably going to be much less likely as I suspect most games are probably only going to be printing small numbers (5 digits or less).
StringBuilder is indeed used by java when concatenating strings e.g. "" + varName + " = " + 12 that are done in one statement. It wasn’t usually the case when it’s split with a variable holding an intermediate string (inside a loop for example), but that might have changed with more recent java compilers.
Are you currently using new when doing so? Because I didn’t found any StringBuilder to retain, so when I’m showing “Distance: 1204m” in my game, I’m doing a "Distance: " + mDistance + "m". Won’t be an issue for now, but it might leads to grave memory fragmentation sooner or later haha
If there were a way to advance the text position after printing something, that’d ease that a lot, but to be honest I didn’t see anything about that in the doc so I assumed it isn’t advancing right now and I ended up joyfully concatenating strings.
You probably won’t have a memory fragmentation because you’re allocating/deallocating objects of the same size again and again.
Also, it does advance the text position, so you should be able to do this:
screen.print("Distance: ");
screen.print(mDistance);
screen.print("m");
Well that’s the only think that gets allocated in the “game loop”, so it should be ok then
That’s good to know about print! 
If you want to drop that down to zero:
private static final String lblDistance = "Distance: ";
(I’d really like to make this unnecessary in the future)
Yeah and anyway that’s often a good thing to keep those constants out of the action haha
I was not aware that they’d made that optimisation. That’s pretty useful.
I suspect C# does something similar,
but I’m not sure what I’d have to search to find out whether it does or not.
(Eric Lippert’s probably mentioned it somewhere on his blog.)
This is one of the places where C++ excels.
A lot of people give C++ flak for using the << operator to do stream output, but…
I once wrote something like this for Arduboy:
template<typename T>
Print & operator <<(Print & printer, const T & object)
{
printer.print(object);
return printer;
}
Which means that something like arduboy << F("Distance: ") << mDistance << 'm'; ends up being (roughly) equivalent to
arduboy.print(F("Distance:" ));
arduboy.print(mDistance);
arduboy.print('m');
when compiled.
(We could easily add something like this to the PokittoLib if there was interest in doing so.)
Sadly Java can’t do this because there’s no operator overloading.
The closest it can get is method chaining.
screen.print("Distance: ").print(mDistance).print("m");
Personally I’ve never been a fan of method chaining where the method returns this, to me it’s always felt like it’s compensating for a lack of better features.
What about making local variables final?
Does that also have the same optimisation?
Nope. It would have to be a static final, but Java doesn’t support that either. 
Is there a specific reason why it wouldn’t be possible to allow final locals to be baked into ROM/optimised like static final if they were initialised with a literal?
People always accuse C++ of having too many rules and features,
but at least 9 times out of 10 I can say “there’s a feature for that” instead of “no, that’s not supported”. :P