Ver la versión completa : Animando personajes
Buenas, estaba yo programando mi futuro juego/motor de luchas para la consola, cuando he llegado al tema animaciones, importante y dificil asunto. :rolleyes:
Bien mi idea (nada innovante) es la de tener todos los sprites de cada animacion en una misma imagen, y luego desde el programa ir seleccionando, capturando la imagen exacta que se requiere. Creo que es el metodo mas conveniente. Pero tengo dudas que creo que podeis solucionarme ;) .
Bien supongamos que tenemos una imagen como esta misma (http://neuropod.net/SDB/sheets/Capcom/SF/ChunLi.gif), ( que pasada por cierto :rever: ) , bien aqui cada imagen de cada movimiento se situa en una posicion cualquiera, es decir no hay el mismo numero de imagenes por cada fila, por lo que a la hora de cargarlos programando seria necesario un archivo de apollo donde estan previamente escritas las posiciones exactas de cada movimiento, no se si me explico, ni si es asi exactamente, corregidme todas las burradas que diga =).
Mi idea para simplificarlo ya que lo del archivo me parece muchisiiiimo curro es fijar un numero exacto de imagenes por columna y fila, y por supuesto que todas esten contenidas en "retangulos" de igual tamaño, asi se simplifica todo un monton, solo hace falta dividir la imagen en el numero de rectangulos que se haya establecido previamente.
Este ha sido mi vaciado mental agradeceria que aportarais vuestro conocimiento sobre el tema, y me aconsejarais. Venga gracias!! :brindis:
Mi idea para simplificarlo ya que lo del archivo me parece muchisiiiimo curro es fijar un numero exacto de imagenes por columna y fila, y por supuesto que todas esten contenidas en "retangulos" de igual tamaño, asi se simplifica todo un monton, solo hace falta dividir la imagen en el numero de rectangulos que se haya establecido previamente.
Este es el método que empleo yo la mayoría de las veces. Es más simple y, aunque desperdiciarás algo de memoria, la lógica de la animación será mucho más sencilla.
Bien WinterN hasta hay bien, pero ahora viene un problema ya que algunas imagenes no ocuparan el cuadrado donde estan contenidas por completo, y esto luego a la hora de calcular colisiones seria una chapuza, por lo que ahora mi duda es...¿¿ es necesario el uso de una imagen adicional para marcar que area de cada rectangulo es realmente imagen y cual es color alpha ???, o con alguna rutina se puede calcular sin necesidad de otra imagen??? :rolleyes:
Si conoceis algun aritculo web que hable sobre el tema estaria agradecido!!!! =)
Gracias!
Bien mi idea (nada innovante) es la de tener todos los sprites de cada animacion en una misma imagen, y luego desde el programa ir seleccionando, capturando la imagen exacta que se requiere.
¿Con ir capturando la imagen exacta te refieres a crear una *nueva* imagen pequeña de cada sprite (y luego descartar la grande, supongo) ? Otra opción es mantener la imagen grande con todos los sprites y hacer una lista de rectangulos (o coordenadas, si el ancho y alto es igual para todos), para luego a la hora de hacer "blit" (ese spanglish..) tomar solo una porción de la imagen.
¿¿ es necesario el uso de una imagen adicional para marcar que area de cada rectangulo es realmente imagen y cual es color alpha ???, o con alguna rutina se puede calcular sin necesidad de otra imagen???
Puedes saber el color de un pixel (en el ejemplo se toma el color magenta como color de fondo, transparente), con lo que no haría falta una imagen adicional. De todas formas, ese metodo es preciso aunque lento.
As visto algo de mugen o beast of rage? el mugen no lo se exacto pero en el beats of rago tomabas por ejem la eskina inferior izq del rectangulo del frame de la animacion komo orientacion es k es algo dificil para mi explikarme cxk no m exliko mu bien, pero si tienes tiempo t akonsejo k t veas el beast of rage sobre to a la hora de crearte tu personaje Xd yo creo k t ayudara.
¿Con ir capturando la imagen exacta te refieres a crear una *nueva* imagen pequeña de cada sprite (y luego descartar la grande, supongo) ? Otra opción es mantener la imagen grande con todos los sprites y hacer una lista de rectangulos (o coordenadas, si el ancho y alto es igual para todos), para luego a la hora de hacer "blit" (ese spanglish..) tomar solo una porción de la imagen.
Si eso es lo que hago , mantener la imagen que contiene todas, y luego a la hora del ""blit"" paso las cordenadas de la animacion que corresponda.
Puedes saber el color de un pixel (en el ejemplo se toma el color magenta como color de fondo, transparente), con lo que no haría falta una imagen adicional. De todas formas, ese metodo es preciso aunque lento.
Perdon no me he expresado bien, ya se como aplicar el alpha tomando un color expecifico, esa no es mi duda. :confused: Pero.... aver como lo explico...
Imaginate el rectangulo que contiene un sprite en concreto, dentro de este retangulo esta la imagen mas el fondo que tiene el el color clave para el alpha. Bien facil. Pero a la hora de calcular colisiones mi manera ( hay mejores ) es calcular que el rectangulo que contieen a esa imagen este en contacto con otro rectangulo, pero puede ser que este en contacto solomante con el color alpha de fondo no con la imagen en si, por lo que el resultado es cutrisimo :loco: .
Bueno espero averme explicado mejor de todas formas muchas gracias.
Akram gracias por la idea no se me habia ocurrido mirar estos dos grandes ejemplos ! =).
^^ de nadas, yo de programacion pokito pero al menos de vez en cuando se m okurre buenas ideas Xd
Yo también de programación poco, pero imagenes como la que tienes de Chuin-Li (llamadas grids para los que no lo sepan) te las puedo proveer a patadas ^^
PD: cojonuda tu pagina, pero a la lista de mejores juegos de la megadrive yo añadiria alguno esencial, como el Gunstar Heroes ;)
Hola pakoito ! imagenes, de esas que llaman "grids" ;) tuyas ?, si te refieres a ripeadas de otros juegos no es muy dificil encontrar, gracias de todos modos!.
Por cierto la web esta todavia en pruebas =), y ese post es una primera parte, todavia quedan muuuchos juegos buenos por nombrar, si te apetece hacerte una lista yo los posteo ! :brindis:
No, ripeadas. Habia un remake del smash bros para la GP32 e hicimos un post recopilatorio con las grids, solo es rebuscarlo y pasarte las webs.
La lista, pues te mentiria si te dijera que podria hacertela porque los he jugado todos, asi que de momento te recomiendo mis favoritos: Gunstar Heroes y los Langrisser. Luego ya hay muchos que me gustan: Earthworm Jim, Moonwalker, Light Crusader, Phantasy Star, etc etc etc
Por cierto, acabo de mirar tus mensajes y hablaste ya del juego de lucha hace más de 1 mes. Ya debes tenerlo algo avanzado, podrias darme(nos) datos sobre él? es tipo MUGEN o Kof91, lucha "clasica" o alguna cosa distinta tipo Smash bros??
Bueno cierto es que ha pasado mas de un mes pero tampoco he avanzado espectacularmente, quizas en una semana tenga alguna screen para mostrar algo interesante.
Respecto al juego , primero voy a hacer una base que sera un juego de lucha basico, y con muchas facilidades para añadirle personajes, una vez tenga esta base, que por supuesto sera de codigo abierto; comenzare mi proyecto de juego, un juego de luchas pero diferente, quiero interactuar con el sonido, y añadirle efectos graficos, gran velocidad y mapas algo raros, en fin es una idea que tengo , dificil de explicar con palabras, espero meterle caña para que no tardar mucho en tener algo jugable =).
Esa es la idea, no prometo nada.
Puck2099
03/02/2006, 04:25
Yo también uso en mis juegos el método de la "tira de imágenes" para animarlas.
En principio suelo hacerlas todas del mismo tamaño de rectángulo donde están inscritas, para luego cambiar de imagen con una simple multiplicación, pero en algunos casos tuve que usar tamaños diferentes y ahí se hace necesario ir haciendo correcciones a la hora de pintarlos.
Respecto a las colisiones, supongo que lo ideal sería comparar los colores de los pixels que entran en contacto y, si ambos son distintos del color transparente, pues habrá colisión. Digo lo ideal, porque en mis juegos lo hago usando un rectángulo como tú sugieres, pero en lugar de hacerlo del tamaño del rectángulo donde esté inscrito el personaje, lo hago de un tamaño menor para que no "cante" tanto.
Saludos
Topochan
03/02/2006, 05:24
cargas la imagen y despues la muestras con un SDL_Rect la zona del tile que deseas, yo los hago verticales pues son mas rapidos leyendo.
Bueno, para tu consuelo, yo tambien me comi la cabeza para solucionar tu mismo problema. Yo tambien he empezado a hacer un juego de lucha (Little Fighter 2 remake), pero lo tengo abandonado de momento para cuando tenga algo mas de experiencia. Tengo pensados la mayoria de los algoritmos del juego, entre ellos, las colisiones.
Puck una vez que estabamos en el IRC me menciono noseque de colisiones por durezas, no lo acabe de entender. Pero esa misma palabra me dio una idea. Se que tu quieres hacer un sistema de colisiones con una sola imagen, pero intente imaginarmelo y aun asi no lo consegui, sin embargo con 2 imagenes se me solucionaba todos los problemas:
Se me ocurrio que podria crear una imagen del mismo tamaño que la tira de sprites, la cual el pixel (0,0) corresponda con el (0,0) de la tira de sprites, el (0,1) con el (0,1) y asi. La seguna imagen era una imagen PNG inexada de 2 bits por pixel. Cuando todos los bits estaban a cero, correspondia a vacio, el primer bit correspondia a cuerpo solido, y el segundo bit correspondia a cualquier cosa que dañara (Un puño, un arma del personaje, lo que sea)
Luego, a la hora de cargar los sprites, iva guardando cada estado del sprite en surfaces (iva cogiendo la informacion de un fichero de texto) y por cada surface le correspondia otra surface donde se guardaria la informacion de la imagen PNG inexada paralela. Lo que hacia, era intentar usar el sistema de colisiones de areas cuadradas, y cuando 2 sprites entraran en colision, crear una matriz que es la interseccion de las dos sprites, y en esa matriz de Uint8, "dibujar" la parte correspondiente de la surface que guarda la informacion de las colisiones. Usaba los 4 primeros bits para describir si habia un objeto solido en esa posicion de la matriz y de que equipo era, y luego los otros 4 bits decian que habia un objeto que hacia daño y de que equipo era. Luego recorria toda la matriz para buscar una posicion donde se encuentren un objeto solido y un objeto dañante de equipos diferentes. A partir de aqui sacaba las conclusiones.
Se que este algoritmo usa otra imagen, pero es que yo creo que es el sistema mas eficiente, y si crees que mi algoritmo tiene algun fallo o algo, comentamelo y tal. Espero que te sirva de algo.
Yo no tengo mucha idea de algoritmos y modos de programarlos en C y tal, pero tuve que hacer un sistema de colisiones en flash, y lo hice detectando puntos concretos del (en este caso) movieclip, dado que en flash es muy fácil saber si un punto concreto esta dentro de otro sprite.
En el MUGEN lo que haces es... por cada fotograma, tienes una serie de rectángulos que definen donde puedes pegar, en el personaje, y luego tienes otra serie de rectángulos que definen que partes del sprite hacen pupa. Asi que probablemente podrías hacerte un archivo externo, con un array de rectangulos, uno por cada fotograma, y luego sería mucho mas fácil y rápido comprobar las colisiones porque solo tendrías que mirar si dos recángulos estan haciendo intersección. Aunque el hacerte el array podría ser pesadísimo, en el Mugen se hacia con un entorno gráfico.
Hola! hago un reflote del tema porque he hecho un descubrimiento que podria ayudarte a hacerte la idea:
He encontrado un juego de lucha aqui (http://go.to/alicuu), se yama super cosplay wars. Bajalo (http://fkdigital.web.infoseek.co.jp/SCWUFINALv02.exe), descomprimelo con la constraseña "http://www.fkdigital.net" (sin comillas). Una vez este instalado abre el juego al menos una vez, se creara el archivo game.ini . Editalo cambiando el parametro Editor.Testplay.HitJudge de 0 a 1. Cuando juegues te enseñara el metodo que usan eyos para el daño: los rectangulos, el estado del pesonaje (sale en japo, pero ***** se interpreta), el comienzo y final de los ataques y demas numeros arriba que no caigo en qué son...
EDIT: También puedes jugar, el juego esta divertido. Va de tios que se pegan mientras se disfrazan de personajes de series anime y tal, esta muy currado ^^
Gracias pakoito! el tema es dificil, hay varias alternativas, y cuanto mas reales mas trabajo implican, estoy intentando encontrar la intermedia porque la idea es que todo el mundo pueda portar los personajes al juego sin excesiva complicacion, y tener que hacer un archivo de texto con las coodernadas de cada rectangulo no es nada funny!
Dentro poco, cuando tenga algo manejable te mando para que veas.
Yo pienso que en el tema de las colisiones, lo mejor, al menos lo que mas me gusta a mi es hacer bounding boxes, o sea, lo que decis de los recuadros, y luego si los recuadros de 2 sprites cualquiera se tocan, paso a mirar el color del pixel, asi me ahorro el comprobar tanto por cada frame, solo miro los que son susceptibles de colisionar.
Yo pienso que en el tema de las colisiones, lo mejor, al menos lo que mas me gusta a mi es hacer bounding boxes, o sea, lo que decis de los recuadros, y luego si los recuadros de 2 sprites cualquiera se tocan, paso a mirar el color del pixel, asi me ahorro el comprobar tanto por cada frame, solo miro los que son susceptibles de colisionar.Tardas mas en hacer un mirror que comprobar una colision como yo lo he dicho, y por cada frame que dibujas alguno de los personajes se le ha de aplicar un mirror, no? (Se estan mirando uno al otro)
Yo creo que hay potencia de sobra para hacer un sistema de colisiones tan preciso como el de comprobar pixel a pixel.
Gracias, creo que lo intentare a nivel pixel, pero de momento me ha surgido otro problemilla derivado de que soy inutil con el software de dibujo. Haber para hacer pruebas he hecho un rip muy sencillo con solo dos movimientos y tal y bueno le he puesto como color alpha el (255,0,255) magenta, sinmas.
El problema es que despues de aplicarselo a todo el grid donde estan todas las imagenes, lo guardo y no se porque el mismo color deriva en varios el solito, muy parecidos por ejemplo (255,0.,253) , pero estos no se consideran clave y al ponerlo en pantalla ocurre esta chapuza:
http://img157.imageshack.us/img157/6030/explicacion0fz.jpg
Trabajo desde linux con GIMP, y al guardar me da a elegir la calidad y otros valores, pero lo dicho de imagenes se lo justo asi que no consigo que me deje todo intacto.
Si alguien me ayuda un poquito.... :rolleyes:
Parece ser que el GIMP esta haciendo antialiasing en las imágenes, o eso o estas guardando en algún tipo de formato con compresión.
No se GIMP y no se lo que puede estar pasando, pero si estas guardando con compresión, usa mejor BMP o PNG a ver si eso soluciona el problema. Si no, mira las opciones del GIMP a ver si en algun paso te esta aplicando algun tipo de suavizado o antialiasing.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.