animation - Usar animación SWF en aplicaciones Haxe/OpenFL
flash assets (2)
Tan grande como Haxe consiguió con NME / OpenFL, el gran problema de la transición del desarrollo de AS3 son los activos. A pesar de que Haxe es similar a as3 y OpenFL intenta proporcionar una API familiar, la falta de soporte SWF ahuyenta a muchos desarrolladores. Mi investigación sobre este tema me llevó a comprender que el archivo SWF actual es bastante débil y con errores, con muchas ediciones necesarias para el archivo SWF para poder ejecutarlo en Haxe.
La pregunta es cómo se usa la animación SWF en las aplicaciones OpenFL o, si no, cuál es la mejor solución que haya encontrado con respecto al tiempo de renderizado, el tiempo del procesador y el tamaño del archivo.
Después de haber dedicado más tiempo a la investigación y preguntar a otros desarrolladores, armé una pequeña lista de posibles alternativas para utilizar los recursos de SWF para la animación . Es de esperar que ayude a otros desarrolladores, que tienen un problema similar mientras que el soporte de animación SWF es débil.
NOTA: todos los métodos fueron seleccionados considerando tres factores importantes para mí: disponibilidad en todas las plataformas, rendimiento y tamaño de archivo de los activos. Por lo tanto, no se incluyeron todos los métodos posibles.
Probado en: HTML5, Android, iOS
La animación SWF es posible con Haxe / OpenFL, pero hay pocas reglas: sin prejuicios: todas las animaciones son fotograma a fotograma. El arte vectorial debe almacenarse en caché como mapa de bits, guardarse como mapa de bits o preprocesarse como secuencia de mapa de bits, ya que en algunas plataformas (por ejemplo, neko) el arte vectorial se transforma en ráster con bordes mordidos. Algunos errores se informaron si representaban MovieClip como gráficos o viceversa, pero no noté ningún error en HTML5, Flash, iOS, lanzamientos de Android. Las animaciones anidadas a veces pueden omitir marcos si se realiza un bucle (no se ve que tampoco, tal vez la versión anterior de NME / OpenFL lo hizo). Diría que esta es una manera bastante buena de animar el contenido a partir del tamaño del archivo y la disponibilidad de la plataforma, pero es un dolor de cabeza editar todos los activos para cumplir con los requisitos del soporte de Haxe. Y no es divertido reutilizar estos activos más adelante, ya que son todas animaciones fotograma a fotograma y es un desastre.
Animaciones de hoja de Sprite . Principal utilizado para objetivos HTML5 debido a un mayor rendimiento de representación. Esto es directamente desde un estándar OpenGL, por lo que este método debe aplicarse a todos los objetivos OpenGL. La idea es tener un archivo grande y ahorrar tiempo al abrir / cargar varios archivos más pequeños. El rendimiento es bueno, funciona en todas las plataformas probadas, pero el tamaño del archivo se agota rápidamente y apenas se puede usar para animaciones donde el tamaño del objeto cambia de tamaño: hace innecesario un gran espacio transparente, rotando la imagen para que se adapte mejor al espacio. rendimiento de representación con edición de la matriz de transformación en tiempo de ejecución.
Secuencia de cuadros aka animación de secuencia PNG . Favorito personal Funciona bien y rápido en todas las plataformas, es posible preprocesar la animación (como cualquier otro método anterior), transformarla en una matriz BitmapData, cargar en secuencia, etc. Se necesita mucho espacio en disco para las animaciones, pero puede suavizarse cargando los activos antes de usarlos (HTML5, SWF) y realmente no importa para los dispositivos móviles, ya que incluso las aplicaciones de 1 a 2 GB son aceptables para el mercado. La gran ventaja que encontré para mí es que este tipo de activo puede usarse para cualquier otro estándar en desarrollo (C ++, Java, cocos2d) y guardarse como hoja de Sprite si es necesario (por ejemplo, cocos2d, como HTML5 prefiere las hojas de Sprite sobre cualquier otra cosa como está escrito el libro oficial COCOS2DX de Roger Engelbert).
Con esta flexibilidad, el buen rendimiento es el tamaño de archivo tolerable. Prefiero este método sobre cualquier otro método mencionado anteriormente.Animación ósea - matriz PNG + lista de propiedades . Otro enfoque es tener imágenes separadas de un objeto animado y cada imagen de matriz de datos para cada cuadro. De esta forma, con un uso mínimo de espacio en disco, es posible hacer miles de animaciones. Las desventajas son: es más difícil (no imposible) tener animaciones anidadas para animaciones más complejas, las transformaciones de matriz constantes limitan el número de animaciones activas en la lista de visualización (método horrible para HTML5, otras plataformas se conservan bien) y poca reutilización de activos. Por lo general, se trata de los mismos buenos viejos recursos de SWF que se exportaron a este tipo, por lo que tiene sentido editar el FLA en lugar de la animación de hueso en sí.
Seguramente me he perdido algunos puntos importantes, hay muchas maneras de animar los gráficos y algunos podrían funcionar mejor para usted que otros, así que siéntase libre de dejar comentarios y críticas, pero todavía espero que este tema haya sido útil.
Esta pregunta puede ser obsoleta. Recopilé una aplicación C ++ en Haxe / OpenFL hace solo 5 minutos y no tuve problemas para hacer funcionar las animaciones SWF (con interpolaciones).
Aquí hay una grabación gif: https://imgflip.com/gif/7l02f
Tenía un activo llamado "library.swf" que contenía esa animación, exportado como clase "Oluv"
Esto requiere la biblioteca "swf", que ahora es gratuita, y se puede instalar con "haxelib install swf"
En mi ejemplo, agregué esto a mi archivo application.xml:
<haxelib name="swf" />
<library id="oluvLib" path="assets/library.swf" type="swf"/>
Luego, coloque esto en un proyecto de plantilla estándar de OpenFL:
Assets.loadLibrary("oluvLib", swfAssetsLoaded);
private function swfAssetsLoaded(library:AssetLibrary):Void {
var oluv = Assets.getMovieClip("oluvLib:Oluv");
addChild(oluv);
oluv.x = (stage.stageWidth - oluv.width) / 2;
oluv.y = (stage.stageHeight - oluv.height) / 2;
}
Los preadolescentes no parecen funcionar en el objetivo neko, pero funcionan bien en C ++ y flash (por supuesto).