Looverlib 1.0

[Haddd]

 ¿y qué hay de las colisiones? Te recuerdo que yo tengo una rutina de colisión perfecta al pixel. ¿Cómo lo resuelves? Si quieres más datos, ya pue un post hace mucho tiempo, pero bueno, puedo recordarte el sistema.

[Loover]

 Las colisiones que tenía implementadas al final las quité. Por que me di cuenta que más que la colisión en sí, lo importante es todo el sistema físico que las acompaña. Es decir, detectar si hay colisión o no, sirve más bien para poco. Hay que detectar también el vector resultante, el area de colisión, etc, etc, para que junto con el sistema de física las partículas que lo conforman tengan respuestas correctas.

Así que, como yo considero que las colisiones deben estar dentro, o formar parte, de lo que es un sistema de física, y LooverLib se centra en el apartado gráfico, decidí quitarlas.

Cualquiera puede usar la libreria física que quiera, como ODE, junto con LooverLib.

Es decir, LooverLib es gráficos 2d. No es una solución completa para juegos, ni para física. Nada de eventos, nada de música.

Pero eso sí, en cuanto al sistema gráfico es muy potente. LooverLib debe ser usada para lo que está concebida: resolver totalmente el apartado gráfico 2d de una aplicación multimedia o juego.

[Haddd]

 Ya, pero no me negarás que para un juego 2D las colisiones por lo menos de cajas deberían estar implementadas. Por que no se va nadie a descargar ODE para utilizar un sistema de colisiones para un juego 2D. Tienes razón en lo que dices, de que un sistema puede ser muy complejo, pero lo básico, básico, debería implementarlo. Es una opinión, claro  :D  

[Loover]

 En mi concepción de un juego 2d con física, ojo, en la mía, la parte de colisiones debe estar implementada como una clase más por encima de las clases de respuesta de colisión. Si yo pongo colisiones en esta libreria, cualquiera que use un motor de físicas luego ni se las mirará, porque ya las tendrá. De todos modos, el próximo juego que voy a hacer, va a utilizar física, siempre podría hacer una LooverLibPhysic.

Aún así, si alguien quiere las clases que implementé de colisiones, por regiones, cajas, etc, siempre puede pedírmelas. Pero de poco le servirán en un juego de física robusta, porque solo detectan colisión en sí, nada de respuestas del vector resultante, etc.

Pero mi decisión de diseño en ese aspecto esta tomada, LooverLib solo da soporte gráfico 2d.

[Pogacha]

 Felicitaciones.
(ole)  

[TheAzazel]

¿y qué hay de las colisiones? Te recuerdo que yo tengo una rutina de colisión perfecta al pixel. ¿Cómo lo resuelves? Si quieres más datos, ya pue un post hace mucho tiempo, pero bueno, puedo recordarte el sistema.

Haddd, stoy mazo vago jeje, donde se puede ver eso de el sistema de colisiones q disenaste? a mi me interesa para incluir con la lib.

PD: sorry por el enie...alguien sabe como leches la puedo poner en un teclado ingles??? jeje

[_Grey]

 Puede que no este mal pero faltan cosas que seria de mucha utilidad.

Los cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.

Las colisiones me parecen fundamentales, si bala toca avion - avion explota, no hay fisica por ningun lado. Lo mejor seria a base de usar rectangulos para cada objeto, si puedes hacer zoom's la colision al pixel puede ser muy compleja y seria mejor dejarla para el final si pica. La colision de las primitivas graficas si que seria interesante hacerla mas compleja, mas o menos como ya has comentado, aun que sea solo para poder hacer rebotar los objetos segun interese.

Y finalmente, algo que simplemente no puedes dejar de lado, los mapas a base de tiles son imprescindibles!

Saludos.

[Haddd]

 Usando Querys de oclusión.:

1. ZBuffer=true, ZWrite=false, ZFunc=LessEqual. Valor de TODOS los sprites de Z=0
1. Haces una primera pasada de forma que dibujas todos los sprites. Lees la Query de cada sprite. Eso te dice el nº de pixels que se dibuja de cada sprite. Y ya los tienes dibujados.
2. Limpias el ZBuffer.
3. ZBuffer=true, ZWrite=true, ZFunc=LessEqual
4. Renderizas el del protagonista (Z=0) (o el que quieres comprobar si colisiona).
5. Renderizas los que pueden colisionar(Z=0.1). Lees la Query de cada uno. Como se dibujan detrás del primero, si hubiera alguna colisión, la Z fallaría en algún punto, y por tanto el nº de pixels dibujados ahora sería menor que el que hemos guardado en el paso 1.

Bueno, eso tiene un montón de optimizaciones. Pero es pixel perfect  (ole)  La grandísima ventaja es que si rotas el sprite, también funciona, cosa que los otros sistemas no lo permiten.

Bueno, si usais esta técnica, por favor, decid que ha sido idea mía en los créditos  ;)


Ya sabeis, a compartir información!!!  (uoh)

[Loover]

 

Los cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.

Fácil, lo haré. ¿Puedes mandarme al correo algún ejemplo y que datos necesitaría? Y si es posible una config que describa como cargarlo para saber exactamente a que te refieres.

Las colisiones me parecen fundamentales, si bala toca avion - avion explota, no hay fisica por ningun lado. Lo mejor seria a base de usar rectangulos para cada objeto, si puedes hacer zoom's la colision al pixel puede ser muy compleja y seria mejor dejarla para el final si pica. La colision de las primitivas graficas si que seria interesante hacerla mas compleja, mas o menos como ya has comentado, aun que sea solo para poder hacer rebotar los objetos segun interese.

Bala toca avion. Eso es tan facil como hacer un GetWidth y GetHeight de ambas superficies, y junto con la posicion compararlo. Pero bueno, ya que tanto insistis y al final me habeis convencido :D, las incluiré de nuevo. El caso es que las tengo hasta documentadas pero las quité en el último momento. Tengo implementadas colisiones por aristas, por área, por círculo y por rectángulo. Se las volveré a meter. Pero desde luego, nada de vectores resultantes ni historias, eso irá en la libreria de física. La colisión por pixel, vendrá más adelante también, ya que estamos. Gracias Hadd, recordaba tu post :)

Y finalmente, algo que simplemente no puedes dejar de lado, los mapas a base de tiles son imprescindibles!

Tan facil como cargar cada tile en un LOV_Surface y dibujarlos en el orden del mapa. Me estoy decidiendo por un editor de tiles open source. Ya le eché el ojo a uno, cuestión de tiempo.


Gracias por las recomendaciones!

[sés]

Los cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.

No sé a qué juegos te refieres, pero ya me dirás como manejas una imagen que contenga los 1000 fotogramas de un sprite... aunque con unos 50 ya te saldría una imagen "grandecita".
Lo mejor es un fichero con un formato propio con todas las imágenes, aunque lo más portable es algo como lo que ha hecho.

[Loover]

 Publiqué dos mensajes por error, borro este.

[Loover]

 Sés refiriéndose a _Grey:

No sé a qué juegos te refieres, pero ya me dirás como manejas una imagen que contenga los 1000 fotogramas de un sprite... aunque con unos 50 ya te saldría una imagen "grandecita".
Lo mejor es un fichero con un formato propio con todas las imágenes, aunque lo más portable es algo como lo que ha hecho.

Ese es el problema, que ese tipo de cosas son a gusto del usuario. Creo que lo mejor es usar unos formatos propios, los más portables posibles, y el que quiera usar la libreria tenga que amoldarse a ellos. Siempre puedes recortar los sprites después de todo. Porque sino, por la misma regla de tres, tendría que hacer cargadores tiles de todos los formatos de mapas que haya.

Algo que nadie ha comentado aún es ya que se utiliza aceleración por hardware, ¿porqué no implementar un sistema de partículas? Y es porque no sé si esperarme a tener montada la libreria de física, y a partir de ella montar el sistema de partículas. Aunque creo que finalmente lo haré directamente en LooverLib.

Tengo que hacer una lista de cosas por hacer para la próxima versión.

[_Grey]

 Lo de Sés me descoloca un poco, igual no me explique del todo bien.

Lo que quiero decir es que cuando se trabaja en un juego 2D lo normal es usar una imagen con todos los cuadros de animacion del personaje tal como esto:



Dejando a un lado de si es de calidad o no ....... (era joven e impetuoso ... :rolleyes:  :rolleyes:  :rolleyes: )

En lugar de usar imagenes en ficheros independientes, como veo que hace Loover.

Quiza abria que cambiar el script que se usa para cargar la animacion, por ejemplo, basandome en el fichero de animacion de tu ejemplo Animacion, para la nave azul que se ve en el dibujo podria ser algo asi:

Código [Seleccionar] Expand


// Aquí definimos los frames
.FRAMES
{
// Avion 1 : nombre imagen - coordenadas (x,y)-(x1,y1) de ese frame concreto de la animacion

.PATH animaciones\advance
.NAME Avion1 .FILE tech.pcx 0 0 26 22
.NAME Avion2 .FILE tech.pcx 27 0 53 22
.NAME Avion3 .FILE tech.pcx 54 0 80 22
.NAME Avion4 .FILE tech.pcx 81 0 107 22
.NAME Avion5 .FILE tech.pcx 108 0 134 22
.NAME Avion6 .FILE tech.pcx 135 0 162 22
.NAME Avion7 .FILE tech.pcx 162 0 189 22
.NAME Avion8 .FILE tech.pcx 189 0 216 22
.NAME Avion9 .FILE tech.pcx 216 0 242 22

}

// Aquí definimos las secuencias
.SEQUENCES
{
// Si no se especifica .TIME por defecto será 150ms
.NAME RockAvanzando
.FRAME Avion1
.FRAME Avion2
.FRAME Avion3
.FRAME Avion4
.FRAME Avion5
.FRAME Avion6
.FRAME Avion7
.FRAME Avion8
.FRAME Avion9
}

Los numeros que se ven, no son mas que las coordenadas x,y del recuadro que enmarca la imagen de animacion de ese sprite, dentro de la imagen mayor. Quiza seria mas comodo indicar el fichero grafico una sola vez indicandole un nombre y luego referenciarlo con el nombre que se le a dado.

Quiza sea mejor usar un formato propio como comentais. En fin solo proponia algo asi, por que no es muy usual un fichero grafico completo para cada cuadro de animacion, si no embutirlo en un fichero para la ocasion, formato propio, o simplemete usando una imagen normal como esta para luego sacar los cuadros de animacion.

Seguramente ahora se vera claro.

Saludos.

PD: Quiza alguien vio este mensaje con un [EDITANDO], se me escapo el enviar, espero que no fuese molesto.

[Loover]

 Lo que si es seguro que tengo que hacer, y que va a ser lo más inmediato junto con colocar de nuevo las colisiones, son unos métodos Add para los manager que carguen los recursos desde memoria. Para de este modo poder cargar los gráficos, scripts, etc desde por ejemplo un .pak o fichero contenedor.

Eso si que es algo imprescindible.

[zwiTTeR]

 

cuando se trabaja en un juego 2D lo normal es usar una imagen con todos los cuadros de animacion del personaje

Ummmmm yo nunca lo he hecho no debo ser normal xDD , siempre depende el juego y tal, para mi es bastante mas comodo fotogramas independientes que hacer una imagen enorme ^_^' , supongo que eso sera a gustos, la unica vez que he hecho eso que comentas fue para un juego de moviles ... pero claro, ahi el espacio está muy limitado y es util ya que los graficos son superpequeños, pero no me veo metiendo los 220 frames de animación de 240x350 pixels en un megagrafico enorme , alomejor hablo sin conocimientos (por que no soy programador), pero creo que no seria demasiado comodo :-S, no se, la verdad es que cada uno hace las cosas de formas diferentes y debe ser dificil tener a todos contentos. Animo loover campeon! xD, las colisiones aunque sean las basicas si que las veo necesarias (por si algún dia aprendo a programar y quiero usar tu libreria xD ) ;-)