Etape 7: Nous pouvons faire mieux
Nous allons maintenant jeter tout cela et voir si nous pouvons le faire un peu plus excitant.
Tout d’abord, une mise en garde importante : Neurogami l’esthétique ne peut pas être vôtre. C’est une sorte de minimalisme glitch. J’espère vous plaira, mais ce n’est pas vraiment le but ici.
L’approche adoptée était d’abord créer un certain nombre de GIFs animés en utilisant ImageMagick et certains logiciels personnalisés Ruby aux images de glitch. Le code de traitement, puis place, balances, etc., tel ou tel fichier GIF basé sur quelle note MIDI et le canal est disponible en.
C’est probablement plus fréquent de voir des croquis de processus où tous les effets visuels sont effectuées par la transformation (ou bibliothèque de traitement supplémentaire) droit dans le sketch. On approche ici est, de façon, tricherie : c’est juste montrer des photos d’effets graphiques. Alors quoi : c’est le résultat qui compte.
Toutefois, à l’aide d’animations pré-faites faciliter les choses. Obtenir les mêmes effets visuels en temps réel dans le traitement serait quasiment impossible. Couple que de répondre également à MIDI des messages en temps réel rend plus probable que les choses tournent mal.
Il y a quelque chose sur ce croquis qui est commun à la plupart traitement croquis. Si vous regardez la plupart des exemples qui rend quelque chose visuellement frappant l’esquisse généralement fonctionne comme ceci: À chaque passage du tirage au sort, exécuter du code pour mettre à jour un ensemble de variables, puis utilisez l’état actuel de ces variables pour déterminer ce qu’il faut restituer.
Cette esquisse est le même. Il utilise une bibliothèque très glissante appelée gifAnimation pour jouer des GIFs animés. Vous pouvez les utiliser comme vous le feriez pour n’importe quel fichier image régulière, qui est, passer une référence à un GIF animé sur image pour contrôler la mise en place et mise à l’échelle.
La chose est, si vous cherchez à rendre de nombreuses images en différents endroits, certains persistent quelques ne pas, vous devez un moyen de garder une trace d’eux. Si vous saviez le nombre exact d’images, vous pourriez être en mesure d’utiliser un ensemble fixe de variables à contenir tous les détails, mais après un petit nombre qui devient encombrant.
J’ai eu à l’esprit de rendre les GIFs placés dans les grilles de tailles différentes. J’ai décidé de diviser l’écran en deux, au milieu. Placement de l’image se ferait en spécifiant à gauche ou à droite, quelle grille de taille (en donnant le nombre de lignes et de colonnes) et où dans cette grille pour placer l’image.
Suivi d’un ensemble d’appels de données connexes d’une certaine manière de les regrouper. Parfois un tableau fonctionne, mais dans ce cas il faut faire deux séries de données groupées. Il vos classes dans le traitement est simple et offre un moyen de conserver des données liées ensemble. J’ai défini une classe appelée RenderArgs (vous verrez pourquoi dans un instant)
class RenderArgs { public color tint; public Gif gif; public int numCols = 0; public int numRows = 0; public int slotIndex; RenderArgs(color t, Gif g, int nC, int nR, int idx ) { tint = t; gif = g; numCols = nC; numRows = nR; slotIndex = idx; } } C’est juste une façon de regrouper une couleur de teinte, une référence à un GIF animé, le nombre de colonnes et de lignes dans une grille et où dans cette grille pour placer le GIF.
(À l’exception de la teinte) Voici tous les arguments pour une méthode placeGifAt.
void placeGifAt(Gif g, int leftOrRight, int numCols, int numRows, int slotIndex ) { int w = width/(numCols*2); int h = height/numRows; int count = 0; int colOffset = 0; if (leftOrRight == RIGHT ) { colOffset = width/2; } for(int y=0; y<numRows; y++) { for(int x=0; x<numCols; x++) { if (count == slotIndex) { image(g, x*w+colOffset , y*h, w, h); } count++; } } } (Le fichier avec ce code définit également droit comme 1 pour rendre cela plus lisible).
Plausible, cette méthode pourrait faire partie de la même catégorie que détient la totalité des valeurs d’argument ; le code a évolué de commencer par créer une méthode pour définir comment placer une image dans une grille de connecteur.
placeGifAt est appelé au tirage au sort, avec un appel à la teinte. Tout cela pourrait être enveloppé dans une méthode d’instance (rendre, peut-être) en renderArgs (qui aurait alors besoin d’un meilleur nom) afin que les données et le comportement restent ensemble (sorte de la point de l’ensemble des classes). Je n’ai pas de faire cela. J’essaie toujours de choses et je suis OK si le code n’a pas arrangé dans une forme définitive.
Il existe des méthodes d’assistance assortis qui gèrent une liste d’instances GIF animés et une liste des teintes et certains cas de ArrayList (renderL et renderR) s’accrocher à des instances de RenderArgs.
tirage au sort fait très peu. Il définit un fond noir, puis effectue une itération sur les listes de RenderArgs et pour chaque élément appels teinte puis l’image. En d’autres termes, il ressemble à un ensemble de variables et les utilise pour décider ce qu’il faut restituer.
Voici le tirage au sort
void draw() { background(0); RenderArgs ra; for( int i =0; i < renderL.size(); i++ ) { ra = renderL.get(i); tint(ra.tint); placeGifAt( ra.gif, LEFT, ra.numCols, ra.numRows, ra.slotIndex ); } for( int i =0; i < renderR.size(); i++ ) { ra = renderR.get(i); tint(ra.tint); placeGifAt(ra.gif, RIGHT, ra.numCols, ra.numRows, ra.slotIndex ); } }
