Animacion flash

[GINO]

En realidad hace falta una buena lib de dibujo vectorial que tenga todo lo esencial, luego pintar el svg con ella. Siempre surgen problemas, por ejemplo las que hay suelen ser por soft y si se quiere portar a opengl es un curro porque es implementarlo de 0. Hay que encontrar algo que ya tenga bindings soft y opengl (openvg por ejemplo).

[shao]

Yo no tengo ni idea de lo que hablais pero mi intencion era poder ejecutar graficos/animaciones como este.



Que es muy dificil y complicado? entiendo, y a la vez es una jodienda pero como ya dije por lo que veo se lleva usando hace tiempo en diferentes dispositivos, es una caracteristica de la que no se podra disponer y la verdad, aunque yo no vaya a usarlo actualmente bueno, es un handicap, tanto yo como para otros usuarios que puedan venir.

En fin si no es posible habra que acomodarse a lo que hay, si quieres seguir usando Gemix.

[g1tp111ricard8]

Yo, desde que conozco flash, no lo he usado y nunca me ha gustado usar flash por las siguientes razones:

- Es lento en ciertos casos e implementarlo en un motor como el de gemix, ni me quiero imaginar.
- La filosofía que usa flash es algo mucho más distinto a lo que se ve en gemix studio, ya que solo maneja gráficos bitmaps.
- Flash solo usa la arquitectura de 32-bits.
- Debería ser reemplazado dentro de muy poco al HTML5.

He visto sitios web que hacen presentaciones increíbles con Flash, pero mejor preferiría usar HTML5 y SVG ya que le dan mil vueltas al flash.

Una buena recomendación sería hacer como dicen una lib que importe archivos vectoriales, pero sería algo muy complicado.

[GINO]

Pero tienes que distinguir entre dos conceptos separados: gráficos vectoriales y animación de ese tipo que usa un sistema de "huesos" y interpolación para animar (físicas en algunos casos también) que creo que es a lo que te refieres.
Lo que no puedes hacer en gemix es lo primero. Lo segundo puedes hacerlo, tienes que crear un sistema de animación dependiendo de los requisitos de tu juego. El sistema puede ir de más estático (poses predefinidas en un programa de edición que son interpoladas para animar) a más dinámico (físicas realistas).
La idea es tener un "objeto" del juego troceado en diferentes partes, las cuales cada una tiene un gráfico asociado normalmente. Por ejemplo esta animación la hice en el programa ese de animación y la figura está cortada en trozos (aunque no se aprecie en el vídeo):

Luego las partes se conectan entre si: el muslo se conecta al tronco en el extremo superior y en el inferior se le conecta la pantorrilla. A esta se le conecta en la parte inferior el pie. Se crea un sistema jerárquico de trozos ("huesos" si es que se usan huesos en el programa).
Luego ya es cuestión de complejidad del sistema. Lo más sencillo es en un editor guardar fotogramas clave que contienen las propiedades de los trozos en ese fotograma (posición/rotación/etc.), y en el juego tener un sistema que simplemente cargue los trozos (en procesos o otro sistema) y manipule sus propiedades según el fotograma virtual en el que se encuentre la animación. Por ejemplo si la animación consiste en una bola que en el fotograma clave 1 (seria el fotograma real 0 de la animación) 0 está en una posición, digamos "J", y en el fotograma clave 2 (que lo situamos en el fotograma real 24) está en la posición "K", tendremos una bola que queremos que vaya de "J" a "K" en 24 fotogramas reales. ¿Como lo hacemos? Interpolando las propiedades. Por ejemplo, queremos saber donde se situará la bola en el fotograma 12. Pues en medio de "J" y "K", un punto que obtenemos interpolando las posiciones (concepto que es familiar ya gracias al módulo tween.
En definitiva, de lo que se trata es de animar proporcionando solo fotogramas clave y dejar que el sistema interpole hallando los fotogramas intermedios.
Luego todo depende de la complejidad del sistema. Por ejemplo si tiene físicas, si tiene posibilidad de mezclar animaciones (por ejemplo la animación saltar que la mezcle con la de andar o correr dependiendo de si el personaje está andando o corriendo).

Esto sí se puede hacer en gemix, aunque tiene su complejidad y nunca se va a poder hacer un sistema genérico al 100% adaptado a todos los gustos. Lo mejor es empezar por buscar y analizar motores existentes que sirvan para esto y ver de llegar a un sistema lo suficientemente genérico y versátil como para incluirlo.

[erkosone]

Que mola no lo discute nadie, que el formato SVG o algo similar hace falta pues tampoco, pero que eso se puede hacer exactamente igual con gemix pues ya te lo digo yo, son simples animaciones, que se ha pegado un eternio el creador para montar por vectores? pues seguramente, pero que las puedes reproducir en gemix de una manera mas simple.

Haber.. mola mucho y tal, pero siendo realista, tiene un curro infernal animar eso para que quede así, aunque con el programita que estoy haciendo no vas a poder crear graficos vectoriales si que vas a poder montar una animación igual de fluida, por que cambiando un poco el concepto que comenté en un principio, si no exportas los "sprites" y usas el esqueleto directamente en el juego puedes hacer lo que te venga en gana.
Está claro que esto de los gráficos vectoriales mola mucho, pero es lo que dice GINO, animarlos "a ese nivel que muestras" es bastante laborioso.

[GINO]

Yo dudo que ese juego en concreto sea vectorial. De hecho creo que usa xna al igual que el Capsized que es de los mismos desarrolladores. Ahora bien, la labor de animación y de hacer que los trozos no se noten es muy buena.

[GINO]

Lo más decente que he encontrado y enfocado a juegos es esto:
http://www.brashmonkey.com/spriter.htm

Lo he probado y he leído la especificación del formato que usan. Personalmente no me gusta en ciertas cosas. Por ejemplo dicen que quieren convertir el formato en un estandar para ese tipo de animación para juegos. Sin embargo me pareció que tiene unas carencias básicas. Por ejemplo, no puedes aniamr cada parte por separado en diferentes lineas de tiempo. Es decir, solo tienes una linea de tiempo real donde metes keyframes y solo puedes cambiar las propiedades de cada parte en ese keyframe. Lo bueno sería que cada parte tuviese su linea de tiempo porque puede que no quieras cambiar en el mismo punto las propiedades de una u otra.
Pero al menos es una buena iniciativa, lo seguiré analizando.

[shao]

Hazle saber eso que dices, igual lo incluyen o lo modifican para ponerlo como dices.

[GINO]

Otra cosa que no veo es mezcla de animaciones. Bueno el proyecto esta en estado beta, supongo que muchas cosas las pondrán en un futuro.
Pero bueno a lo que me refería más bien es a que siendo un proyecto kickstarter (http://www.kickstarter.com/projects/539087245/spriter) y habiendo la gente contribuido 71000$ y siendo de pago, como es que no esta bastante más avanzado o con una estructura de fondo mucho mejor... Pero esto son pensamientos míos, todos sabemos que hacer las cosas cuesta, más si es hacerlas bien.
Yo sinceramente, os aliento a que se cree un debate sobre cuestiones como esta en vez de esperar a que alguien lo implemente y después decir de hacer esto así o asa. Por ejemplo meter un sistema así en gemix requiere 3 cosas fundamentales:
1 - El formato. en la especificación del formato ya vienen dadas las capacidades de lo que se puede hacer, porque es un reflejo de ello.
2 - El motor en gemix que coge el formato y lo interpreta.
3 - Un editor. Sin el no se puede crear el formato y por tanto tampoco usar la característica en gemix.

[erkosone]

Suena muy interesante lo que dices GINO.
El tema del editor es casi lo ultimo en discutir creo, por que se ceñirá a lo que se hable sobre el formato en sí, y el motor pues también por que será un interprete.
Hablar del formato estaría bien, así de paso también cojo ideas para mi proyecto que aunque no va a ser nada grandioso siempre va bien tener mas claras las cosas.