Paso 7: Nosotros podemos hacer mejor
Ahora vamos a hacer todo esto y ver si podemos hacerlo un poco más emocionante.
Primero, una advertencia importante: Neurogami la estética no puede ser tuyo. Es una especie de minimalismo glitchy. Les espero guste, pero no es el objetivo.
El enfoque adoptado fue primero crear una serie de GIFs animados constituidas ImageMagick y algunos software personalizado de rubí a las imágenes de interferencia. El código de procesamiento luego lugares, escalas, etc., tal o cual archivo GIF basado en qué nota MIDI y canal viene en.
Es probablemente más común ver bocetos de proceso donde todos los efectos visuales son realizadas por procesamiento (o algunos adicionales biblioteca de procesamiento) en el bosquejo. Enfoque aquí es, en forma, hacer trampa: solo muestra fotos de efectos gráficos. : Es el resultado final lo que importa.
Sin embargo, utilizando animaciones prefabricadas facilitar las cosas. Conseguir los mismos efectos visuales en tiempo real en el proceso sería casi imposible. Pareja que con responder también a MIDI en tiempo real los mensajes hace más probable para las cosas a ir mal.
Hay algo sobre este sketch que es común a la mayoría de procesamiento de bocetos. Si observas la mayoría cualquier ejemplo que hace algo visualmente llamativo el bosquejo generalmente funciona así: en cada pasada de sorteo, ejecuta código para actualizar un conjunto de variables, a continuación, utilice el estado actual de las variables para determinar qué hacer.
Este esquema es el mismo. Utiliza una biblioteca muy resbaloso llamada gifAnimation para reproducir GIFs animados. Se pueden utilizar como lo haría con cualquier archivo de imagen ordinario, que es, pasa una referencia a un GIF animado a imagen para controlar la ubicación y escala.
La cosa es, si usted busca para representar numerosas imágenes en diversos lugares, algunos que persisten algunos no necesita algún modo seguimiento de les. Si supieras el número exacto de las imágenes podría ser capaz de usar un conjunto de variables para mantener todos los detalles, pero más allá de algunos pocos que es engorroso.
Tenía en mente hacer los GIFs en cuadrículas de diferentes tamaños. He decidido dividir la pantalla en la mitad, por la mitad. Colocación de la imagen se realizaría mediante la especificación de izquierda o derecha, qué red de tamaño (al dar el número de filas y columnas) y donde en esa cuadrícula para colocar la imagen.
Seguimiento de un conjunto de datos relacionados con las llamadas de alguna manera agruparlos. A veces funciona una matriz, pero en este caso hay que hacer dos series de datos agrupados. Hacer sus clases en el proceso es fácil y ofrece una manera de guardar datos relacionados juntos. Define una clase denominada RenderArgs (van a ver por qué en un momento)
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; } } Es sólo una manera de agrupar un color de tinte, una referencia a un GIF animado, el número de columnas y filas de una cuadrícula y donde en esa rejilla para colocar el GIF.
(Excepto el tinte) son todos los argumentos a un método 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++; } } } (El archivo con este código también define derecho como 1 para hacerlo más legible.)
Plausible, este método podría ser parte de la misma clase que contiene todos los valores de argumento; el código desarrollado desde la primera creación de un método para definir cómo colocar una imagen en una ranura de la rejilla.
placeGifAt se llama en sorteo, junto con una llamada al tinte. Todo esto podría estar envuelto en un método de instancia (hacer, tal vez) en renderArgs (que luego tendría un mejor nombre) para que los datos y el comportamiento se mantienen Unidos (especie de punto entero de clases). Simplemente no he hecho esto. Todavía estoy probando cosas hacia fuera y estoy OK si el código no ha colocado en alguna forma final.
Existen variados métodos que gestión una lista de instancias GIF animadas y una lista de colores y algunos casos de ArrayList (renderL y renderR) a instancias de RenderArgs.
sorteo hace muy poco. Se establece fondo negro luego itera sobre las listas de RenderArgs y para cada elemento las llamadas tinte entonces la imagen. En otras palabras, se analiza un conjunto de variables y los utiliza para decidir qué hacer.
Aquí está el sorteo
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 ); } }
