Mango:
The algorithm I use is a human method going layer by layer, which goes like this: top edges, top corners, middle (edges), bottom edges orient, bottom edges position, bottom corners position, bottom corners orient, and optionally, center correction.
My algorithm is as far as I know the only algorithm which fixes center rotations for picture cubes.
Because my algorithm is a human method, solutions are generally long (about 100 moves). I have looked at implementing Thistlewatte's method and Kociemba's method (which are group-theory based methods which require large table generations, producing solutions in 25 moves or less) but have decided not to implement it for a number of reasons.
The main reason is because the solver is now generalized to solve NxNxN cubes, of ANY size from 2x2x2 to however much your memory will allow. For cubes of size 4x4x4 or greater, using a group-theory based solution is simply utterly unfeesible.
However, unlike Mitth'raw'nuruodod, I do not just tout a method without producing any code and claim that my code works correctly without any evidence whatsoever to support that claim.
So, if you'd like to have a look at my code, you can download the source to my solver here:
command-line version (easiest to read)
cgi version (the version which runs on the webserver and had the fancy interface)
The cgi version also has some advanced capabilities such as graphical output, and the ability to not only solve a cube, but also to solve a cube to another position (e.g., to solve for special patterns).
And once again,
here's a link of the solver in action.
But, yes,
Mainly I'm interested to see people work on the challenge I've posted.
To that end, if you download the command-line version from the above link, you can get lots of hints... as all the fundamental functions and structures needed are there.
I'm especially keen to see what data structures other people use to represent the cube. For me, figuring this out was one of the biggest challenges in the beginning.
Peace
- Eric