7 ms·

I love DoubleContainer: https://github.com/raxod502/TerrariaClone/blob/master/src/DoubleContainer.java https://github.com/raxod502/TerrariaClone/blob/master/sr

I love DoubleContainer: https://github.com/raxod502/TerrariaClone/blob/master/src/DoubleContainer.java https://github.com/raxod502/TerrariaClone/blob/master/src/Do... which is fortunately only used in a comment here: https://github.com/raxod502/TerrariaClone/blob/9ea04b15add48141dbcb905af8fc906d423d854d/src/World.java#L725 https://github.com/raxod502/TerrariaClone/blob/9ea04b15add48...

alexwebb2 9y ago
I'm sure there was a good reason for that.
- Nition 9y ago
  I'm not so sure. In the readme he says there are over 500 cases of "unnecessary boxing."
  - Agathos 9y ago
    Raise your hand if you were excited when you heard Java 1.5 would introduce autoboxing.
bcbrown 9y ago
I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78e6bcc6fc3aa0c1e204d5b84475e/src/Inventory.java#L1666 https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78...
- danbruc 9y ago
  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.
  - baddox 9y ago
    Also assuming that x <= 9.
  - raxod502 9y ago
    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.)
- hacking_again 9y ago
  Well, it's faster than %, but I bet it's premature.
  - CydeWeys 9y ago
    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.
    - hacking_again 9y ago
      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-avoid-using-the-mod-operator-when-possible 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.
      - 35bge57dtjku 9y ago
        > On their own, % and / are way slower than +, -, *, <<, >>. And the branch instruction is free??
        hacking_again 9y ago
        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.
sparky_ 9y ago
My favorite part is the overloaded print methods: https://github.com/raxod502/TerrariaClone/blob/master/src/TextField.java#L59 https://github.com/raxod502/TerrariaClone/blob/master/src/Te...
- js2 9y ago
  Maybe those are stubs the author intended to do something else with later?
  - raxod502 9y ago
    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.
    - bitexploder 9y ago
      It always was rather onnerous.
    - js2 9y ago
      In that case, I think you might have been happier in a language other than Java. :-)
    - userbinator 9y ago
      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.
    - taw55 9y ago
      It IS a great idea!
SuddsMcDuff 9y ago
A textbook example of a quasi-class: http://www.idinews.com/quasiClass.pdf http://www.idinews.com/quasiClass.pdf

alexwebb2 9y ago

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

Nition 9y ago
I'm not so sure. In the readme he says there are over 500 cases of "unnecessary boxing."
- Agathos 9y ago
  Raise your hand if you were excited when you heard Java 1.5 would introduce autoboxing.

bcbrown 9y ago

I really like this method: https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78e6bcc6fc3aa0c1e204d5b84475e/src/Inventory.java#L1666 https://github.com/raxod502/TerrariaClone/blob/fd1ff8b8b0e78...

danbruc 9y ago
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.
- baddox 9y ago
  Also assuming that x <= 9.
- raxod502 9y ago
  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.)
hacking_again 9y ago
Well, it's faster than %, but I bet it's premature.
- CydeWeys 9y ago
  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.
  - hacking_again 9y ago
    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-avoid-using-the-mod-operator-when-possible 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.
    - 35bge57dtjku 9y ago
      > On their own, % and / are way slower than +, -, *, <<, >>. And the branch instruction is free??
      - hacking_again 9y ago
        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.

sparky_ 9y ago

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

js2 9y ago
Maybe those are stubs the author intended to do something else with later?
- raxod502 9y ago
  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.
  - bitexploder 9y ago
    It always was rather onnerous.
  - js2 9y ago
    In that case, I think you might have been happier in a language other than Java. :-)
  - userbinator 9y ago
    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.
  - taw55 9y ago
    It IS a great idea!

SuddsMcDuff 9y ago

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