Quelques détails sur CellAu

1. Mode d'emploi

Le fonctionnement du logiciel n'est pas forcément intuitif.

Il y a deux fenêtres : le champ initial et le champ évolulé. On peut zoomer (par puissances de deux) et utiliser des barres de défilement sur les deux champs. Un point blanche représente une cellule vide, une noire contient un animalcule.

La fenêtre champ initial est éditable. On peut dessiner des cellules une par une. Dans le menu Champ > La souris dessine, on peut sélectionner un motif différent à dessiner (par exemple des gliders). On peut importer des champs au format Life 1.05 (.lif) en faisant Fichier > Ouvrir.

La fenêtre champ évolulé représente l'état courant du champ. On peut faire évoluer la date représentée en la précisant explicitement, en avançant d'un pas ou en lançant une animation.

Le point moyennement intuitif est que pour que le champ soit effectivement recalculé, il faut cliquer sur recalc dans la fenêtre champ initial. Si le programme plante à ce moment là, c'est que vous n'avez qu'un misérable G3 sans AltiVec. Rassurez-vous cependant, tout n'est pas perdu (voir section suivante).

On peut faire le recaclul automatiquement dès que le champ initial change ou dès que le champ évolue en cochant la case auto.

La fenêtre de préférences (accessible par pomme-,) permet de préciser la taille du champ (512×512 par défaut) et de dire comment traiter les bords : passe-t-on d'un bord à l'opposé (topologie torique) ou restent-ils toujours vides (topologie rectangulaire) ou un mix des deux (topologie cylindrique). On peut aussi préciser la vitesse de l'animation (attention: pour les vitesses supérieures à 10 générations/seconde, toutes les générations ne sont pas affichées). Attention, les modifications sont prises en compte même sans cliquer sur OK !

2. Le code

Le code est en Objective-C pour la partie graphique. Il y a trois classes :

BMView est un widget qui affiche un champ à un certain niveau de zoom ;
EditableBMView est un descendant du précédent qui permet à l'utilisateur de modifier le champ ;
Manager est une classe non graphique qui décide quand il faut calculer et afficher quoi. Il est prévu pour gérer un EditableBMView et plusieurs BMViews à des générations différentes (ce qui explique que le bouton de mise à jour soit dans la fenêtre champ initial et non dans le champ évolué, ce qui aurait été plus logique).

La partie qui fait le calcul proprement dit est en C, dans les fichiers cellular.[ch]. Il y a deux fonctions exportées:

load_cellauto charge un fichier au format Life 1.05
cellauto_evolve fait évoluer un champ d'une génération

Les champs sont décrits comme un tableau d'octets (8 cellules par octet), de taille xd×yd. Chaque ligne fait bpl octets (en général, si xd est multiple de 8, bpl=xd/8).

La fonction cellauto_evolve s'occupe des problèmes aux bords, et soustraite le calcul de chaque ligne à oneline_128. Cette fonction existe en de multiples versions :

oneline_8 : version qui travaille octet par octet
oneline_32 : version qui travaille mot par mot (si vous n'avez pas de Altivec, vous pouvez remplacer les appels de oneline_128 par oneline_32)
oneline_128 : version qui utilise l'unité vectorielle pour calculer 128 bits à la fois.

Chacune des versions utilise une macro (OL_INNER_?) qui traite un bloc (de 8, 32 ou 128 bits). La macro est utilisée différemment pour les extrémités de la ligne et le reste des blocs. La macro OL_INNER_128 existe en deux versions : une avec des tables précalculées, une avec la méthode décrite dans l'article (plus rapide). Il y avait des versions « table » des autres macros, mais elles ont disparu.

Le projet est au format Project Builder, parce que tout le monde n'est pas forcément passé à Xcode (moi, par exemple).

3. Perspectives

Le logiciel n'est pas terminé. Il faut qu'il puisse afficher plusieurs générations évoluées. Il faut aussi qu'il détecte automatiquement s'il peut utiliser des instructions vectorielles. Il faut qu'il puisse exporter les champs, mieux les calculer, etc. Qui sait quand (si) tout cela sera réalisé ?