Anarkade

Started by JaViS, February 29, 2016, 01:55:24 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

JaViS

Ya que estamos, comento, una gran parte del codigo va a ser liberada en forma de librerias, hay de todo, desde gestion de animaciones, hasta una interfaz comun para los diferentes dispositivos de entrada.


Una de las librerías es justamente la parte del mapa de durezas y la emulación de la física para plataformas. Si les interesa empezar a verla y colaborar, puedo prepararla para publicarla antes.
Working on Anarkade. A couch multiplayer 2D shooter.

gecko

muy, MUY bueno lo que estás haciendo.
Torres Baldi Studio
http://torresbaldi.com

elezeta

Buenas! Soy el otro integrante detrás de Anarkade. Gracias por las sugerencias y la buena recepción. Sólo quiero agregar que en el tumblr vamos a ir actualizando de a poco la info del juego http://anarkade.com. Como dijo Javis, hay varias librerías que vamos a ir abriendo y publicando para que las vean y así retroalimentarnos todos.

Gracias de nuevo

Drumpi

Pero entonces no entiendo cómo va el tema de tiles y durezas ¿usais un map como mapa de tiles, y los tiles los dibujais en un mapa, que mandais al start_scroll?

Es que yo no sé qué os va a dar más rendimiento, si usar el método que teneis ahora mismo, o el que uso yo, de un proceso por tile (visible y no nulo). A mi me va "lento" respecto a un scroll normal, una pantalla de 320x240 con tiles de 16x16 (un máximo de 22x17 = 374 procesos) en una Wiz va a 40fps, pero claro, no uso ninguna función pixel_put/pixel_get.
De hecho monté el propio motor con zoom en una versión, escalando los tiles e iba muy bien (es más, lo tengo que volver a montar con la última versión para el Tilemap Editor). No tenía una gran caida de frames, pero claro, aquella versión era mucho más exigente que la actual.

Pero lo dicho, a ver qué os sale, porque tiene una pinta de ser de esos juegos que te picas con los colegas y no soltais el mando en toda la tarde :)
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

JaViS

Quote from: Drumpi on March 02, 2016, 07:48:22 PM
Pero entonces no entiendo cómo va el tema de tiles y durezas ¿usais un map como mapa de tiles, y los tiles los dibujais en un mapa, que mandais al start_scroll?



Los niveles son generados aleatoriamente, es por eso que usamos tiles. Contamos con tiles de dureza y su correspondiente version 'pintable'. Con los tiles de dureza, generamos el mapa de dureza que usamos para colisiones y física.
Working on Anarkade. A couch multiplayer 2D shooter.

JaViS

Quote from: Drumpi on March 02, 2016, 07:48:22 PM
Es que yo no sé qué os va a dar más rendimiento, si usar el método que teneis ahora mismo, o el que uso yo, de un proceso por tile (visible y no nulo). A mi me va "lento" respecto a un scroll normal, una pantalla de 320x240 con tiles de 16x16 (un máximo de 22x17 = 374 procesos) en una Wiz va a 40fps, pero claro, no uso ninguna función pixel_put/pixel_get.
De hecho monté el propio motor con zoom en una versión, escalando los tiles e iba muy bien (es más, lo tengo que volver a montar con la última versión para el Tilemap Editor). No tenía una gran caida de frames, pero claro, aquella versión era mucho más exigente que la actual.



Tengo desarrollado un propio motor de tiles en la librería, que pinta la pantalla en tiempo real mientras la cámara se va moviendo. Anda muy bien de rendimiento y tiene detección de colisión por tile y lectura de formatos del editor Tiled. Pero no tiene implementado el zoom.

Para este juego en particular, me parece que me quedo con el método que tengo ahora, ya que los niveles son de un tamaño limitado, y no me hace falta tanta complejidad.
Working on Anarkade. A couch multiplayer 2D shooter.

Drumpi

Oye, no sé cómo de grandes serán las arenas de batalla, pero, si no son demasiado grandes ¿habeis pensado en dibujar toda la arena en un único graph y desplazarlo, hacerle zoom y demás a mano, prescindiendo de scrolles y demás? Lo más complicado sería el cálculo de las coordenadas de los personajes de la posición del nivel a la posición relativa a la cámara (según desplazamiento y zoom) y ya está.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

JaViS

Quote from: Drumpi on March 02, 2016, 08:19:01 PM
Oye, no sé cómo de grandes serán las arenas de batalla, pero, si no son demasiado grandes ¿habeis pensado en dibujar toda la arena en un único graph y desplazarlo, hacerle zoom y demás a mano, prescindiendo de scrolles y demás? Lo más complicado sería el cálculo de las coordenadas de los personajes de la posición del nivel a la posición relativa a la cámara (según desplazamiento y zoom) y ya está.
Pues, no me he puesto a pensar en eso todavía. Tengo miedo que el el cálculo de coordenadas se me complique mucho , pero lo voy a evaluar.
Aunque, honestamente, creo que lo más lerdo es la comprobación de durezas.

Enviado desde mi Nexus 6 mediante Tapatalk

Working on Anarkade. A couch multiplayer 2D shooter.

Drumpi

Hombre, un scroll a mapa es muy costoso computacionalmente hablando, según mis últimos tests de rendimiento. Por eso, si prescindes del scroll a mapa puedes ganar hasta un 50% (hablo de un programa que sólo haga eso, scroll a mapa frente a mapa "gigante" en pantalla). Otra cosa es que se implemente el zoom en el propio scroll.

Respecto a las coordenadas, no es muy complicado: cada personaje tiene unas locales scroll_x y scroll_y, se le pasa a una función que tenga en cuenta la posición del mapa gigante (si le pones el centro en (0,0) será mucho más fácil) y el factor de escalado (un par de sumas/restas y una multiplicación por cada coordenada) y se devuelven coordenadas de pantalla.

Por ejemplo, este es el conversor de coordenadas que uso en mi motorcillo, sin zoom, y teniendo siempre la cámara en el pixel superior izquierdo de la pantalla:
process tscroll_get_screen_position (tscroll pointer ts_struct,int x2,int y2,int pointer gsp_posx,int pointer gsp_posy)
//***************************************************************************
//  FUNCION:      tscroll_get_screen_position
//                se le pasan coordenadas del scroll y esta devuelve coordenadas
//                de pantalla.
//  PARAMETROS:   ts_struct: estructura con los datos del scroll donde queremos situarnos
//                x2: posición x dentro del scroll del proceso
//                y2: posicion y dentro del scroll del proceso
//                gps_posx: dirección donde queremos que se almacene la posición x en
//                          pantalla.
//                gps_posy: dirección donde queremos que se almacene la posición y en
//                          pantalla.
//***************************************************************************
begin
     [gsp_posx]=[ts_struct].ini_reg_x+(x2-[ts_struct].camera_x);
     [gsp_posy]=[ts_struct].ini_reg_y+(y2-[ts_struct].camera_y);
end
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

JaViS

Mucho me temo que aplicar el zoom a los calculos de coordenadas va a ser lo que complique mucho las cosas. No me sente a pensarlo bien todavia, pero seria cuestion de hacer pruebas de rendimiento y evaluar si vale la pena.
Working on Anarkade. A couch multiplayer 2D shooter.

panreyes

Quote from: JaViS on March 03, 2016, 02:56:32 PM
Mucho me temo que aplicar el zoom a los calculos de coordenadas va a ser lo que complique mucho las cosas. No me sente a pensarlo bien todavia, pero seria cuestion de hacer pruebas de rendimiento y evaluar si vale la pena.

Si pasas a trabajar sobre GPU, merece la pena infinitamente :)

JaViS

Quote from: PiXeL on March 03, 2016, 11:05:51 PM
Si pasas a trabajar sobre GPU, merece la pena infinitamente :)


voy a probar, pero necesito saber, porque renderizar el scroll en un mapa utiliza el CPU en lugar del GPU?
Working on Anarkade. A couch multiplayer 2D shooter.

SplinterGU

Quote from: JaViS on February 29, 2016, 11:47:48 PM
Quote from: PiXeL on February 29, 2016, 11:30:39 PM
Pintaza, enhorabuena :)

Si no me equivoco, utilizas scroll a mapa, ¿no?

¿Usas Bennu o PixTudio? ¿Cómo va de rendimiento?


Gracias!


Utilizo scroll a mapa, para el zoom. Quedo bueno, no? :)


Uso Bennu. No lo pase a Pixtudio todavía porque cuando lo probe, aunque lo hice funcionar eliminando algunas incompatibilidades, el rendimiento era muy bajo. Supongo que el pintado de scroll en mapa no andaba bien en Pixtudio en ese momento. Luego me concentre en completar el juego y no volvi a probar.

El rendimiento.. En Windows debe ser la única plataforma en que anda bien..
El juego en Linux anda lerdo, en Mac anda lerdo, y en Android, corriendolo en SD, lo llego hacer funcionar a 30 FPS siempre y cuando no muestre muchos procesos al mismo tiempo.
Supongo que la primera release sera en Bennu solo para Windows, y eventualmente deberia migrar a PixTudio, cuando este un poco mas avanzado.


P.D: antes que se adelanten, si, trabaje mucho en la optimizacion del rendimiento. Lo mas complicado de mejorar es la lectura de los mapas de dureza. Como dato interesante, probe reemplazar la lectura de imagenes por un array de bytes, pero el rendiemiento es el mismo.

eso de linux es raro, quizas probando otra profundidad de colores en el set_mode mejore la performance.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

Quote from: JaViS on March 04, 2016, 03:07:43 PM
Quote from: PiXeL on March 03, 2016, 11:05:51 PM
Si pasas a trabajar sobre GPU, merece la pena infinitamente :)


voy a probar, pero necesito saber, porque renderizar el scroll en un mapa utiliza el CPU en lugar del GPU?

lo mismo me pregunto... en bennugd2 el scroll a mapa es renderizado por GPU, pero en bennugd (liberado) no hay uso de GPU.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

JaViS

Quote from: SplinterGU on March 05, 2016, 01:40:52 PM

eso de linux es raro, quizas probando otra profundidad de colores en el set_mode mejore la performance.


Si, lo de Linux siempre me resulto muy raro, pero hace rato que pasa. Al punto que es mas rápido correrlo en Wine que nativo. (ya se, suena ridiculo, pero es cierto)
Working on Anarkade. A couch multiplayer 2D shooter.