Anarkade

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Drumpi

Por qué?

Para los personajes:
x = (mi_scroll_x - camara_x) * camara_zoom;
y = (mi_scroll_y - camara_y) * camara_zoom;
size = camara_zoom;

Y para los planos de scroll (estando el centro del gráfico en la coordenada (0,0))
x = -camara_x * velocidad * (camara_zoom/100);
y = -camara_y * velocidad * (camara_zoom/100);
Siendo velocidad el multiplicador para los distintos planos de scroll, valiendo 1.0 para el frente, 0.5 para el fondo y 0.25 para más al fondo.

Esto creo que debería funcionar. Está planteado de forma muy básica y super rápida, habría que probarlo, ajustarlo, tener en cuenta los decimales, etc, pero en menos de una semana de ratos libres deberíais tener un motor decente funcionando. Es que si no, veo que después, para adaptarlo os ibais a tirar semanas reescribiendo código. Pero vamos, eso como lo veais, Javis, no sé qué planes teneis en mente ;)
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

Bueno, el plan es sacar una beta cuanto antes, pero me convenciste, vos a pensarlo bien :)
Working on Anarkade. A couch multiplayer 2D shooter.

SplinterGU

Quote from: Drumpi on April 17, 2016, 01:00:39 PM
Juer, es que de 920fps a 580fps se va un 30% del rendimiento aproximadamente, eso en una consola portátil casca sí o sí :P (me remito a la frase de mi firma).
El scroll a mapa tiene muchas utilidades, como el ppoder usar los efectos de zoom y rotación, usar el mapa en un modo7 para ahorrar espacio y varios efectos gráficos más molones. Pero si el scroll usa imágenes fijas, sin movimiento cíclico (flags 1 y 2) y sin rotaciones, como es este caso, casi que te compensa más usar procesos sueltos y moverlos "a mano" ¿no?

drumpi, decir que reduce un 30% el rendimiento de tu juego es incorrecto, porque en un juego no solo el scroll es lo que esta consumiendo recursos, en el caso de mi equipo podria decir que el scroll en mapa le cuesta 340fps... si fuera un 30% entonces indicaria que en un proceso que consume con un scroll normal 90fps, el proceso con scroll a mapa funcionaria a 60fps, y estaria de maravillas 60fps, pero la realidad seria que el proceso iria a los saltos, asi que decir 30% no es correcto.

en mi ejemplo, me dio esa diferencia de fps, lo que no significa que a todos los casos, en todas las cpus, memorias (no es lo mismo una 133 que una 166, etc), videos (lo mismo con la velocidad de la vram), etc... consuma lo mismo...

lo que quise demostrar con mi respuesta es que el scroll a mapa sin dudas consume recursos, pero eso no significa que no sirva para tu proyecto...

esta demostrado que en el proyecto de JaViS el scroll a mapa la mueve muy bien, mas que bien, diria que anda de lujo... y esta usando mucha mas resolucion que mi prueba... asi que en mi equipo de prueba estan afectando otras condiciones... puede que sea inaceptable para una consola o puede que no... no te lo puedo asegurar...

tambien depende del tamaño del mapa y del scroll...

al inicio, reitero o reformulo mi respuesta, si te sobran fps en lo demas, te podes dar el lujo de usar un scroll a mapa...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

Claro, Splinter, a eso me refiero, que según tu prueba se pierde un 30%. Yo he supuesto que hablas de una prueba en la que sólo está el scroll, sin otros procesos que alteren el resultado, eso luego hay que tenerlo en cuenta.
Pero que se pierda un 30% de velocidad sólo es malo si andamos justos de rendimiento ¡580fps son casi 10 veces la velocidad ideal de un juego de hoy día! Yo sólo estoy teniendo en cuenta que Javis dice que en Raspberry el juego le va regular, por lo que ese "30%" de mejora es posiblemente el empujón que necesite para que le vaya fluido en un dispositivo de recursos limitados.

Es como yo con el Echo: ando como loco por conseguir 3fps más para que funcione bien en Wiz (10 sería lo ideal, para evitar el overclock), y en la nueva versión quería añadir una serie de efectos (scroll de fondo, scroll con transparencias, scroll tileado con dos capas, otros efectos gráficos...) que no son posibles en la portátil, y que en un PC funciona de sobra, pero no los he añadido por eso, porque no me funciona en la portátil.
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)

SplinterGU

nunca me puse a ver como esta hecho el echo, pero quizas tengas demsiados procesos a la vez, aunque no se dibujen... o tienes algun controlador que vaya matando y creando los procesos a medida que se esten por visualizar o dejen de estarlo?
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

El Echo está hecho con el mismo motor de scroll tileado que puse el otro día, cuando me recomendaste usar las etiquetas y los define. Es el que usa un proceso por tile.

En principio el scroll funciona bien, he conseguido reducir el número de procesos como sigue: en pantalla se representan x+2 filas e y+2 columnas de tiles, siendo X e Y el número de tiles que caben a lo ancho y a lo alto en pantalla (320/16 y 240/16), pero de esos tiles, sólo tienen proceso aquellos que no son 0. Un proceso tile es un proceso congelado que no hace nada.
Además, la última versión del Echo contiene una mejora que reconoce patrones de tiles repetidos de 2x1, 1x2 y 2x2, y usa tiles de 32x16, 16x32 y 32x32 que se generan durante la carga del nivel (y se modifica el mapa de tiles antes de ejecutar el scroll), reduciendo aun más la carga (gané como un par de fps extras en el mejor de los casos).
A la hora de moverlo, si el scroll avanza dentro de los 16 pixels de una columna/fila, su única misión es recorrer la lista de procesos tile y modificar su X e Y. El problema viene cuando la "cámara" cambia de fila o columna, que entonces tiene que hacer cálculos más gordos y es cuando el juego pega un pequeño "tirón": recorre la sección del mapa visible buscando valores no nulos, y usa la lista de procesos tile modificando la posición y gráfico de cada uno de ellos, si ya no quedan tiles que mostrar elimina los procesos sobrantes, si faltan procesos se crean y se añaden a la lista (esto último creo que es lo más costoso del algoritmo).

Tenía empezado uno que usaba un map en un scroll cíclico, de forma que sólo refrescase en la imágen una fila o una columna de tiles cada 16 pixels de movimiento (o 32, depende del tamaño de tile que se quiera usar), pero implementar el scroll tileado cíclico me estuvo dando problemas y lo abandoné. Cometí algún fallo en el algoritmo, y en ciertos desplazamientos diagonales se producía un "corte" o "desfase", y como no encontraba el error lo fui dejando. En teoría debería ser más rápido que el scroll a procesos, pero el usar funciones PUT era su debilidad, y no recuerdo si llegué a hacer pruebas preliminares de rendimiento.
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)

SplinterGU

Quote from: Drumpi on April 20, 2016, 12:08:24 PM
El Echo está hecho con el mismo motor de scroll tileado que puse el otro día, cuando me recomendaste usar las etiquetas y los define. Es el que usa un proceso por tile.

En principio el scroll funciona bien, he conseguido reducir el número de procesos como sigue: en pantalla se representan x+2 filas e y+2 columnas de tiles, siendo X e Y el número de tiles que caben a lo ancho y a lo alto en pantalla (320/16 y 240/16), pero de esos tiles, sólo tienen proceso aquellos que no son 0. Un proceso tile es un proceso congelado que no hace nada.
Además, la última versión del Echo contiene una mejora que reconoce patrones de tiles repetidos de 2x1, 1x2 y 2x2, y usa tiles de 32x16, 16x32 y 32x32 que se generan durante la carga del nivel (y se modifica el mapa de tiles antes de ejecutar el scroll), reduciendo aun más la carga (gané como un par de fps extras en el mejor de los casos).
A la hora de moverlo, si el scroll avanza dentro de los 16 pixels de una columna/fila, su única misión es recorrer la lista de procesos tile y modificar su X e Y. El problema viene cuando la "cámara" cambia de fila o columna, que entonces tiene que hacer cálculos más gordos y es cuando el juego pega un pequeño "tirón": recorre la sección del mapa visible buscando valores no nulos, y usa la lista de procesos tile modificando la posición y gráfico de cada uno de ellos, si ya no quedan tiles que mostrar elimina los procesos sobrantes, si faltan procesos se crean y se añaden a la lista (esto último creo que es lo más costoso del algoritmo).

Tenía empezado uno que usaba un map en un scroll cíclico, de forma que sólo refrescase en la imágen una fila o una columna de tiles cada 16 pixels de movimiento (o 32, depende del tamaño de tile que se quiera usar), pero implementar el scroll tileado cíclico me estuvo dando problemas y lo abandoné. Cometí algún fallo en el algoritmo, y en ciertos desplazamientos diagonales se producía un "corte" o "desfase", y como no encontraba el error lo fui dejando. En teoría debería ser más rápido que el scroll a procesos, pero el usar funciones PUT era su debilidad, y no recuerdo si llegué a hacer pruebas preliminares de rendimiento.

si, esa parte la vi... el scroll de bennugd no deberia ser mas lento que lo que vos haces, por el contrario, deberia ser mas rapido, pero claro, ahi perdes la capacidad de tiles.
igual me referia a quizas otros procesos con logica mas pesada, desconozco si existen y la cantidad que se ejecutan a la vez.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

Si, claro, el scroll de Bennu es mucho más rápido, como 10 veces más, pero pierdo más que sólo los tiles:
- Memoria, porque un mapa como el del Echo de casi 900x22 tiles de 16x16 es imposible meterlo en Wiz.
- Tiles especiales, que no se dibujan, sino que lanzan un proceso, como puede ser un enemigo, un objeto o un evento.
- Tiles animados, que de momento los trato como procesos aparte, pero que podrían ir incluidos por código o usando MAPs animados.
Y más cosas, como usar el mapa de tiles como mapa de durezas, detección de colisiones más sencillas y menos costosas, como la que usé en "el Ballena Azul" y cosas que seguro que no se me ocurren. Es por eso que pedí hace tiempo que se incorporara de forma oficial, e incluso estuve mirando la implementación del scroll para hacer mi propia librería.

Respecto al Echo, pues hay dos procesos que son auténticos titanes: el prota, que tiene código para aburrir, especialmente la parte de detectar durezas; y la detección de durezas por parte de algunos enemigos. Por lo demás, se mantiene todo al mínimo: los enemigos se duermen al alejarse (en la última versión), las colisiones se hacen por "abs(prota.x - offset - enemigo.x)" (quizás collision_box me podría dar algo más de rendimiento), y las que se hacen por collision se busca antes que haya una proximidad entre ambos procesos... Pero vamos, que hay partes en las que hay más de 20 enemigos y la Wiz no se altera gran cosa, creo recordar.
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)

SplinterGU

un scroll tileado nativo en bennugd vendria de perlas... me parece...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

JaViS

En mi motor de Tiles (que de hecho esta liberado hace rato) uso un scroll del tamaño de la pantalla visible, mas un tile de buffer, y voy pintando a medida que la camara se mueve, la cantidad de tiles que haga falta pintar.


Anda muy rapido, pero no tiene soporte a tiles animados. Al menos, no por ahora.
Working on Anarkade. A couch multiplayer 2D shooter.

josebita

Quote from: SplinterGU on April 21, 2016, 09:25:18 PM
un scroll tileado nativo en bennugd vendria de perlas... me parece...
De hecho, en pixtudio tengo algo parecido: cuando un mapa es más grande de lo que soporta la tarjeta gráfica, se parte en cachos internamente, pero sólo se puede pintar (de momento) sin rotación.

¿Tendría sentido añadir soporte nativo? Intenté hacer funcionar tu motor, javis, en pixtudio y daba algún error. Lo volveré a intentar.

SplinterGU

Quote from: josebita on April 23, 2016, 06:34:24 PM
Quote from: SplinterGU on April 21, 2016, 09:25:18 PM
un scroll tileado nativo en bennugd vendria de perlas... me parece...
De hecho, en pixtudio tengo algo parecido: cuando un mapa es más grande de lo que soporta la tarjeta gráfica, se parte en cachos internamente, pero sólo se puede pintar (de momento) sin rotación.

¿Tendría sentido añadir soporte nativo? Intenté hacer funcionar tu motor, javis, en pixtudio y daba algún error. Lo volveré a intentar.

no es exactamente lo mismo, pero cerca... un scroll por tiles necesitaria de un mapa (no un mapa grafico, sino una serie de datos donde indica que tiles hay que cada posicion) y los tiles; tiles que se repiten y combinan a lo largo del mapa... parecido, pero un poquito mas complicado... pero basicamente si...

yo creo que estaria bien un scroll tileado nativo, o al menos una lib en C...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

josebita

Sí, claro. Eso lo entiendo. Pero debería ser sencillo adaptar lo que tengo ahora mismo para, en lugar de cargar un mapa por trozos, cargue la lista de tiles reutilizando las texturas donde sea necesario.

¿Existe algún formato de tiles que sea sencillo de leer y relativamente común?

SplinterGU

Quote from: josebita on April 23, 2016, 11:07:11 PM
Sí, claro. Eso lo entiendo. Pero debería ser sencillo adaptar lo que tengo ahora mismo para, en lugar de cargar un mapa por trozos, cargue la lista de tiles reutilizando las texturas donde sea necesario.

¿Existe algún formato de tiles que sea sencillo de leer y relativamente común?

si, seria simple adaptarlo.

la verdad que no conozco ninguno, quizas podrias definir alguno.
tendrias que ver bien que cosas considerar, si simplemente un scroll o meterle deteccion de durezas, camara, regiones, etc...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

JaViS

Quote from: josebita on April 23, 2016, 11:07:11 PM
Sí, claro. Eso lo entiendo. Pero debería ser sencillo adaptar lo que tengo ahora mismo para, en lugar de cargar un mapa por trozos, cargue la lista de tiles reutilizando las texturas donde sea necesario.

¿Existe algún formato de tiles que sea sencillo de leer y relativamente común?
Tiled es muy usado y es el que uso en mi motor
Working on Anarkade. A couch multiplayer 2D shooter.