Echo v1.4: road to season two

Started by Drumpi, June 12, 2016, 11:30:54 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Futu-block


Drumpi

Necesito algo que se de en películas o series de acción, que recuerde que Echo es un chavalín viviendo su propia historia como heroe, o que realmente parezca de una peli de aventuras, de acción o de superheroes. Ya he descartado el puesto de frutas :D
Pero también debería indicarle al jugador que es un checkpoint o un punto de salvado, y quiero huir del estereotipo del disquete... Mmmm, una SD... o un pendrive como los que contienen documentos clasificados o virus informáticos... ¿un disco de datos codificado ultrasecreto?... ¿quizás un maletín con un ordenador? ¿un zapatófono?...
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)

DCelso

Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Futu-block

una flecha...

un poste de autobus de parada

un cartel de parada taxi

una señal de prohibido aparcar

un paso de cebra, lol

ya lo tengo, a su perro dogy, le espera impaciente y cuando el lo acaricia ya se queda sentaito tranquilo
en caso que es a dogy a quien esté buscando, poner a su gato caty o a su pescaito fishy

Drumpi

Quote from: Futu-block on December 06, 2016, 11:52:33 AMya lo tengo, a su perro dogy, le espera impaciente y cuando el lo acaricia ya se queda sentaito tranquilo

La verdad es que es muy buena idea, no lo había pensado (y mira que es una elección obvia ^^U).
Tenía pensado usarlo en otra parte del juego, pero creo que puede ser compatible...
Entonces tendré que acabar con su diseño. Aun no tengo nada definitivo sobre Doggy, porque es difícil crear un perro adorabilísimo en menos de 16x16 (sobre todo el problema es el factor "achuchable" :P). Trabajaré en ello.

Muchas gracias, ya iba a poner el típico disco láser dando vueltas :P
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)

Ryo Suzuki

La verdad es que te está quedando muy pero que muy bien!!

Por cierto, malas noticias:



Probado en consola real y después de LOGOS OK se queda colgado, no llega a mostrar nada en pantalla.

Con la antigua versión que l1nk3rn3l montó para Dreamcast sí que pasaba de los logos y demás...

Creo que habría que reducir mucho lo que pesan las imágenes, evitar que cargue recursos como el audio y demás para que cargue los assets mínimos y más livianos para poner algo en pantalla, quizás poner says más específicos para ver qué está pasando realmente y dónde se cuelga el tema...

Drumpi

Pues por recursos no creo que sea, más que nada porque en la portada, el único FPG que carga, en principio, pesa 184KB, así que si no puede con eso la DC, mal vamos. Bueno, luego está la música, pero no llega a 1MB. Ya te dije que el Echo funciona en GP2X, que tiene menos de 32MB de RAM :D
Lo único que puedo decir es que si llega a "LOGOS OK", lo siguiente es examinar el fichero src/main_menu/main_menu.inc. Ahora mismo estoy en Linux y te he hecho una versión de ese fichero con varios SAY, a ver hasta donde llega (al menos, hasta la parte del FADE). Espero que los fin de línea Linux style no sean un problema (y si no, lo puedes arreglar con notepad++).
No te quiero mandar todo el código de nuevo porque no sé los cambios que habrás hecho, y los que tengo ahora mismo son "más o menos estables".

Y con "más o menos estables" quiero decir que he estado trasteando con los ficheros de salvado para que guarden información de episodio, capítulo y checkpoint, ya que antes sólo guardaban los dos primeros, porque era información suficiente. ¿Qué ha cambiado?, pues que ahora tenemos checkpoints. Antes los había, pero estaban relegados al episodio 3, y también al 4 pero en plan chapuza. Al añadirlos al resto del juego, me he visto obligado a añadir esta información extra, y ahora los ficheros de salvado no sirven, tengo que generar unos nuevos para hacer pruebas al modo principal (teniendo el level select, tampoco es algo que me urja).
De hecho, he estado modificando los niveles y he añadido unos cuantos: en el primer episodio hay al menos un checkpoint por cada capítulo, incluso 4 en el 4º capítulo, dadas las vueltas que hay que dar y lo largo que es. En el 3º, el del futuro postapocaliptico, hay hasta 9 puntos de salvado, en lugar de los 3 de antes... aunque aun tengo que resolver un problema con uno de ellos (he puesto uno tras el primer boss del episodio, para seguir después de tan dura batalla, pero si se inicia desde ahí, se lanza el evento que lo activa y se produce un bug "mu gordo"... aunque se me acaba de ocurrir una solución).
Hay algunos checkpoints que debo revisar, pero es que, sin el progreso normal del juego, algunos sitios hacen que Echo reciba daños antes de que se pueda empezar a controlar (la idea era que al salvar en los checkpoints, se guardasen los enemigos muertos para que no vuelvan a aparecer, pero usando el level select no hay enemigos que quitar, así que algunos checkpoints al lado de enemigos que deben morir para acceder a ellos, pueden hacerte sufrir daños antes de tiempo). Ya dije que quizás tendría que revisar los niveles, y modificarlos ligeramente. Al menos ya he resuelto un fallo que había en el mapa de durezas desde la primera versión ^^U

El cambio de los ficheros de salvado también me ha hecho modificar el menú de selección de partida. Por suerte han sido cambios menores. Y esa es otra de las cosas que quiero modificar, poder salvar más de 6 partidas, y poder elegir en cada momento cual de ellas quieres sobreescribir. Puede suponer un problema porque no sé a ciencia cierta cuántos ficheros habrá (aunque los limite) ni cuales están disponibles, y pueden complicarme la vida. Creo que voy a limitarlo a unos 15 o 20 ficheros máximo, y crear un scroll en la ventana de selección de fichero, con esa cantidad de slots, una por fichero, para no complicarlo tanto. No sé ¿cómo lo veis vosotros?

En fin, no he dicho lo más importante, pero creo que ya tengo, por fin, ¡¡una versión definitiva de Doggy!! aun tengo que pedir un par de opiniones más de confianza antes de revelarlo en público, pero creo que os va a gustar, el factor adorable es alto (más de lo acostumbrado en mi :P) y me han entrado ganas de convertirlo en mi "Yoshi" particular, pero no quiero añadir ninguna mecánica extra al juego de las que ya tenía previstas (me lo guardo para "Doggy!!!" ¿Qué? ¿que el objetivo es rescatarlo? Es la idea, pero según el guión hay más cosas que están pasando, aunque sea algo sin importancia como una guerra, y la vuelta a casa no va a ser tan sencilla :P No, no hago spoilers porque aun no hay un guión escrito, o sea, que ni yo sé lo que va a pasar en el juego, más allá de las 4 lineas generales y las 3 escenas puntuales).
A ver dónde encuentro SFX adorables y que pueda usar legalmente :P
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)

Drumpi

Vale, aun tengo que arreglar algunos problemas con los eventos (no había previsto lo de poder estár por delante de los eventos sin haberlos completado). Por suerte, la prueba que hice con el primer boss del episodio 3 ha funcionado y ya es cuestión de aplicarlo al resto de eventos.
Pero lo más urgente era ver qué es lo que tenía que optimizar, así que hice pruebas del Echo en Wiz, usando los dos motores de scroll tileado y... los resultados son, como poco, no concluyentes... o raros:

Ciertamente, el motor de scroll usando el scroll de Bennu y una imagen que se actualiza por filas/columnas (en adelante, graph_tscroll) ha demostrado ser ligeramente más rápido que el motor que usa un proceso por tile (en adelante, proc_tscroll).
Según mi análisis inicial (allá hace pffff años), el graph_tscroll debía ir un 100% más rápido como poco, y permitirme meter más enemigos y un segundo plano de scroll. Como adelanté en otro análisis posterior, la mejora apenas era de un 10%. Wiz ha confirmado este análisis en parte. proc_tscroll incorporaba optimizaciones en el mapa en tiempo de ejecución que hacía que hubiera menos procesos en pantalla al agrupar 2 o 4 tiles iguales en uno solo, y esto ha hecho que ambos scrolls funcionaran casi a la misma velocidad.

Por alguna razón, sin movimiento de scroll, proc_tscroll iba más suave que graph_tscroll, pero en cuanto empezaba el movimiento, los tirones cada 16 pixels (momento en el que se refresca la lista de procesos-tile o el mapa del scroll) eran más obvios en proc_tscroll.
No he apreciado diferencias de rendimiento en zonas donde había una gran concentración de tiles. Son los enemigos los que han marcado la diferencia de rendimento, dando esos "efectos raros" que no acabo de comprender.
Cuando había pocos enemigos, el proc_tscroll era más efectivo, pero en cuanto la cosa se sobrecargaba (hablamos de 30 enemigos o más), graph_tscroll daba algunos FPS más que el otro.

En resumen, graph_tscroll ha dado mejor rendimiento en movimiento sin enemigos y con muchos enemigo, mientras que sin desplazamiento de scroll y con algunos enemigos, es proc_tscroll el más eficiente. WTF?

Mi teoría es que el scroll de Bennu tiene más problemas manejando procesos que se ven a través de los huecos del mapa, que en manejar muchos procesos simultáneos. Pero llega un punto en el que cuando hay demasiados procesos, la carga de la gestión de estos supera en mucho el tiempo que tarda el blit en dibujar los enemigos en los huecos del scroll.

Pero claro, es una medición a ojo y son suposiciones. La mejora de rendimiento es mínima, y usar graph_tscroll me obligaría a modificar muchísimos tiles que no son de 16x16 (los hay de 32x16, 16x32 o 14x14 (items). Por lo que creo que mi mejor baza ahora mismo es intentar optimizar el rendimiento de los enemigos. Casi todos usan el mismo código de detección de durezas (gracias, include) y creo que es lo que más daño hace ahora a la CPU. Creo que si puedo suprimir su uso en los momentos de "idle", algo ganaré, pero tengo que mirar si el uso de "switch" penaliza mucho más que usar "elseif".
Y creo que debería comprobar "collision_box" antes de hacer "collision" ¿no? Actualmente compruebo que antes estén lo suficuentemente cerca del prota mediante sus locales X e Y, pero así gano algunos FPS mientras están lejos, perdiéndolos cuando están en contacto.

Otra solución es suprimir esas "habitaciones" repletas de enemigos. Las uso para restablecer la energía y conseguir items de experiencia para armas, pero se pueden sustituir por "estaciones de recarga" (aunque es un placer masacrarlos a todos con un arma bien cargada :D).

Eso sí, los fondos de scroll en Wiz se pueden ver, pero se pierde velocidad, y el "foreground" del primer capítulo está desaconsejado TOTALMENTE. Ese flag aditivo es demasiado para la consola.

Puedo preparar un paquete de pruebas si alguien quiere hacer de betatester en Wiz, con un dcb para el graph_tscroll y otro para el proc_tscroll. Una segunda opinión no me vendría mal, antes de seguir adelante.

Nada más de momento.
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)

l1nk3rn3l

#98
me imagino que estas usando dreamcast ...

vendrian bien un     execute("nivel3.dcb")     ;D

asi funcionaria como un reinicio pero con un dcb diferente..



ya dentro de poco le pondremos eso.. es que la DC se fragmenta la memoria
por tener tan poca ram...

esperad... y le echaremos mano... creo que tambien al port PS2


Drumpi

No, he dicho Wiz :D En todo caso PC. Lo de DC lo he dejado de lado mientras Ryo_suzuki no me diga lo que le lanza la consola con el último fichero que le he pasado.
Ahora, dentro de un rato, os diré los resultados de las pruebas de IF vs SWITCH, porque son sorprendentes :)
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)

Ryo Suzuki

Sé que soy un pesado, pero me tendrías que pasar el .dcb con ese cambio ya compilado porque como te comentaba a mi no me compila por el error de los songs...

Para la Dreamcast son solo 16 megas de RAM así que debemos andar con mucho ojo. De esos 16 ya el binario se lleva 1,5 aprox, más el dcb también va pesando y no estoy realmente seguro de que pueda hacer uso real de todo lo que sobra... ya he tenido alguna mala experiencia, por desgracia.

Si me puedes pasar .dcb y todas las files en un zip lo pruebo enseguida (solo tendría que hacer una iso de eso y lanzar el 1st_read con la iso con todos los recursos)

Quote from: l1nk3rn3l on December 10, 2016, 10:13:55 PM
me imagino que estas usando dreamcast ...

vendrian bien un     execute("nivel3.dcb")     ;D

asi funcionaria como un reinicio pero con un dcb diferente..



ya dentro de poco le pondremos eso.. es que la DC se fragmenta la memoria
por tener tan poca ram...

esperad... y le echaremos mano... creo que tambien al port PS2

Wow! Eso sería genial, me iría de perlas para alguna cosilla.

¿Cómo se podría implementar eso en el port de Dreamcast?

Drumpi

Bueno, si realmente no has hecho ningún cambio en los ficheros, no me costaría nada compilarte una versión para que lo pruebes, es más, creo que se podría incluso "eliminar" el proceso de control de la música fácilmente (como la carga, reproducción y descarga se lleva a cabo en un único proceso, sólo tendría que comentar el include que lo contiene y la línea que lo llama en el PRG principal).

La pega, como comentaba en mensajes anteriores, es que ando trasteando en el código de las durezas de los enemigos, y hasta que no termine con la prueba que estoy realizando, no puedo generar ningún DCB. Es un código largo, de unas 1500 líneas, en las que estoy cambiando los SWITCHs por IFs, y son unos cuantos, va a llevar tiempo. Vamos, desde que empecé hasta hoy, voy por la mitad más o menos, porque encima he estado liado con los cursos y la asistencia técnica, y sólo le he dedicado de verdad un par de días.

He mirado en mensajes atrás, y no he visto ningún mensaje sobre que tuvieras problemas de compilación por ninguna song. ¿Por qué? Yo lo he compilado en Windows sin problemas siempre, y creo que también en Linux ¿Estás intentando compilarlo en DC? :P
Pero bueno, dame unos días, que vea que la prueba va a fracasar, y cuando revierta los cambios, te genero un DCB, con los códigos y todo eso... o a ver qué puedo hacer desde las copias de seguridad.
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)

Drumpi

Por fin, hoy he conseguido terminar de cambiar los switchs por ifs... y total ¿para qué? para confirmar mis sospechas: va incluso más lento. No gran cosa, pero creo haber percibido una pequeña ralentización extra a lo que ya tenía.
Sí, los IFs son más rápidos que los SWITCHs, mientras no haya que hacer comparaciones con valores individuales. Me explico, un if con una única comparación es tan rápido o ligeramente más que un switch. Si la comparación del IF afecta a más valores (if (x>20)) entonces el IF es más rápido.
¿Qué pasa?, que en mi código viene a ser una cosa así:

if ((temp_dur == 0) || (temp_dur == 25) || (temp_dur == 50) || (temp_dur == 75) || //normal
(temp_dur == 33) || (temp_dur == 34) || (temp_dur == 83) || (temp_dur == 84) || //extras
(temp_dur == 100) || (temp_dur == 104) || (temp_dur == 105) || //especiales (extra)
((temp_dur >= 150) && (temp_dur <= 255))) //otras


El problema es que, además de cada == tiene que hacer un OR, y ya son dos operaciones que, al sumarse, son casi el doble de lentas que cada valor individual de un CASE. La última línea es más rápida, pues aunque son tres comparaciones, afectan a un rango de valores muy amplio. De hecho, creo que si el rango de valores es superior a 4, el "if ((x>=1) && (x<=4))" es más rápido que los switchs.

Podría hacer un código híbrido, intentando usar ambas cosas, según cual sea más rápido en cada ocasión (porque hay sitios donde el IF ayudaría mucho)... peeero creo que la mejora de rendimiento no compensaría las molestias. He perdido menos de un 1% de rendimiento (vamos que creo que apenas he perdido uno o dos FPS), por lo que está claro que aunque optimice esto, ahí no está el gran problema de rendimiento.

Lo que me deja la otra gran opción, que quería evitar porque afecta a unos 22 includes como poco: las colisiones. Uso collision en cada enemigo para los choques contra el prota, la espada o los disparos. He intentado optimizarlos para que sólo se usen cuando el prota está muy cerca (en los dos primeros casos) o cuando entran en el rango de tiro de Echo.
El plan es anidar el actual collision dentro de un IF (box_collision...). De esta forma, lo que se ejecutaría sería el box_collision, y si hay contacto, entonces afinaríamos la colisión con COLLISION. Creo que esto aumentaría el rendimiento, salvo en los casos reales de colisión, que tardaría el doble en confirmarlos, pero creo que compensa. ¿Qué opinais?

No me olvido de ti, Ryo. Antes de hacer nada, te prepararé un código con SAYs extra para ver hasta dónde llega dentro del menú. Te lo mandaré pre-compilado y todo, y ya me contarás qué es lo que pasa.
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)

Ryo Suzuki

De acuerdo, pásamelo cuando puedas y lo probamos de nuevo en hardware real de DC a ver qué es lo que sucede.


P.D:  l1nk3rn3l, dime algo cuando puedas que me he quedado con la intriga. He estado mirando que el port de Fenix de DC Swat podía usar y lanzar diferentes .dcb, eso sería genial!!

Drumpi

WTF!!!

Vale, hoy he estado haciendo pruebas otra vez. Tras el fracaso de la detección de durezas, he sospechado de collision.
He ido por muchos de los procesos de los enemigos, he suprimido la sección de colisiones con cualquier otro proceso, lo he metido en la consola... y he obtenido alguna mejora, pero se sigue ralentizando.
Así que nada, le he metido el graph_tscroll sin las colisiones y al principio digo "¡ostras! esto pinta de muerte". Pero apenas me acerco a una sala llena de enemigos, el juego se ralentiza a menos de la mitad. Vale que no llega a los límites normales, en lugar de ir a un 20% de su velocidad, iba quizás a un 30%, es difícil de decir, pero no es la mejora que esperaba ¡y no puedo suprimir las colisiones.
Eso sí, sin colisiones y con el motor graph_tscroll, el principio del primer nivel va casi perfecto. Tiene algún tironcillo que seguramente pueda solucionar descentrando la cámara, para evitar que se junte el refresco de los tiles del scroll con la comprobación del cambio de tile del prota.

Pero lo curioso es eso, que la ralentización viene de los procesos que se mueven por el escenario, y no es por la cantidad de procesos en pantalla (porque ya digo que graph_tscroll apenas me da entre 2 y 3 FPS extra frente al scroll por procesos), sino de exclusivamente los procesos enemigos que hay.

Entonces ya no sé qué hacer:
- Usar el graph_tscroll me obliga a modificar los tiles, que ya es un trabajo, y a meter a los procesos dentro del scroll (lo cual ahorraría la conversión de coordenadas de scroll a pantalla, que es una llamada a una función de dos o tres líneas). Es mucho esfuerzo para tan poca mejora (y más sin saber a ciencia cierta los resultados).
- Las colisiones no sé cómo mejorarlas. No sé si collision_box + collision mejorará el rendimiento o lo empeorará.
- Y tengo que mirarlo para confirmarlo, pero la detección de durezas es muy probablemente lo que más consuma. Por desgracia es la física del juego, o sea, algo muy delicado, y no sé cómo mejorarlo, de momento. No me atrevo a tocarlo.

En fin, que las pruebas me han dejado un sabor muy amargo. Conseguir optimizarlo para Wiz va a ser un suplicio, y no sé si merecería la pena, dado que quiero terminar ya el proyecto y que poca gente usa ya la Wiz (aunque el juego esté diseñado para ella). ¿Debería darle carpetazo y hacer una versión 2.0 para PC exclusivamente? ¿O simplemente abandono el desarrollo para Wiz y sigo en PC añadiendo lo que siempre he querido meter, como la segunda capa de scroll? Yo quiero mantener una versión para Wiz, aunque esta sea lenta. No sé, ahora mismo estoy en modo pesimista. Voy a darle oxígeno a la cosa y ya veremos.

Por cierto, Ryo, ya te he mandado la última versión precompilada y con código por correo. Le he añadido SAYs hasta que sale algo del menú en pantalla, espero que sean suficientes. Tiene algunas de las modificaciones de las pruebas que he estado haciendo (los enemigos no colisionan) ¡Ah! y le he quitado el proceso de control de la música, por si acaso (eso incluye las llamadas al proceso, y los includes a su fichero de código). Habrá SFX pero no música, aunque el resto de procesos la estén solicitando (vamos, que la variable que controlaba la música sigue ahí).
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)