Animación flash en Unity3D desde cero. Primera parte, lírica

En esta serie de artículos, hablaré sobre cómo y por qué decidimos crear nuestra propia solución para importar animación Flash a Unity, y sobre las técnicas de optimización y el funcionamiento interno del complemento. También tengo muchas otras cosas fascinantes que contar: aspectos internos del formato SWF, características especiales de la extensión del editor de Unity y asuntos generales de animación. ¡Encontrarás todo eso dentro!




Introduccion


Cuando comienza a trabajar en cualquier proyecto, siempre tiene que enfrentar el problema de elegir las tecnologías para la mayoría de sus componentes. Uno de estos componentes es, por supuesto, el sistema de animación. Ahora, hay algunas variables de las que dependerá su elección. La primera pregunta que debe hacerse es a qué herramientas están acostumbrados sus animadores (con los que pueden trabajar) y cuáles son más fáciles de encontrar. Claro, elegir un producto extremadamente específico no tiene mucho sentido. En este caso, si sus empleados se van por algún motivo (o son atropellados por un autobús), será casi imposible reemplazarlos. Entonces, básicamente, su proyecto, total o parcialmente, se detendrá por un período indefinido, que puede ser muy costoso, especialmente para un producto comercial. La segunda variable es más técnica, y consiste en integrar las herramientas en su motor. ¿Hay alguna solución de terceros y cuál es su calidad? ¿Tiene la oportunidad y la capacidad de crear su propia solución? Por supuesto, la eficiencia y la conveniencia de todo lo anterior también es crucial. Y la tercera variable son las capacidades de las herramientas. Por lo tanto, si realmente necesita una cinemática inversa , sería muy extraño que prefiera la animación no esquelética.


Tipos de animación 2D


Ahora, veamos las técnicas de animación más populares en los juegos. Consideraré solo la animación 2D, ya que la animación 3D es un tema para una conversación completamente diferente, con sus propios enfoques y herramientas. No dude en saltarse esta sección si está bien versado en este asunto (créame, no habrá revelaciones ni revelaciones). De la misma manera, si solo está aquí para ver las características de la animación Flash, las encontrará en el siguiente artículo.


Animación cuadro por cuadro


Iniciando nuestra mini revisión, el tipo de animación más simple y antiguo: la animación cuadro por cuadro. En esta animación, cada cuadro está representado por una imagen individual, y al cambiar esas imágenes muy rápido, obtenemos la ilusión de movimiento.


Pros:


Implementación elemental, generalmente disponible para cualquier motor. Cualquier complejidad y estilo de animación, incluso puede insertar los fotogramas completos de la película (en teoría, por supuesto). Cualquier herramienta: casi cualquier cosa puede proporcionarle una secuencia de marcos que puede, si es necesario, juntar en un atlas de texturas.


Contras:


La principal desventaja es, por supuesto, la cantidad de memoria que requiere todo esto. Ciertamente, puede usar todo tipo de trucos, como cortar cuadros en bloques y luego reutilizar los bloques repetitivos, cargar en segundo plano los cuadros del disco y eliminar los que ya se muestran, y así sucesivamente. Pero recuerde que todos estos trucos también tienen sus propios inconvenientes. Por ejemplo, cortar bloques solo se puede usar en pixel art , la carga en segundo plano ejerce una tensión adicional en el disco, ocupa mucho espacio en este disco, lo que aumenta el tamaño del juego en sí, así como la cantidad de datos necesarios para que un usuario la inicie o actualice.


Línea inferior:


Funciona solo para pequeños y pocos cuadros de animación, perfecto para pixel art y juegos de estilo retro como NES .


Video animacion


Básicamente, la animación de video es una apoteosis de la locura cuadro por cuadro. Y sí, todavía se aplica y, a veces, incluso correctamente. Hemos implementado algo como esto en los juegos de objetos ocultos para la animación voluminosa y compleja, y también para escenas con un toque de realismo. Agregue a estos códecs como theora o vp8 , y podrá crear una animación de video bastante agradable (incluso con composición alfa ) propia.


Lo bueno de este tipo de animación es, por supuesto, que puedes crear casi cualquier cosa, desde escenas manejadas por el escenario con actores reales hasta batallas renderizadas en 3D. Lo malo es una gran carga en la CPU cuando está decodificando y, por supuesto, la calidad de la imagen. El compromiso entre calidad y eficiencia solo se puede lograr en un número limitado de casos específicos, como en los juegos de objetos ocultos mencionados anteriormente.

Entonces, de todos modos, la animación de video no es para todos y no siempre es aplicable, casi nunca, para ser precisos. Básicamente, este tipo de animación funciona muy bien solo para escenas renderizadas. Si logras hacer una buena implementación de dicha animación, seguramente no será pan comido. Hay toneladas de matices y trucos a tener en cuenta, tanto con respecto a la calidad de la imagen de salida como a la carga de la CPU. Debido a esta especificidad, hay muy pocas implementaciones listas para usar, que no son lo suficientemente buenas o cuestan mucho dinero (hola, Bink_Video ), por lo que la mayoría de las personas prefieren escribir las suyas.


Animación esquelética


Entonces, avancemos hacia los tipos más populares y modernos de animación 2D. Las animaciones esqueléticas están ganando más y más corazones y mentes de los desarrolladores 2D, cada vez más cerca de ser el estándar de animación del juego. Lo curioso es que, en realidad, se han vuelto tan populares en 2D hace relativamente poco tiempo, a diferencia del 3D, donde se remontan, cuando nuestros antepasados ​​estaban creando Half-Life . La esencia de la animación esquelética, te sorprendería, es un esqueleto creado por un animador. Básicamente, un esqueleto es un conjunto de huesos conectados entre sí y que forman una estructura de árbol. Los huesos están unidos a pedazos, representados por imágenes individuales. Esta construcción comienza a moverse cuando los huesos se desplazan o giran uno con respecto al otro. Los cambios y rotaciones de los huesos del esqueleto se adhieren a la línea de tiempo de la animación general.


Los pros son obvios: no tenemos que almacenar cada cuadro de animación como una imagen separada, solo las piezas (por ejemplo, piernas y brazos del personaje), que serán movidas por los huesos. Hay algunas implementaciones realmente geniales de este tipo de animación con tiempos de ejecución para diferentes plataformas y motores, que son asequibles o incluso gratuitas: Spine , Spriter , Anima2D , DragonBones y otros. Usando el esqueleto y sus características, puede lograr un increíble nivel de suavidad de su animación al interpolar las posiciones de los huesos. También puede alternar las transiciones entre las escenas e incluso mezclar dos tipos diferentes de escenas: disparar mientras se ejecuta, disparar mientras se arrastra y así sucesivamente. No voy a enumerar todas las posibilidades de la animación esquelética, así que ten en cuenta que realmente hay muchas y son realmente geniales. Y prefiero darle un enlace al sitio web de Spine donde puede verlos todos con fotos y descripciones.


Parece que tenemos a nuestro soldado universal, pero aún no. También tiene sus propios inconvenientes. Y debo decir de inmediato que para muchos proyectos y animaciones, estas desventajas pueden no existir. Entonces, si la animación esquelética funciona para usted, eso es genial, úsela, porque se ve muy bien y moderna.


Ahora, volvamos a los inconvenientes. La animación esquelética requiere un paso adicional: la manipulación. Se trata de crear un esqueleto y unir huesos y piezas. Si su objeto tiene solo una animación, no pocas, como, por ejemplo, el personaje del juego de plataformas , entonces este paso no le sirve de nada. También debe recordar que no todas las escenas se pueden animar fácilmente con huesos. De hecho, hay muchos ejemplos cuando es mejor sin ellos, tanto en términos de creación como de rendimiento del juego final. También señalaría la disponibilidad de expertos en el mercado como un factor importante. Por supuesto, con la creciente popularidad de la animación esquelética, su número también está creciendo, pero aún así, probablemente no será fácil para usted incluirlos en su equipo. La variedad de herramientas también está haciendo su parte. Todos tienen sus propias preferencias, y aún así se necesita ser flexible y estar listo para aprender, lo que crea dificultades adicionales para reclutar y capacitar a sus empleados.


Animación de línea de tiempo


He guardado este tipo de animación para el final no porque sea mejor que todas las demás, sino porque está principalmente representado por animación Flash cuyo interior hablaremos en la parte técnica de este artículo. Ahora, Flash no es el único representante de este tipo de animación, pero ciertamente es el líder, por lo que a partir de este momento, voy a describir todo en relación con él. Las escenas de animación de la línea de tiempo consisten en piezas animadas en diferentes capas en la línea de tiempo. Básicamente, es casi lo mismo que vimos en la animación esquelética, pero sin esqueletos. Usando los fotogramas clave en la línea de tiempo, podemos mover, rotar, reemplazar y agregar nuevas piezas a estos fotogramas y, por supuesto, interpolar transiciones, ampliaciones y rotaciones entre ellos. Significa que en este caso, no movemos los huesos a los que se unen las piezas, sino las piezas en sí. Claro, nos priva de muchas posibilidades de animación esquelética, pero como dije antes, no todos las necesitan. Además, obtenemos otras ventajas, como:


  • capacidad de agregar e insertar nuevas piezas en el medio de una escena;
  • sin aparejos, sin huesos que a veces son innecesarios;
  • Adobe Flash (actualmente Adobe Animate ), la herramienta de animación más antigua y probada a través de los años; una gran cantidad de animadores, de una forma u otra, pueden trabajar con él;
  • capacidad de usar escenas antiguas al transferir sus proyectos Flash a Unity, incluidas las escenas que realizó en gráficos vectoriales , no solo en ráster .

Usted puede preguntar, ¿no está Flash muerto? Como jugador de navegador, sí, pero como herramienta de animación, todavía está en el juego. Y te diré más, no hay alternativas a Flash ahora o previstas. ¿Hay algún inconveniente? Claro Y la principal desventaja es que ... no es una animación esquelética, ja, ja. Por lo tanto, estamos perdiendo la capacidad de mezclar nuestras escenas entre sí, la cinemática inversa y algunas otras características que solo puede usar cuando trabaja con esqueletos. ¡Pero tenemos líneas de tiempo una dentro de la otra, y también máscaras de trama y vectores! ¡Y los animadores adoran las máscaras! Aquí debe tenerse en cuenta que Spine también ha agregado recientemente la opción de recorte , pero hasta ahora son geométricos y muy limitados en comparación con las máscaras Flash.


Tipos de animación: resumen


Por supuesto, he enumerado no todos los tipos de animación, sino solo los principales. Por ejemplo, dejé la llamada animación de procedimiento, cuando los objetos o piezas están controlados solo por código, pero es casi imposible compararlo con los demás, y no quería que el artículo fuera demasiado largo para leerlo. Supongo que ahora es mejor para nosotros echar un vistazo más de cerca a algo más especializado en animación para completar la imagen.

Entonces, para resumir. Como siempre y en otros lugares, no hay un soldado universal aquí. Debe elegir su solución en función de su proyecto, tareas y personas. Después de todo, ¿quién dice que solo debes usar un tipo de animación a la vez? Hay muchos proyectos en los que podemos ver todos los tipos de animación utilizados, y todos están contentos. Animación de video para escenas, esqueleto para personajes, línea de tiempo para paisajes, procedimientos para vuelo de sistemas de partículas de emisores y fotogramas simples para las partículas mismas. Simplemente tomamos lo mejor de cada tipo.


Dilema y decisión de escribir nuestra propia solución.


De todos modos, por algunas razones objetivas, decidimos que para nuestro proyecto necesitamos animación Flash. Entonces surgió la pregunta sobre su integración en el motor. Después de probar varias opciones de complementos, optamos por la que consideramos mejor por sus capacidades. Aunque estaba vivo y bien respaldado, también tenía una licencia empresarial completamente inasequible, pero ¿quién realmente puede poner precio a un buen producto? Ahora, intencionalmente no le daré ningún nombre, para que no se vea como publicidad o antipublicidad.

Pasamos casi un año de desarrollo con este complemento, período durante el cual queda claro por qué no podemos seguir usándolo. En particular, fue la calidad de su integración a Unity. Esto dio lugar a errores bastante graves que los desarrolladores derrotaron fácilmente, no rápidamente y sin pelea. El rendimiento en los dispositivos de destino también fue terrible, y para nosotros todavía significa nivel iPad 2 . Sucedió porque intentamos hacer una integración a un motor en particular, ignorando sus detalles y baches. Estábamos más que satisfechos con la funcionalidad, pero los desarrolladores se negaron a abrir el código fuente para nosotros, incluso de forma individual. Entonces, así es como decidimos escribir nuestra propia solución.

Tenía una experiencia bastante exitosa en la escritura de extensiones para Unity y un poco de experiencia en la conversión de escenas de animación Flash a mis propios formatos. Ha sido bastante tiempo desde el último, para ser justos, pero algo que todavía recordaba. Al mismo tiempo, tomé la decisión de escribir todo esto como un proyecto favorito, por lo que no dependería del proyecto principal o de la empresa donde trabajo. Y, seamos sinceros, es bueno tener esa producción por su cuenta. De todos modos, armado con una especificación de formato SWF de 250 páginas, entré en combate.


Opciones de exportación


Para empezar, analicemos las opciones que tenemos para exportar animación desde el editor Flash. Hay algunos de ellos, cada uno con sus propias ventajas y desventajas. Vamos a repasar los principales.


Formato .XFL


En el editor de animación Flash, puede guardar el archivo fuente en un formato .XFL sin comprimir en lugar del conjunto cerrado .FLA de forma predeterminada. Ahora, es bastante fácil trabajar con este formato, pero no tiene documentación. Básicamente, consta de unos pocos subdirectorios y un montón de archivos .XML que describen todos los estados de los clips almacenados en su interior. El formato de descripción también es muy simple y comprensible, como puede ver en el siguiente ejemplo:


static_clip.xml

<DOMSymbolItem name="static_clip" itemID="5c719f28-00000051" lastModified="1550950184"> <timeline> <DOMTimeline name="static_clip"> <layers> <DOMLayer name="Layer_1" color="#00FFFF" current="true" isSelected="true"> <frames> <DOMFrame index="0" keyMode="9728"> <elements> <DOMBitmapInstance selected="true" libraryItemName="bitmap.png"/> </elements> </DOMFrame> </frames> </DOMLayer> </layers> </DOMTimeline> </timeline> </DOMSymbolItem> 
Enlace fuente

Lo que obtuvimos aquí es este clip, static_clip con una capa, Layer_1 y un marco que almacena una imagen ráster llamada bitmap.png .


movie_clip.xml

 <DOMSymbolItem name="movie_clip" itemID="5c719f30-00000053" lastModified="1550950713"> <timeline> <DOMTimeline name="movie_clip"> <layers> <DOMLayer name="Layer_1" color="#00FFFF" current="true" isSelected="true"> <frames> <DOMFrame index="0" duration="4" tweenType="motion" motionTweenSnap="true" keyMode="22017"> <elements> <DOMSymbolInstance libraryItemName="static_clip"> <matrix> <Matrix tx="-50" ty="-50"/> </matrix> <transformationPoint> <Point x="28.5" y="27.5"/> </transformationPoint> </DOMSymbolInstance> </elements> </DOMFrame> <DOMFrame index="4" tweenType="motion" motionTweenSnap="true" keyMode="22017"> <elements> <DOMSymbolInstance libraryItemName="static_clip" centerPoint3DX="128.5" centerPoint3DY="127.5"> <matrix> <Matrix tx="100" ty="100"/> </matrix> <transformationPoint> <Point x="28.5" y="27.5"/> </transformationPoint> </DOMSymbolInstance> </elements> </DOMFrame> </frames> </DOMLayer> </layers> </DOMTimeline> </timeline> </DOMSymbolItem> 
Enlace fuente

Aquí puede ver la descripción del clip movie_clip , que consta de dos fotogramas clave con índices 0 y 4, respectivamente. En esos cuadros, nuestro clip static_clip se almacena mediante las coordenadas (-50;-50) y (100;100) . Aquí hay interpolación de movimiento entre los cuadros (una animación de procedimiento, en nuestro caso es solo un cambio, sin escala y rotación). Por lo tanto, la posición del clip estático entre los cuadros clave se puede calcular utilizando la interpolación lineal de las coordenadas que tomamos de estos cuadros.

Por supuesto, en el caso de una animación real, todo será, eh ... un poco más complicado y voluminoso, pero aún así todo se puede entender, incluso sin documentación. Y puede parecer que esto es todo. Y, de hecho, conozco varios proyectos y compañías que fueron así y tuvieron bastante éxito, pero no sin algunas limitaciones y dificultades. Y estas dificultades son el verdadero golpe de .XFL, que son:


  1. Las interpolaciones pueden ser muy diferentes, tanto simples (con interpolación lineal como más complejas) con funciones personalizadas y gráficos de esta interpolación; la transformación de gráficos vectoriales en preadolescentes se realiza solo de acuerdo con sus propias reglas, comprensibles solo para Macromedia y Adobe;
  2. Los gráficos vectoriales, al igual que todas las animaciones, excepto los gráficos de trama, se describen en un archivo de texto, por ejemplo . Significa que necesita escribir su propio rasterizador, que, debido a la naturaleza y complejidad del formato vectorial en Flash, no puede realizarse;
  3. Las reglas para la reproducción de animaciones, incluidas las anidadas, deben elaborarse desde cero. No hay documentación para esto, y las respuestas a preguntas como cuándo y qué marco se debe mostrar, cuándo interpolar y cuándo dejarlo sin interpolación, tendrán que averiguarlo por su cuenta, al mismo tiempo que intentan cubra todos los casos posibles durante las ejecuciones de prueba, lo cual, créanme, es un ejercicio muy trivial para una solución general, no privada.

Estos no son todos los inconvenientes de este enfoque, pero creo que son suficientes para que comprenda que funcionaría para una solución general solo con fuertes limitaciones. Hace mucho tiempo, seguí este camino trabajando en uno de los proyectos míos. Hubo escenas de Flash con interpolaciones clásicas (sin reglas de interpolación personalizadas y funciones especiales de interpolación), gráficos rasterizados y otras oportunidades avanzadas proporcionadas por el editor de Flash. Se me ocurrió esa solución patentada de manera bastante rápida y eficiente, pero aún requería algunas limitaciones severas en los animadores, por lo que no usarían nada que pueda llamar complicado. El enfoque tiene derecho a existir y hay algunas bibliotecas basadas en él, con diversos grados de confusión, pero, como dije, funciona con muchas limitaciones.


Guiones .JSFL


Otra opción casi funcional para obtener información sobre nuestras animaciones, los scripts .JSFL le permiten ampliar su editor Flash, interactuar con su entorno, editar su animación y, por supuesto, obtener toda la información necesaria sobre las líneas de tiempo, capas, clips y marcos dentro . También lo utilizan los animadores para la automatización de varios procesos, pero en realidad esta es una historia completamente diferente. En general, el enfoque posee todos los inconvenientes del anterior, por lo que no voy a profundizar en él. Permítanme decir que les permite exportar sus escenas de animación, por ejemplo, cuadro por cuadro, pero sabemos que esto no es lo que haría un Jedi real (pero, por supuesto, podría hacerse en algunos proyectos). Volveremos a estos scripts más adelante, cuando discutamos el enfoque que elegí: para rasterizar gráficos vectoriales y optimizar las escenas exportadas.


Aplicación AIR


Este enfoque realmente funciona y se puede usar como debería. Aún así, no lo elegí, pero voy a contarte sobre esta opción, solo para el registro. La esencia de este enfoque es que creamos una aplicación AIR en Flash o, para puristas, por ejemplo, en Haxe . Esta aplicación extraerá toda la información de las escenas de animación que ya compiló en el formato SWF. En la aplicación, reproducimos la escena cuadro por cuadro, obtenemos toda la información sobre los cuadros y la guardamos en el formato más adecuado para nuestro tiempo de ejecución. Usando este método, abordamos todos los problemas que mencioné anteriormente:


  • no necesitamos rasterizar nuestros gráficos vectoriales, ya que lo hará Flash runtime. Lo único que nos queda por hacer es obtener esta información y guardar la salida ráster de nuestras piezas vectoriales;
  • no tenemos que inventar reglas de reproducción y hacer frente a la interpolación de interpolación personalizada, el reproductor Flash integrado en la aplicación AIR sabe exactamente cómo debe hacerse y básicamente hace el trabajo por nosotros;

Como beneficio adicional, tenemos la oportunidad de usar scripts de cuadros (todo el play() , stop() y otros gotoAndPlay() , a algunos animadores realmente les gustan). Como inconveniente, perdemos la oportunidad de exportar las escenas enlazadas en Flash. Pero en realidad no es tan malo, ya que podemos hacer un bucle en nuestro tiempo de ejecución, y los animadores podrían preparar todo para eso.


Cabe señalar ahora que estoy seguro de que todo será más o menos difícil de lo que lo describo, ya que personalmente no he ido allí, por lo que realmente no puedo contarte todos los detalles. Doy la bienvenida a aquellos que han ido por este camino para compartir su experiencia, ¡me alegrará leer sobre sus éxitos y fracasos!


Tu propio reproductor flash


Esta es probablemente la opción más justa, obvia y directa entre todas, pero también es la más difícil. Después de todo, eso es lo que hace un verdadero reproductor Flash, el que la mayoría de nosotros instalamos en el navegador favorito como complemento. Ahora, los representantes populares de este género son: gameswf y, nacido del primero, scaleform . Ambos están muertos hoy. Lo fascinante de ellos es que se usaron principalmente para implementaciones de GUI en varios proyectos, incluido AAA . Pero nuestro interés está en lo interno, no en las aplicaciones de bibliotecas muertas.


Cualquier reproductor Flash decente tiene al menos dos cosas importantes ocultas en su interior:


  • Analizador de formato SWF;
  • rasterizador de gráficos vectoriales;
  • máquina virtual para lanzar ActionScript del código;
  • biblioteca estándar para un código personalizado;

Sé que piensas. Cada uno de estos puntos anteriores grita que incluso si es posible implementar algo como esto, tendrá que cambiar a más de un equipo para esta tarea y pasar unos años en el desarrollo de la versión básica. Incluso la implementación de una pequeña parte solo para jugar algo le llevará mucho tiempo, y puede estar seguro de que las nuevas adiciones en forma de muchas partes indocumentadas de esta tubería duplicarán este largo período.


Sí, Internet está lleno de intentos de implementar cada una de estas partes, que varían en grados de turbidez y errores. Pero ni siquiera puede tomar estos desarrollos como base para sus propias cosas, ya que tendría que pasar años solo para cazar insectos. También tendría que agregar todas las pruebas unitarias no escritas antes de darse cuenta de que nunca podrá implementar completamente cada pequeña cosa. Aquellos tipos que intentaron agregar las capacidades necesarias a gameswf entenderán de lo que estoy hablando. Un reproductor Flash justo también debería rasterizar los gráficos vectoriales no por adelantado, sino en el tiempo de ejecución, lo que tendrá un impacto tan grande en el rendimiento que no todos los proyectos pueden pasar. Por cierto, quiero saludar a los sobrevivientes que intentaron usar Scaleform en dispositivos móviles. De todos modos, esta es la forma más solemne y desesperada, y definitivamente no es nuestra elección.


Combinando los enfoques


Entonces, finalmente vamos a mi opción. Después de estudiar todas las formas posibles, se me ocurrió esta combinación interesante. Es relativamente fácil de implementar, manejable por una persona y, al mismo tiempo, tiene suficiente funcionalidad para cubrir todas las necesidades de casi cualquier producción de animación de línea de tiempo 2D.


Primero, vamos a usar la escena de animación compilada en SWF, para no inventar varias opciones de reproducción y casi nunca adivinar cómo funciona el reproductor Flash en el interior, ya que no podemos cubrir todos los casos, pero aún estamos Buscando la solución general. Además, el editor Flash se deshace de todas las interpolaciones que utilizamos en nuestra animación, dándonos solo las posiciones desnudas de las piezas en el SWF compilado.


En segundo lugar, prohibimos el uso de scripts en animación. Sí, este requisito es muy difícil y triste, pero no tengo un equipo completo de programadores para implementar una máquina virtual decente y una biblioteca estándar que tendrían que escribir casi con los ojos vendados. Aquí, por supuesto, puede ver un inconveniente de mi enfoque en comparación con el método de aplicación de AIR. En el segundo, podríamos usar algunos scripts para la reproducción de animación interna. Al mismo tiempo, no nos impide crear buenas escenas de animación. Para transferir información personalizada de la escena al juego, puedes usar las llamadas frame labels , que encontrarás en el código. También puede anclar eventos de usuario en los marcos particulares utilizando las funciones de devolución de llamada del tiempo de ejecución.


Luego, nos deshacemos de escribir nuestro propio rasterizador de gráficos vectoriales, ya que no podemos escribirlo para el caso general y para cubrir todas las opciones y posibilidades de vectores en Flash. En cambio, rasterizaremos nuestros gráficos antes (!) Compilación utilizando un script JSFL. Mientras tanto, usando este mismo script, vamos a optimizar nuestros gráficos vectoriales al fusionar clips estáticos en una imagen, y acercar o alejar las imágenes ráster resultantes por nuestra propia prioridad: calidad y / o rendimiento. También aquí vale la pena tener en cuenta las opciones de calidad / resolución de arte para dispositivos con varias densidades de píxeles de pantalla (por ejemplo, arte HD y SD).


Conclusión de la parte lírica.


Esto concluye la primera parte de mi artículo. En el segundo vamos a discutir detalles de implementación técnica, fragmentos de código, imágenes (!), Optimización, trucos y ajustes. Próximamente, ¡no te lo pierdas!

Source: https://habr.com/ru/post/445102/


All Articles