Echo v1.4: road to season two

[SplinterGU]

no tengo una gp32, solo tengo gp2x y caanoo

[warrior_rockk]

Yo tengo una GP32 por si queréis que haga algún tipo de prueba.
Por otro lado, Drumpi, ¿esta por algún lado la versión antigua del Echo? Tengo curiosidad de probarlo y así también ver las mejoras cuando tengas la nueva versión...

[Drumpi]

No he podido buscarla en mis repositorios, y tampoco tengo ahora acceso al FTP de mi web, donde podrían estar subidos. Como siempre dirigía a la gente a la web del hamster... Si no te importa esperar, te la mando por correo a donde me digas cuando la tenga localizada en mis copias de seguridad, pero me tienes que decir qué versión quieres (Wiz, Caanoo o PC).
Si no quieres esperar, en Openhandhelds están las versiones:
Wiz 1.1: http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,35,340
Wiz 1.1 con gráficos de FBustamante: http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,35,593
Caanoo 1.1.1: http://dl.openhandhelds.org/cgi-bin/caanoo.cgi?0,0,0,0,35,791

Además, por alguna razón, no encuentro dónde subí la 1.2 ^^U
La diferencia entre la 1.1 y la 1.3 son un par de bugs en el sonido corregidos, que se pueden elegir los gráficos del juego, y dos subniveles extra, aun sin terminar (aunque eso incluye unas cuantas mejoras en el motor, que Echo puede sumergirse en el agua... pero no gran cosa que se vea).
El código es compatible con la r265 de Bennu, por si lo quereis probar en PC, y que teneis disponible para GP2X aquí:
https://www.gp32spain.com/foros/showthread.php?85395-BennuGD-r265-para-GP2X

De momento no puedo hacer más, lo siento ^^U

[warrior_rockk]

Pues te mando por privado mi correo y me envías la version PC cuando la encuentres, no hay prisa. Zenkiuuu!

[Drumpi]

Done. De paso le pediré al hamster que me pase los ficheros que le mandé para el concurso, porque no los tengo en las copias de seguridad, y no encuentro el acceso al FTP, es como si hubieran cerrado el dominio ???

[Drumpi]

Pues nada, hoy, en lugar de ponerme a buscar ficheros, tenía ganas de programar y... hasta se me ha olvidado hacer la copia de seguridad antes de ponerme en harina ^^U
Pues nada, mañana tendré que ponerme a deshacer cambios, guardar, y rehacer. Menos mal que los cambios se han concentrado en tres ficheros, uno de ellos totalmente nuevo, y que es el que se ha llevado la mayor parte del código. También gran parte del trabajo se ha ido en nuevos gráficos, y es que hoy me he puesto manos a la obra añadiendo fondos de scroll normal a los niveles. He aprovechado que tenía uno empezado hace ya la tira de tiempo... y es el que peor ha quedado.
En la imágen os muestro cómo queda el fondo después de usar una imagen fija (sacada del antiguo fondo, gracias a png_save) y dos scrolls de bennu, con un total de tres imágenes. Y flipareis cuando lo veais en movimiento, en scroll automático.



Y es que Echo va a tener tres tipos de scrolls. Este automático va a estar siempre en movimiento, uno manual, que va a seguir a la cámara, con imágenes cíclicas, y otro "adaptable", que va a medir el tamaño del mapa, y se va a desplazar en el mismo porcentaje que la cámara (si la cámara se situa a mitad del nivel, el fondo se verá en la zona central del mismo, si estamos a un tercio del nivel, la cámara mostrará la prate del gráfico situada a un tercio del mismo, y así).
Este último scroll se va a usar en el nivel 3, un mapa de scroll de unos ¿15000 pixels? con un fondo de unos 3000x240. Mamá, miedo :S

Ya os digo que el efecto de dos sencillísimos gráficos, puestos en mosaicos y desplazándose a diferentes velocidades respecto a la cámara, ha quedado ESPECTACULAR en la fase 1-4. Tanto que me ha puesto en duda si quitarlo como tenía previsto o no, porque se suponía que ese mapa iba a tener partes al aire libre y partes con el fondo del nivel. Si hubiera una forma de pintar un fondo estático en unas zonas concretas, y un scroll en otras, usar algún tipo de máscara...

[Fede]

Si hubiera una forma de pintar un fondo estático en unas zonas concretas, y un scroll en otras, usar algún tipo de máscara...

Precisamente estoy ahora dándole vueltas a la cabeza sobre el tema.

¿Multiples scrolles tileados? (Unos con transparencias y otros no).
¿Scroll de fondo?
¿Gráficos en movimiento en el fondo sólo en ciertas zonas del scroll tileado?

A ver por lo que me decido.

[Drumpi]

Lo que necesito má bien es hacer una especie de "croma", como en televisión: que pueda rellenar una parte del mapa de tiles con un color chillón, y que en él se vea una imágen estática que yo quiera. Usando postprocesado en otros motores, con funciones de máscara o similares sería fácil de hacer, pero aun lo tengo que pensar muy bien.
De momento voy a centrarme en hacer los fondos, que es lo sencillo, y en cambiar el sistema de guardado. No me gusta la idea de reescribir todo ese código, pero es que no me queda otra para lo que tengo que hacer :S No digamos ya el perder los ficheros de guardado que tengo, que son accesos rápidos a determinadas partes del juego.

[Drumpi]

Bueno, antes que nada: ya he encontrado los ficheros ejecutables de la versión 1.3 del Echo para PC, Wiz y Caanoo, las tenía en una copia de los juegos del concurso MMGTWILT del hamster (benditas copias de seguridad). Mi duda es si subirlas a GameJolt o esperar a tener la versión que realmente debió salir. Son 22MB cada fichero.

También he encontrado los binarios de BennuGD r265 para GP2X y los he subido al subforo de GP2X/WIZ/CAANOO como fichero adjunto, para que no se pierdan. Y sí, creo en un 90% que sirven para jugar al Echo v1.3 en la negrita (según he visto, los .bat de compilación apuntaban a esa versión antes de cambiarlos a la r333 en la carpeta de desarrollo).
La v1.2 sigue desaparecida, empiezo a creer que nunca se llegó a compilar (música de misterio).

[Drumpi]

Bueno, entre una cosa y otra, el proyecto se ha ralentizado bastante.
Estos días he estado buscando cosas en las copias de seguridad. Ya sabeis, la v1.3 que no sabía dónde andaba, el port de Bennu para GP2X, librerías que me habían pedido...

Así que tampoco he programado nada. He estado haciendo gráficos, y ya sabeis que para eso soy bastante lento. Encima no son gráficos pequeños... algunos sí, pero la mayoría no. Ya os he hablado de los fondos de scroll, pero es que también tenía que hacer la gran presentación de los bosses... vale, quitemos la palabra "gran" de la frase, por lo menos que sepais cómo se llaman esas moles que os perjudican la salud sin tener que buscarlos por la carpeta de FPGs... que por cierto, debería ordenarla un poquito, que ya hay demasiados ficheros para no dejarlos en carpetas.
Y estoy preparando una nueva arma. Los que hayais probado la v1.3 y hayais conseguido las 3 disponibles, habreis visto que ahora hay un scroll en la selección de armas, y es porque como no tenía hueco para 4 armas por la barra de energía de los bosses, pues de alguna manera tenía que dejar espacio para la que nunca me dió tiempo a añadir a la v1.3. Y sí, estará en la v1.3.1, que es lo que debió estar hecho para el concurso y no se pudo por todos los cambios internos que hubo en su momento (y que ahora me han ahorrado muchísimo trabajo).

En fin, aun no tengo claro el efecto que aplicaré a la entrada de estas imágenes, así que de momento voy a optar por lo sencillo. Me hubiese gustado poder crear un efecto "derretido", sé cómo se hace (moviendo lineas verticalmente, con un cierto retardo unas de otras, pero intentando crear ondas) pero tengo que buscar la manera de hacerlo sin perjudicar el rendimiento. Hay una forma, pero es muy laboriosa, y no sé si merecerá la pena.

En fin, seguiré dándole una vuelta y mañana o pasado veremos, que mañana dicen que se acercan 40º y yo voy a buscar refugio en alguna piscina ^^U

[Drumpi]

Bueno, después del bañito y de haber hecho más ejercicio que en todo el año ( :D es lo que tiene ser un friki de 200Kg encerrado en el sótano de su casa), me he puesto un rato a pintar y a programar.

Le he dedicado parte de la tarde al fondo del nivel 3. Tenía algo hecho, gracias a una versión muy antigua de potochof, y unas herramientas que apenas había usado y que me están siendo muy útiles para conseguir los efectos que estaba buscando. Hoy le he añadido algunas cosillas, y he programado el efecto de scroll que me faltaba para probarlo.
Programarlo ha sido muy rápido, tanto que cuando me ha empezado a fallar no me extrañaba, pero tras un buen rato de debug, vi que el código estaba perfecto. O sea, que me persigue otro de mis "errores de juventud": por alguna razón, la experiencia del arma no se carga bien, y no sé si es cosa de la interfaz, de los datos guardados en el fichero o de la carga de los mismos, que me hace cosas raras con el pintado y no aparecen los items de experiencia del arma.

A ver, que ando muy disperso. Pues eso, que he estado probando el fondo y quería que lo vieseis para que me dierais vuestra opinión, porque no recuerdo quién me dijo hace mucho tiempo que ese fondo naranja le hacía daño en los ojos. No quiero señalar a nadie, porque seguro que Pixel o Momia se enfadan conmigo por acusarles erroneamente :lol:



Aun no tengo claro si rebajarle el tono blanco a algo más anaranjado, que parezca más disperso en la lejana bruma. Aun tengo que añadir algún edificio más a esa parte, retocar un poco la parte central de la imagen, y terminar la parte derecha. Es un mapa grande, unos 1280x240 pixels (el más grande de momento), de unos 650KB de memoria (mucho más que cualquier nivel del juego), pero tengo la ventaja de que todos los gráficos del juego son de estilo sencillo, y que tengo la excusa de que no soy grafista :D :D :D
Me hubiese gustado haberle podido añadir efecto ondulante al fondo, como si hiciera calor, pero si ya me cuesta trabajo creer que la Wiz vaya a poder con este fondo de scroll, añadirle efecto ondulante va a ser matarla del todo. Quizás un sol animado con efecto blit aditivo podría valer, por aquello de mantener los degradados de colores sin que se tapen unos con otros (recordemos que en 16bits no tenemos  componente de color alpha), pero de nuevo, me cuesta creer que Wiz pueda con ello (necesito ese nuevo motor de scroll tileado).

De momento no os enseño más, porque os voy a arruinar todas las sorpresas, y no es plan. Tengo que arreglar ese problemilla con la experiencia del arma y averiguar por qué a los guerrilleros ahora les ha dado por darle la espalda a Echo.

[SplinterGU]

muy buen trabajo drumpi!

[Drumpi]

Gracias, Splinter, pero lo que hay más adelante ha quedado mejor, y no tenía ganas de echarle 15 minutos para hacer una captura al tercer cuarto del nivel :D

Hoy la verdad es que no tengo nada que escribir, pero voy a hacerlo, a ver si así me pongo las pilas de nuevo, porque llevo unos días que no rindo. Un colega me está mandando mensajes para que visite su página de devianart, y como hace tiempo le mandé una imágen graciosa que hice con XNALara, pues me está pidiendo opinión y va a conseguir que me enganche otra vez a hacer poses 3D.

Al lio: pues he entrado en situación de bloqueo artístico con el fondo de la ciudad. Tengo 3/4 partes hechas y me falta la final, pero no sé qué hacer. Pensaba en algo sobre alienígenas, un platillo volante (HOLY MOTHERSHIP APROACHING!!) que se viera llegando al final del nivel, justo cuando nos damos cuenta de que una de las bases terrícolas esconde una base alienígena (la zona verde), pero ni sé qué forma darle a la nave, ni qué poner debajo para rellenar, porque pensaba en la silueta de la base terrestre con la torre de control, los aviones listos para despegar... pero no lo veo.
¿Y no puedes hacer otra cosa? El fondo del nivel 1-2 también está pendiente, pero tampoco se me ocurre nada mejor que la típica pared de ladrillos gordos más oscuros, y no quiero usar mapas demasiado grandes. Tengo pendiente cambiar la decoración del nivel 4-2 (la cueva) y hacer los fondos del nivel 4, pero lo mismo: bloqueo creativo.

Hoy me he puesto un rato con el código. Después de mucho indagar, de sospechar de un fallo de Bennu al copiar datos entre posiciones de memoria, de ficheros de salvado desfasados y demás, me he dado cuenta de que todo ha sido culpa de un par de < que debían haber sido <= en sendos bucles, y lo que es peor, esa parte del código no tiene en cuenta la nueva arma, ni los ficheros de salvado, así que cuando la añada, tocará revisarlo y crear nuevos ficheros de guardado (lo que implica otra partida completa de una hora de juego).

Y nada, entre el bloqueo por una parte, y que tampoco voy a mirar demasiado el código del Echo, me tocaría hacer lo que menos me gusta: desviarme del plan para escribir una parte del código que no estaba prevista para ese momento, y dedicarle más tiempo del que esperaba. Sí, tenía pensado meterle mano al nuevo motor de scroll tileado, pero ya cuando acabase la v1.3.1 (aunque ya voy por la 1.3.2), pero el ver cómo el juego se arrastra al 50% de su velocidad en ciertas partes del nivel 1-4 en Wiz me tiene muy preocupado... y lo peor es que sospecho que gran parte de la culpa es de la detección de durezas, que es un algoritmo bastante glotón, aunque de sus más de 1500 lineas, en realidad apenas llega a ejecutar 1/6 de las mismas o menos. También podría ser de la detección de colisiones, pero creo que esa parte está bastante bien afinada (no uso ningún tipo de collision) salvo la distancia a la que empieza a comprobarla.

En fin, voy a acostarme, a ver si por fin duermo bien y mañana me da tiempo de escribir todo el motor, y con suerte, tenerlo depurado y funcionando. No debería darme tiempo porque no es algo a lo que haya que dedicarle un único día, pero cosas más gordas he hecho en días de "programación salvaje", y al Tilemap Editor 2 me remito.

Buenas noches :)

[Drumpi]

Bueno, otra entrada en mi diario de aventuras programiles.
Hoy toca un episodio spin-off, o sea, que sí, que me he puesto con el dichoso motor de scroll tileado.

Como dije, escribirlo ha sido cosa de niños... más o menos. A ver, para empezar necesitaba la última versión disponible del motor, y como fue desarrollado en Fenix, y se ha ido copiando de proyecto en proyecto y se le han ido haciendo pequeñas modificaciones que no siempre han terminado en el código de desarrollo original (es decir, estaba con un juego, veo que hay un  fallo en una linea del motor, la modifico en el código del juego, pero luego se me olvida hacerlo en el código que está en la carpeta del proyecto del scroll tileado ^^U), pues no sabía dónde estaba. Así que lo más seguro es que la útima versión fuera la del Tilemap Editor 2, pero esta fue editada para que se adaptase a su sistema y sólo almacenase un tipo específico de mapas.
Total, que me he tirado como una hora y pico limpiando código para tener, más o menos, el código original del motor. Y digo más o menos porque al final le he dejado el zoom, no me apetecía dedicarle demasiado tiempo (también he dejado algunas funciones del editor).

¿Y para qué eso? Gran parte del código me hacía falta. Aunque el funcionamiento del motor sea distinto, la carga del mapa, los cálculos iniciales y los cálculos de la posición de la cámara son los mismos, y representan el 65% del código del motor (ojo, del codigo, no de la ejecución).
Al final he optado por hacer la versión simple, en lugar de optimizar las comprobaciones al máximo...

Me explico: la idea del motor es dibujar los tiles sobre un mapa usando funciones MAP_PUT. Este mapa se mete en un scroll con los flags cíclicos horizontal y vertical, para que se repita ¿por qué? porque queremos que cuando queramos pintar una nueva columna en el mapa, en lugar de desplazarlo todo 16 pixels a la derecha, o hacer el mapa más grande, pintamos sobre la primera columna, porque esa aparecerá por la derecha de la región del scroll (recordad, scroll cíclico horizontalmente, el mapa se "repite").
Con esto conseguimos que solo necesitemos pintar una fila o una columna (o ambas) en lugar de todo el mapa. Pero eso está bien para pequeños incrementos ¿Qué pasa si nos desplazamos el equivalente a dos filas, o a cinco columnas?

Aquí es donde entra la simplicidad en lugar de la eficiencia. En lugar de calcular cuantas filas y columnas hay que actualizar, las vamos a hacer todas cada vez que la cámara cambie de tile. ¿Entonces volvemos a lo de pintar todo el mapa? No, porque como le dije a FBustamante, tenemos en memoria un array que nos dice qué tile hay pintado en cada posición del mapa, por lo que si una fila realmente no se actualiza, el valor nuevo y antiguo coincidirán y no se usará MAP_PUT, que es lo que hay que evitar a toda costa. Esto tiene un efecto secundario beneficioso: si la nueva fila tiene tiles en común con la que va a desaparecer, son tiles que no tenemos que pintar.

Para que os hagais una idea, en una prueba preliminar, tenía un mapa de 14x10 tiles. Al desplazarme un tile hacia la derecha, en lugar de pintar 10 tiles (16x16x10 pixels), el motor sólo pintó 4.

Lo malo es que la prueba preliminar reveló que el nuevo motor era más lento que el anterior. En el anterior tenía unos 909fps en reposo (sin mover la cámara, o sea, con los cálculos básicos de la cámara) y unos 898-820fps en movimiento. Con el nuevo tenía unos 700 y pico en reposo y caidas por debajo de 550fps en movimiento. ¿Qué pasaba? ¿Acaso el scroll de Bennu necesitaba 200fps en reposo? ¿mover 120 procesos dummies (bueno, menos, los tiles vacíos no tenían proceso) es más rápido que el scroll mover un mapa de 320x240?
Estuve haciendo debug, porque claro, el código lo escribí en 3 horas o menos, pero tenía fallos por todas partes, y es a lo que hoy le he estado metiendo mano, pero a pesar de ello apenas gané unos pocos frames por segundo.

Así que hice una locura: quité el dump_type=1 y el restore_type=1. El motor antiguo ganó unos pocos fps... ¡pero el nuevo superó los 1000fps en reposo! llegando a tener picos de 1100fps. Aun no he hecho pruebas, y sigo teniendo bugs tan graves como para que Windows me cierre el programa, pero sí que ha hecho scroll con valores por encima de 900 de media. Estas pruebas preliminares me dan una mejora del 10-15% aproximadamente.

De todas maneras no me hago ilusiones. Pensaba que al reducir de más de 40 procesos a 1, y de moverlo usando una función interna (start_scroll) en lugar de a mano, ganaría un 50% o más de rendimiento, que llegaría sin problemas a los 1500fps, y me ha caido como una jarra de agua fría. No había tenido en cuenta bastantes cálculos nuevos (bastantes costosos, porque hay unas cuantas divisiones y módulos), y pecaba de optimista.
Lo dicho, aun son pruebas preliminares, debo resolver todos los bugs del motor, y estos me pueden aumentar el rendimiento o bajarlo. Todavía no sé si se están haciendo todos los cálculos necesarios o si se están haciendo operaciones de más, si puedo reducir algunas operaciones o sustituir las más gordas por otras más sencillas (ya he dicho alguna vez que un if+resta consume menos tiempo que una división, y esta menos que un if+resta+resta)

Code Select Expand

//Esto consume menos
if (cont > 100) cont-=100; end

//que esto
cont = cont%100;

De momento también quiero comentar que le he cogido un par de ideas a FBustamante, como meter los mapas sobre los que vamos a pintar dentro del FPG que contiene los tiles, para usar MAP_XPUT en lugar de MAP_XPUTNP, que es más lento (quería haber usado MAP_PUT, pero no puedo evitar la necesidad imperiosa de usar el flag NOCOLORKEY para que pinte los pixels transparentes del tile). Había otra cosa pero no la recuerdo ^^U. Gracias de todas formas por la idea.
Mañana a resolver bugs, y luego a rezar para que los tiles que he usado en el Echo sean cuadrados y no me den problemas al borrar con draw_box. Con el mapa de Fenixland es un desastre, porque hay tiles que pintan hierba en el tile superior, o bordes de hierba en los laterales, y al borrarlos quedan los restos que sobresalen.

Hala, a dormir, que vine para escribir 5 minutos y llevo ya una hora.

[Fede]

¡Enhorabuena chico! :)

Porque yo no tengo pan-ta-lo-nes de hacer que ande. :(

Eso sí, ¡no me rindo!