[snailcuber]

Genau die Überlegung hatte ich bisher auch angestellt: Entweder stupide die Farben pro Seite speichern wie Du schon berechnet hast und "einfache" Funktionen für die Moves schreiben.

Oder aber individuelle Variablen für je 8 Ecken mit je 3 Orientierungen und 12 Kanten mit je 2 Orientierungen (8x2bit + 12x 1bit) in einem 3D-Koordinatensystem (3x3x3 array) als Pointer abzulegen, bzw. besser die Position im 3x3x3system stattdessen direkt mit zu speichern. Da Ecken nur an 8 Positionen und Kanten an 12 Positionen sein können, wären auch nur je 3bit zusätzlich für Ecken und 4 bits zusätzlich für Kanten als Positionsmarker in der jeweiligen Variable erforderlich. In Summe also immer 5bit pro Ecke/Kante = 20 * 5bit = 100bit = 12,5byte

Die Move-Funktionen würden dann natürlich wesentlich komplexer ausfallen.


Das ganze plane ich zudem auf einen Microcontroller umzusetzen.

Auf jeden Fall sehr spannend. Ich hatte das vor 5 Jahren mal gemacht, aber noch simpler und nicht auf einem Microcontroller. Gerade mal nachgeschaut. Ich hatte sehr verschwenderisch alles in ein char array bzw. string gepackt (inkl. Mittelstein). Das initial setup war weiss oben blau (statt grün) vorne.

"WWWWWWWWWBBBBBBBBBRRRRRRRRRGGGGGGGGGOOOOOOOOOYYYYYYYYY";

Aber die moves waren sehr einfach, du musst ja nur einmal statisch hinterlegen wie sich der string bei einem z.B. "R" move transformiert.

Nach einem R sah das dann so aus:

"WWBWWBWWBBBYBBYBBYRRRRRRRRRWGGWGGWGGOOOOOOOOOYYGYYGYYG"

Code:

     WWB              prevmove : R (y30)
     WWB                       depth : 1
     WWB                     nodes : 120

RRR BBY OOO WGG
RRR BBY OOO WGG
RRR BBY OOO WGG

     YYG
     YYG
     YYG

Mir ging es damals darum Fragen zu lösen wie z.B. wie viele moves benötigt man um mit R,Z,R,Z,.... wieder in die Ausgangsform zurück zu gelangen.