Refactor the automatic scrambling. From now on, it is not needed to care about single and double turns when randomizing a new turn.
Minor
Change the automatic scramble API in the TwistyObject - in preparation for automatic scrambles in the Bandaged Objects.
Properly initialize DynamicQuat.
New 'tutorial' activity.
More debugging for the case of suspicious submits.
Rename some classes.
Adjust randomizing new rotations so that:
1) it works for basicAngle=5 (Megaminx) (so now basicAngle=2,3,4,5 supported)2) it leaves the decision as to what can be the next rotation to the Object class, as in case of certain Objects (the Dino, or the Helicopter, the Megaminx) the next rotation doesn't have to 'intersect' the old rotation always when oldRotAxis != newRotAxis (that's so simple only in case of the Cube and - only partly - the Pyraminx!)
Speed up WinEffectGlow - MEDIUM quality is fully enough.
Object node: size of screenWidth.
Progress with dragging.
Convert the PostRender to a PreRender, called before we render.This makes more sense as this way things are prepared for the very first render.
More progreess porting RubikCube.
Smaller halo.
Change the Postprocessing effects: separate the radius and the halo.Reason: we needed a way to specify the size of the halo around a postprocessed object; before it was automatically (and not very correctly) computed from the radius - before we knew the size of the object's bounding box, so this automatic computation was possible. Now we're removing the MashBase.getBounding(0 API, so the size of the halo has to be explicitly given by the user. This way is more correct anyway and gives the user more control (as the Multiblur app proves!)...
Adjust the app to match the changes in library.
Looks like we'll have to add 1 dim to the GLOW effect.
Make chances to randimoze a given row when scrambling dependant on the type of Object.
The point: in case of the Cube, all rows should have equal chances. In case of the Pyraminx, the smaller the row, the smaller the chance should be. In particular the trivial 4 corners of the tetraherdon should have a very small chance to be selected.
More support for the 3x3x3 Solver: more of the actual 3x3x3 solver mechanism.