grafx - Extensible Java Graphics Package Code

Adding qBestStrategy etc. E.g., QBEST_STRAT_WEIGHTED_3_BEST_FUTURE_SCORES.

Renaming speedyFindRotatedBlock() to findRotatedBlock() and removing the old
findRotatedBlock().

This will be an attempt at using BlockGenerator.speedyFindRotatedBlock(). I
wonder how it will perform.

Making some incremental optimizations to net.blockout.meta.BlockGenerator.
Adding inner class BlockInfo which is essentially a net.blockout.Block except
that it's not subjected to as much heap allocation or error checking. Adding
function getBlockOrientationLookup() which returns a HashMap of String rotation
to BlockInfo object, which will be used in tandem with the other new function,
speedyFindRotatedBlock(), which is an attempt to improve upon the existing
function findRotatedBlock() as far as performance goes. Adding an internal
static HashMap named 's_rotationsCanonicalPlus' which maps the existing
canonical rotations, plus "x", "-x", "y", "-y", "z", or "-z" tacked onto each
(considers all permutations), mapping that to the actual canonical rotation.
This is used by simplifyCompositeRotation() which greatly speeds up its
performance in the most common use cases. A second two-arg
simplifyCompositeRotation() is needed, which allows this cache to be bypassed,
so that intialization calls can still be made with the use of that function,
before the extra cache is created.

Committing changes which now use BlockGenerator.findRotatedBlock() to consider
the post drop rotation slide moves, instead of using e.g. rotateY() etc. in the
same class, BlockGenerator. I am still trying to fine tune this code to
improve its performance even further.

Adding function findRotatedBlock() to net.blockout.meta.BlockGenerator. This
is already showing improvements in computer player performance (to be committed
soon), but strangely only after the first few moves. I am going to try to
study the bottlenecks in this function and improve it further. I believe that
the computation of the canonical rotation can be improved upon in this special
case.

Removing 'error.blo'.

Removing 'TODO' from comment, but leaving comment.

Reverting back to the plain vanilla way of ordering ⟨xOff,yOff⟩ pairs. The new
way, which started in the center, sort of, and expanded outwards, sort of,
was causing really strange issues. It probably had bugs. It was also overly
complicated. Maybe at some future point I will revisit this interesting
problem.

With the new xOff,yOff order the game stalled for some reason. Saving. There
was no output which would indicate the nature of the problem.