I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78...

That is probably (x + 1) % 10 assuming x is non-negative. That kind of code is responsible for quite a bit of the verbosity, the author was obviously not aware of many of the little tricks usually used in this kind of code.

Original author here.

It's actually a method to convert from the index of an inventory hotkey slot into the keystroke used to access it -- there were ten hotkey slots, which were numbered 1–9 and 0 at the end.

But I like all the other interesting interpretations here :P (They all assume way more knowledge than I had at the time.)

Also assuming that x <= 9.

Well, it's faster than %, but I bet it's premature.

Why do you say it's faster? It's guaranteed to fail branch prediction one out of ten times. My guess is that'd be a lot slower than using the integer modulo operator, which is not an expensive operation.

On their own, % and / are way slower than +, -, *, <<, >>. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be avoided is a kind of folklore based in truth - kind of like function calls being slow - but like everything time-sensitive the mistake lies in not profiling before (manual) optimization.

There's an example on SO, I got similar results just now when I replicated it:

https://stackoverflow.com/questions/15596318/is-it-better-to...

It doesn't matter on my machine whether the divisor is 10 or 42 (as in the example), the branching is way faster. Now, maybe if the branching were not in a loop and hence not so easily predicted, it wouldn't make a difference. But if this code is not being used in a loop, optimization may be premature anyway (as indicated in my original comment).

Probably f() has something to do inside the main game loop and gets called on a bunch of objects every frame. I haven't looked at the code enough to know if that's a bottleneck.

> On their own, % and / are way slower than +, -, *, <<, >>.

And the branch instruction is free??

More or less, assuming you can predict it. But there's a penalty for misprediction. So it boils down to whether using % frequently (either as a native instruction or as a sequence of instructions) is more or less expensive than predicting a branch frequently, given a certain misprediction rate.

> More or less, assuming you can predict it. But there's a penalty for misprediction.

Yeah, no, that's not free.

Ok, so what changes would you make to my explanations?

At least in C++, GCC and Clang will both use a CMOVE: https://godbolt.org/g/W1GWyP

My favorite part is the overloaded print methods: https://github.com/raxod502/TerrariaClone/blob/master/src/Te...

Maybe those are stubs the author intended to do something else with later?

Original author here.

I can confirm that the actual reason is that at the time I thought typing "print" instead of "System.out.println" was a great idea.

In that case, I think you might have been happier in a language other than Java. :-)

That's actually not such a bad idea, since you seem to have discovered one of the traits of good abstraction: it makes code more concise.

It always was rather onnerous.

It IS a great idea!

I'm sure there was a good reason for that.

I'm not so sure. In the readme he says there are over 500 cases of "unnecessary boxing."

Raise your hand if you were excited when you heard Java 1.5 would introduce autoboxing.

A textbook example of a quasi-class: http://www.idinews.com/quasiClass.pdf