Bennu Game Development

Hola a todos:

Acabado el Tilemap Editor 2 (o al menos, dado por "finalizado", de momento), antes de entrar en el periodo "entre proyectos", he decidido darle caña a un juego que lleva ya demasiados años en desarrollo, y que sólo pretendía ser un aperitivo para el juego de verdad.

El juego: "the amazing adventures of Echo". Objetivo: completar los tres niveles diseñados inicialmente, acabar el nivel extra creado en exclusiva para la versión 1.3 (la del concurso del hamster), y reordenar todo el código para dejarlo listo para "Doggy!!!".
Así que hoy empiezo otro worklog en el que iré diciendo los avances que vaya haciendo sobre el código, e iré subiendo a este mensaje  las betas que vaya completando. Así que empezamos.

Día 1: el momento de más ilusión de todo el proyecto, mezclado con el de más terror. Aunque el último día del desarrollo es el que más alegría da por tener el producto terminado, y el de más miedito es el día previo por la presión del tiempo, el primer día es una mezcla de ambos difícil de definir. Por un lado te has propuesto dar vida a algo nuevo, algo que llevas días, semanas e incluso meses preparando, y sabes que va a ser genial, tienes todas esas ideas en la cabeza, y sabes cómo quieres que quede, pero justo cuando te sientas delante del ordenador, comienzan las dudas, los sudores fríos, no sabes por dónde empezar y ves una montaña de trabajo del tamaño del Everest.

Pues en eso estoy.

Antes de empezar me he marcado una hoja de ruta, que espero poder seguir... más o menos. Quiero desviarme cuando el trabajo sea demasiado agobiante, e ir avanzando trabajo que no tenga nada que ver con lo que estoy haciendo, porque por suerte, hay trabajo de limpieza, programación, gráficos, diseño y música.

El primer paso es coger el código del Echo y reordenarlo. Aquellos que hayan tenido la osadía de leerlo, habrán visto que todos los ficheros de código están en la carpeta raiz, algo que en su día consideraba correcto porque no sabía compilar el código en otras carpetas. Hoy ya se hacerlo manteniendo sólo el prg principal y el bgdc.import.
Luego está el separar aun más el código porque cuando empiezas es normal tener 15 ficheros de código, pero lo he estado revisando y hay ficheros con más de 1000 lineas y más de 15 e incluso 20 procesos/funciones. Así que me toca reidentarlo todo, e intentar separar, por ejemplo, los eventos del código de los bosses, y agruparlos por niveles. O esas funciones que están en ficheros tipo game_generic.inc en separarlas si son de sonido, de carga de recursos, de búsqueda de enemigos...
Y finalmente volver a cambiar el sistema de carga de niveles, para que sea más modular y menos dependiente de lo que contenga el nivel (es decir, que dentro del switch del load_level, cada case no tenga más de 10 líneas).

Para el juego tengo previstos tres grandes cambios:
El primero es intentar cambiar el motor de scroll tileado por otro más rápido. Ya lo he comentado otras veces, que tengo en mente uno basado en dibujar en un mapa cíclico, y espero mejorar el rendimiento al menos un 30%, porque quiero que funcione fluido en Wiz sin overclock, y tener potencia de sobra para añadir nuevas cosas.
Eso nos lleva al segundo cambio: estaba previsto que la v1.3 tuviera fondos de scroll, e incluso scroll en primer plano... De hecho estaba previsto desde la v1.0, pero primero por falta de tiempo, y después por falta de potencia, no se ha añadido. También quería poder cargar los enemigos antes de empezar el nivel, o al menos, en bloque, para poder sincronizarlos, porque aquel que haya llegado al nivel 1-4, habrá visto que hay unos 8 "solecitos" juntos que, en teoría, deberían subir y bajar a la vez, pero como dependen del scroll tileado para ser creados... Y otro añadido gracias a la potencia extra sería una segunda capa a los mapas de tiles, porque hay partes del castillo del primer nivel, o de las pirámides del cuarto, que mejorarían muchísimo si se pudieran poner paredes detrás para que contrastasen con el fondo.
Y el tercer cambio es... ¿os habeis fijado que he llamado al nivel de Egipto "cuarto nivel"? Desde la versión 1.0, la fase "2012: alien invasion" siempre ha sido la tercera fase que se iba a desarrollar (aunque fue incluso la primera en tener parte del mapa y los gráficos ^^U). Pues esa es la idea: terminar el nivel de "Egipto" (porque la tercera pantalla, aun no desarrollada, es el verdadero núcleo del nivel) y crear esa "fase 2", que cambia el desarrollo plataformero ligeramente... aunque me estoy planteando ampliar la parte de las pirámides y crear un nuevo nivel en el que Echo luche contra momias y dioses egipcios mientras se abre paso hasta la cámara secreta que contiene la entrada a las cuevas que ya habeis visto y... No, me voy a guardar la sorpresa :D

También le quería dedicar tiempo, si es posible, a corregir el código del detector de durezas. Tiene un par de fallos que a más de uno os habrá hecho tiraros de los pelos, como intentar saltar a un pasillo de poca altura y no poder entrar hasta el tercer  cuarto intento, esos saltos frenados lateralmente por el techo, o los teletransportes contra las paredes cuando estábais cayendo.
Y añadir algunos detalles más, como mostrar los nombres de los bosses antes del combate.

Y una vez terminado ¿qué? Bueno, lo primero lanzarlo al público, como siempre. Versiones para Windows, Linux, Wiz/Caanoo y, si cabe, GP2X. Es posible que salgan otros ports, pero dependerá del tiempo, del HW disponible y/o de la colaboración ciudadana. Quería también subirlo a GameJolt, para tenerlo con el resto de proyectos, y de paso, probar su nueva función de compra. Don't panic, mi idea es ponerlo con donación voluntaria, ya que cada uno valore el esfuerzo.
Y si el tiempo me lo permite, iniciar una campaña de crowfunding, usando este juego como reclamo, para desarrollar finalmente "Doggy!!!" como un juego comercial. Usaría el mismo motor, pero el juego estaría más orientado a seguir una historia, más en la linea del Cave Story original, pero manteniendo las plataformas, los puzles y los disparos. Probablemente, si tiene el éxito que quiero, podría contratar a gente para que me eche una mano, porque necesitaré a alguien que me ayude con los gráficos, y me gustaría pagarle a Caleb por su música.

Es muchísimo trabajo, ahora que lo he escrito, pero bueno, como siempre digo: "...pero hay que intentarlo". Poco a poco.
La limpieza del código me puede llevar de una a tres semanas, y la reestructuración creo que un par de semanas más. Con eso hecho, poco habrá que programar (enemigos, bosses y cosillas sueltas). Corregir los fallos va a ser lo más duro, pero va a ir entre medias. El grueso del trabajo se lo va a llevar los gráficos y el diseño de niveles. Una vez terminado el nivel 4 como estaba planeado en la v1.4, sería cuestión de seguir con el nuevo nivel de Egipto o el nivel 2, ya se irá viendo.

En fin, de momento, ya he reorganizado la carpeta del proyecto: he copiado lo que tenía hecho, he organizado los contenidos extra en otras carpetas, he sacado los gráficos temporales a una carpeta de desarrollo de gráficos, y ya tengo los ficheros de código dentro de la carpeta src con sus respectivas subcarpetas. Empieza la reescritura. Deseadme suerte ^^U

Acabo de empezar y ya me he llevado la primera en la frente :(

He podido reidentar y ordenar unos cuantos ficheros: el sistema de música, el de los logos al principio, e incluso he separado un par de includes en cuatro diferentes cada uno (no sé por qué tenía el código de los logos en el mismo fichero que el de los créditos y la pausa).
Pero cuando me he puesto a probar los créditos porque había una cosa que no entendía bien del código, me ha surgido un fallo catastrófico, de esos de ventanita de Windows y de que se cerrará, con código de excepción c0000005 (que no sé cuál es).
He revisado el código y no se hace nada raro, en ese momento sólo hay 3 procesos de control activos, el de los créditos, y 20 que muestran los gráficos de los créditos. Pensaba que era cosa de la música pero no.
Entonces he probado con Bennu r263 y no se ha producido ningún error.

Os subo el pedazo de código que supuestamente da error, a ver si veis algo que yo no, y si no, puedo mandarle el proyecto a Splinter. Sí, se que está sucio, pero por suerte la parte de los créditos es un acceso casi directo (logos, menú, y ya los créditos), y ya más o menos esa parte está saneada, pero cualquiera diría que es aquel famoso bug gráfico que apareció en las últimas versiones de Bennu, porque por punteros no es: hasta ahora no he visto ninguno (y debería haber usado ya al menos un par, la verdad).

Diario de a bordo. Fecha estelar 518.191 cuarto y mitad:

Cuando me embarqué en esta misión, sabía que sería larga, que debía armarme de paciencia, y trabajar sin ninguna prisa ni atisbo de nervios. 45 ficheros de código comenzaron la misión, 54 son ahora y 30 me ha parecido contar que ya he reidentado. Pero no nos engañemos, 54 son ahora, pero muchos más van a ser al final, esta plaga está lejos de ser controlada y pronto se van a reproducir siendo muchísimos más.

De momento está siendo una tarea sencilla, pues de los menús y los créditos poco tengo que cambiar. Algo si voy a tener que alterar respecto a los ficheros de guardado, que hasta ahora almacenaban el nivel y la pantalla donde se quedó el jugador en el último punto de salvado, pero la futura inclusión de puntos de guardado va a cambiar esto, porque si antes los niveles tenían nivel y pantalla o nivel y punto de guardado, ahora van a ser tres los datos que voy a necesitar almacenar... y va a ser mejor así, es más homogéneo, pero también va a requerir cambiar bastantes cosas del comportamiento de algunos eventos y de la carga. Y si definitivamente añado elementos de muerte instantánea (pinchos, caidas o aplastamientos), tendré que añadir a la muerte la habilidad de encontrar el último checkpoint de salvado y retroceder el nivel hasta ese punto.

Pero en nuestro camino ya nos hemos encontrado con dos agujeros negros. Uno de ellos ha sido PUT_SCREEN, que no ha querido centrar las imágenes que le pasábamos, y ahora parece que una función interna está provocando un acceso no válido, que es responsable de que no pueda ver funcionar los créditos si uso pantalla a doble resolución.
Estoy replanteando seriamente downgradear la nave a la anterior revisión estable que dispongo, la r265, si el ingeniero de máquinas, maese Astilla, no encuentra solución, porque esto tiene que seguir adelante.

Estoy a punto de entrar en las aguas más turbulentas de la misión, los procesos más tochos de todo el código (el prota, los eventos y los bosses) y los más delicados (la carga de niveles, que contienen muchas inicializaciones, y necesitan una reescritura A FONDO), por lo que todo va a ir más despacio y los ficheros se van a multiplicar una cosa bárbara.

La hoja de ruta sigue en pie. Daba como mínimo una semana, y aun no es Sábado, pero seguramente necesite esas tres semanas para una buena limpieza.
Del desarrollo nuevo aun no he hecho nada, estoy viendo si tengo que tocar algo del código, pero de momento no he pasado de crear valores constantes. En un futuro necesitaré alguien que compruebe que no se ha roto nada con la limpieza, así que si hay algún voluntario para hacer de betatester, que se lo vaya pensando, preferiblemente alguien que conozca el juego y se lo haya pasado alguna vez.

Por mi parte, cierro el diario por hoy, voy a reponer fuerzas, y mañana otro ratito más de limpieza, a ver si hago tres o cuatro ficheros más.

veamos a ver si podes mantener la nave upgradeada

Enésimo día desde la invasión zombie:

Los ánimos en el bosque andan decaidos. No hay señales de vida más allá de los árboles desde que la noria de la feria acabó por los suelos por circunstancias misteriosas, los zombies escasean, Ramón se esconde para evitar ayudarme en la caza y la tia buena aun no ha sacado la ropa de verano.

Lo cierto es que escribo tras una maratón de casi tres horas de "limpieza" sin pausa, habiendo dormido apenas 6 horas justo antes de una mañana de paseos por la ciudad, así que el aire es un poco menos alegre del habitual.
Sí, con el Echo sigo de limpieza. He cogido el código detector de durezas de los enemigos, y he convertido unas 2000 lineas y pico en 4 ficheros de unas 500 de media, y uno más que los "incluye" a los 4; eso me simplificará navegar por este código para arreglar cualquier problema. La pega es que el prota tiene otro trozo de código muy similar (casi un copia y pega), y eso va a ser un día y pico de modificar código.

Así que me lo he saltado. Estoy con el fichero de enemigos, que contenía unas 4000 líneas de código (¿o eran más?) con unos 21 procesos diferentes, que están acabando en ficheros separados. Algunos enemigos sólo necesitaron 100 líneas (mas el include de la detección de durezas, si usaban físicas), pero otros como el guerrillero o la araña han sido más de 400/500 lineas de código :S
La buena noticia es que ya me quedan 5 enemigos por sacar del fichero (entre ellos, el super guerrillero, otro mastodonte de código), y que he podido optimizar algunas cosillas sin importancia, pero que espero ayuden a darle al juego ese empujoncito extra de cara a los 50fps estables.

Y ¡POR FIN! ya le he añadido la señal para indicar cómo coger los objetos. Llevaba queriendo implementarlo desde la primera versión, pero por una cosa u otra, siempre se ha ido retrasando y no lo ponía. Aprovechando que limpiaba los procesos de los items, le he añadido unas 4 líneas que controlan la creación y destrucción de este indicador, que es un proceso nuevo que cambia entre 2 gráficos, mientras sigue al prota. Los gráficos no son nada del otro mundo, pero creo que son suficiente para saber que hay que ulsar abajo :D

A ver si termino con los enemigos y me puedo dedicar a otros dos ficheros mastodónticos: los eventos (aka "el fichero gordo que incluye eventos, jefes de zona, y alguna función de salvar en plan cutre y matar enemigos atrasados para mejorar rendimiento") y el fichero del prota.
Después de eso no debería quedar mucho por limpiar. Serían los procesos que llaman al nivel, las armas del prota y poco más. El primero puede ser un problema porque es el que tengo previsto modificar entero, no me gusta el sistema de almacenamiento de los FPG_ID en memoria, ni cómo se llama al nivel, y aun tengo que hacer la separación entre sub-niveles y checkpoints, pero estaba esperando a tener todos los ficheros abiertos en notepad++ para poder hacer las búsquedas de variables cómodamente.

Y quedo a la espera de la nueva revisión de Bennu para probarla, aunque no sé si tendré ánimos de hacerlo en la Wiz ^^U

En fin, por hoy voy a dejarlo, que estoy cansado y oigo lamentos quejumbrosos de hambre, no sé si hay un pequeño batallón de "come-sesos" con ganas de tragar plomo, o es el "Chuache" que se está quejando de nuevo de cenar alubias en lata. ¡RAMÓN!

vamos a ver si preparo el entorno y compilo la ultima revision.

Pues nada, parece que tengo un virus y... no, el ordenador está bien: con Drumpi dentro no se acercan a menos de 40000mm. Soy yo, que parece que el día de "carpintería creativa" no me abrigué bien, y entre el fresquito que hacía y que estuve sudando, pues... Hoy es el día que más fuerte me está pegando...

Pero no hablemos de mi... Hablemos de lo que hago, o intento hacer.
A pesar del dolor de cabeza y el malestar general, he conseguido hacer limpieza de las más de 2000 lineas de código del prota. De nuevo he separado la lógica de detección de durezas del código principal en 4 "cómodos" ficheros. Y como bonus, el código de las armas del prota, las colisiones de los disparos (bastante sencillitas, porque van en línea recta) y los tiles animados... Sí, había tiles animados ¿no habeis visto las fabulosas cascadas del final del nivel 4-2? ¿no? ¿ES QUE NADIE SE HA PASADO EL M...?

...(Ufff, mi cabeza). Bueno, pues estoy con el fichero de eventos ¡Mi madre! 4000 líneas. Ya he separado el código de Ghyppo... el hipopótamo fantasma del nivel 1-3, y estoy teniendo problemas con el dragón: entre la gripe y sus más de 1100 líneas, con mucho código que reidentar, se me pasan horas sólo con este bicho. Estoy viendo que hay mucho código repetido entre sus 6 estados * 4 sub-estados (de media), pero no sé si de verdad está repetido, hay ligeras diferencias, y no quiero cargar más el código añadiendo comprobaciones extra o llamadas a funciones con posiblemente 10 parámetrs o más :S Al menos no hasta que se me pase la gripe y tenga ya el código listo para trasterar con comodidad.

Ya he alcanzado los 97 ficheros en la carpeta SRC, y aun me quedan 3 jefes más dentro de los eventos (aparte de los propios eventos), teóricamente me faltan 12 ficheros por limpiar, pero también me quedaban 15 hace tres días y tenía 80 y pico ficheros de código.

COF, COF. Seguiremos informando... mientras queden aspirinas.

Drumpi, te tengo dicho que no dejes la medicación.  ;D

Por lo demás tómatelo con calma. :)

Bueno, no hay mucho que contar, pero no tengo sueño (bueno, un poco sí, UUUUAAAAHHHHHZZZZZZ!!!!!!)

Pues nada, los bosses ya están cada uno en su rinconcito. No veas con el dragón de la leche, he tenido que separarlo en dos ficheros y aun así uno de ellos no ha podido tener menos de 700 líneas.
También he separado los eventos, incluso me ha dado por coger el evento 3-1 (el de las naves) y separar el código en otro de boss, que hasta ahora, ese combate era tratado en el programa como evento, no como mid-boss.
He estado repasando los includes que me quedan por limpiar, y me queda la carpeta de selección de nivel y el include principal que controla el desarrollo de la partida normal (aka game.inc), porque esta tarde le he metido mano al motor de scroll tileado. Era una versión antigua, pero no hay grandes cambios entre una y otra: funcionar funciona, y tengo aun previsto cambiarlo por el motor que tengo que arreglar.

De todas formas me he dado cuenta de que probablemente gran parte del rendimiento se me esté yendo en un enorme SWITCH que tengo incrustado en el código. Primero tengo un IF que comprueba si el tile está entre 1 y 150, y hace las tareas normales de añadir a la lista enlazada. Luego tengo un if que hace lo propio con los valores entre 151 y 999, en cuyo caso, hace un switch con unas 40 posibles reacciones diferentes (crear enemigo, crear tile especial, lanzar evento...). Y un último if con cualquier valor >=1000 para tiles optimizados (una mejora de la v1.3, que analiza el mapa en busca de tiles repetidos en espacios contiguos, y los cambia por versiones 2x2, 2x1 o 1x2 del mismo tile que se crean en runtime, reduciendo el número de tiles no nulos, y por tanto, procesos).

Bueno, eso no sé cómo optimizarlo. De momento voy a terminar la limpieza, que hoy he cogido el código de algo que tenía pendiente para el nivel 2, y me va a llevar un rato. Luego a ver qué tal está la carga de los niveles, porque el game.inc tiene una cantidad de procesos que no corresponden ahí...

Bueno, ya puedo dar por terminada la limpieza de código.
Ha sido arduo, pero ya tengo los procesos en ficheros de no más de 500 lineas, agrupadas por categorías, y sin compartir ningún fichero tipo "misceláneo", incluyendo el game.inc, que tenía funciones de 4 o 5 cosas diferentes.
La buena noticia es que el mecanismo de carga de los niveles está mucho mejor estructurado de lo que pensaba. Aun necesita cambios para que se ajuste al nuevo sistema nivel-subnivel-checkpoint, en lugar del viejo nivel-(subnivel|checkpoint).
Otra de las cosas que necesita cambios es el sistema de salvado. Aunque el sistema actual es bueno, puede dar problemas en cuanto añada el item de guardado (a menos que se borren si se está jugando sin guardar partida), y no qeda del todo claro cuándo se guarda (depende de dos o tres procesos diferentes, según el momento: fin de nivel, evento, boss...).

El caso es que ya está todo reidentado, reordenado, y todo está más claro ahora. De momento quiero probar el juego completo con la última versión de Bennu antes de liberar nada. Ya han surgido un par de contratiempos, uno de ellos bastante grave (porque no se pueden leer los menús), y quiero solucionarlos si se pueden, antes que lanzarla con una versión antigua de BennuGD. Tengo previstas lanzar versiones para Windows, Wiz, Caanoo, y si puedo, Linux y GP2X. Ojo, sería la v1.3.1, una revisión de la lanzada para el concurso de Gecasoft, no la actual v1.4.

Estad al tanto ;)

Enhorabuena chico.  8)

Por cierto, ¿hay bennu para GP2X?

No me las des aun, queda mucho por hacer. Esto es sólo el principio.
En cuanto vea que realmente no he roto nada, ya se habrá dado el primer paso de la v1.4. A partir de ahí es cuando empieza el auténtico trabajo duro (sólo hemos pasado el tedioso).

Respecto a Bennu para GP2X, sí, yo mismo compilé los fuentes hace ya... pfffff. Hay una versión que funciona en las GP2X con firm oficial, y otra para firms con Open2X que va ligeramente más rápida. Se hizo así porque se compilaron con dos toolchains diferentes, y aun me ando peleando para conseguir entender qué leches hice :P Aun tengo que compilar las versiones más modernas, porque estamos hablando de r100 y pico, así que fíjate si ha llovido desde entonces.

Por cierto, si te animas con gráficos nuevos para el Echo, te puedo ir pasando betas exclusivas pa ti, con acceso a las areas nuevas LOL
Tengo pendiente usar aquellos tiles de fondo que hiciste para la fase egipcia, pero sólo si consigo mejorar el rendimiento del motor de scroll tileado, si no, no podré añadir la segunda capa.

Quote from: Drumpi on June 26, 2016, 12:58:38 PM
Por cierto, si te animas con gráficos nuevos para el Echo, te puedo ir pasando betas exclusivas pa ti, con acceso a las areas nuevas LOL
Tengo pendiente usar aquellos tiles de fondo que hiciste para la fase egipcia, pero sólo si consigo mejorar el rendimiento del motor de scroll tileado, si no, no podré añadir la segunda capa.

Fale. Pero con tranquilidad.
No empecemos con las Drumpi-Locuras de terminarlo para algún concurso o cosa por el estilo. :)
No tengo el ánimo para meterme de gordo, pero me apetece dibujar.
...
Respecto al scroll de fondo, ¿podría ser de tiles más gordos?
Por lo que observé en el Cave History el fondo solían ser tiles bastante más gordos, además de que se tendría que repintar menos.
...
¿Y Bennu para GP32? ¿Existe?¿Sería esta consola demasiado lenta?

De momento no hay prisa, no voy a entregar nada en una fecha determinada, pero tampoco quiero extender el desarrollo durante demasiado tiempo. Mi idea es tener una base sólida, un motor ya hecho con el que poder desarrollar el "Doggy!!!" (y probablemente hacer un crowfunding para el proyecto, y poder pagarle al grafista y al músico que quiera incorporarse).

Quiero meter dos cosas de fondo:
- Primero, una segunda capa al scroll tileado. Usaría tiles del mismo tamaño y serviría para poner cosas detrás de Echo, por ejemplo, paredes en los niveles 1-2 y 1-4, dejando ver el cielo nocturno en determinadas partes. Eso no quiere decir que no se puedan usar tiles de 32x32, 32x16, o cosas así: lo bueno de este motor es que no te obliga a usar tiles de tamaño fijo. De hecho, la v1.3 incorpora una mejora que crea tiles de 32x32, 48x48, 32x48 y 48x32 usando el mismo tile repetido, y modifica el mapa de tiles para usarlos y ahorrar cálculos al reducir el número de procesos tile.
- Por detrás, un fondo con el scroll de Bennu. El tamaño de los gráficos no importaría aquí, pero deben ser cíclicos o a pantalla completa. Ejemplos: en el nivel 1-1 seguiría estando el cielo estrellado fijo, pero quiero meter tres capas de nubes en scroll cíclico horizontal, similar a la fase nocturna de Cave Story
http://s16.postimg.org/e3l9v3vh1/screenshot_1380535086.png
El nivel 1-2 sería simplemente el fondo de ladrillos del castillo, y el nivel 3 sería un único gráfico de 3000*240 que se desplaza más léntamente que el scroll normal, pero dejando ver ciudades en ruinas, o el cañón sobre el que se pasa en la zona del puente.

El Cave Story siempre usa tiles de 16x16, lo que pasa es que para determinados fondos usa imágenes más grandes.

Ya Bennu para GP32 no sé si hay port. Yo no la tengo (y me gustaría) y no recuerdo que lo hubiera. Si bien hay algún rastro en mi cabeza de que Splinter tenía una GP32 y que no pudo portarlo. El rendimiento lo veo muy complicado, no imposible porque el Echo funciona en GP2X medianamente bien (lo cual fue una sorpresa, porque fue un port hecho por mi, sin optimizaciones ni nada), pero estaríamos muy limitados en memoria porque la mayor parte se la llevaría el propio Bennu.

no tengo una gp32, solo tengo gp2x y caanoo

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...

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 (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 (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 (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

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

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 ???

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.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3573)

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...

Quote from: Drumpi on June 29, 2016, 07:45:05 PM
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.

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.

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).

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

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:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3578)

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.

muy buen trabajo 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 :)

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)

//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.

¡Enhorabuena chico! :)

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

Eso sí, ¡no me rindo!

Tranquilo, Fede, en cuanto lo acabe lo subo, así podrás tomar ideas y, si eres capaz, corregir mis fallos (¡SÍ, POR FAVOR! :( ).
Lo que pasa es que el debug me va a llevar un día o dos, porque hay bastante que corregir, y no es fácil cuando tienes 120 elementos que analizar cada frame.

El truco está en no asumir nada: ¿has sumado 3 a una variable? Comprueba con un say que realmente se ha sumado 3 y no ha habido otra suma en otra parte que ha alterado ese valor. Ve analizando paso a paso que todo se hace de acuerdo a lo que has pedido, mostrando por pantalla o por consola los valores en todo momento. Busca patrones en los errores, si eres capaz de encontrarlos es fácil encajarlos en tu código y corregirlos para qe no sucedan.
Y paciencia, mucha paciencia, porque el bug no suele estar donde buscas, y en ocasiones te tienes que desviar 4 procesos y 100 lineas para encontrarlo. El debug necesita el doble o el triple de tiempo que la programación en sí.

Después de ese paso lateral con el scroll tileado me he dado cuenta de que he empezado a hacer el equivalente en programación a divagar, y he perdido la ruta del proyecto. Me he dado cuenta cuando, a parte de notar que he bajado el ritmo, me vi pintando uno de los enemigos nuevos del nivel 4-3, algo que no iba a aparecer hasta la v1.4 ¡Primero tengo que llegar a la v1.3.1... digo v1.3.2!

Así que he cogido y he hecho una lista de las prioridades de las cosas que tengo que hacer para la v1.3.2, las que podrían ir pero que no son obligatorias (aunque sí que irían en la 1.4), y las que finalmente sólo aparecerán en la versión que tengo planteada como final (aunque se me están acumulando ideas que darían para una 1.5).
Ahora, aunque es un poco más peñazo porque las cosas obligatorias me exigen pintar, que es algo que es lento y tedioso en según qué cosas (especialmente cuando no tengo ninguna inspiración para seguir), ya tengo de nuevo puestos los ojos en la ruta a seguir.

Lo primero ha sido dejar el nuevo motor de scroll tileado, que por lo pronto es opcional para la v1.3.2. Ya está hecho y sé que es más rápido, pero hay cosas que corren más prisa que andar experimentando con el nivel más bajo del código del juego.
Y eso son los fondos y la presentación de los jefes. Lo de los fondos ya sabeis que llevan planeados desde la primera versión, y tengo hechos como la mitad (faltan el nivel 1-2, 1/4 del 3, no se si hacer alguno para el 4-1, y el fondo del nivel 4-2).
Y lo de las presentaciones de los jefes también llevaba bastante tiempo en la lista, sobre todo cuando más de uno me preguntaba por el nombre de alguno de ellos. Pues bien, hoy puedo anunciar que, oficialmente, todos los jefes de nivel ya tienen nombre. Ya lo tenían si los buscabas entre los FPGs, pero ahora podreis verlos antes de la batalla, cada uno con su propia animación, como por ejemplo:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3585)

...Aunque aun tengo que pulir algún detalle, porque el texto del último jefe lo he hecho del mismo color que el propio jefe y me he dado cuenta después de aplicarle varios filtros y retoques a la imágen, y ponerlo en el propio juego. Ahora cambiarle el color puede ser una tortura :S Espero que mis conocimientos de Potochof me ayuden una vez más.

Tengo que seguir creando fondos, probar el nuevo motor... ¡y probar la última versión de Bennu aun! ¿No he dicho que llevo una semana muy disperso? :D ¿Para qué me recordarán que existe el XNALara? ^^U

Quote from: Drumpi on July 15, 2016, 04:43:02 PM
Después de ese paso lateral con el scroll tileado me he dado cuenta de que he empezado a hacer el equivalente en programación a divagar, y he perdido la ruta del proyecto. Me he dado cuenta cuando, a parte de notar que he bajado el ritmo, me vi pintando uno de los enemigos nuevos del nivel 4-3, algo que no iba a aparecer hasta la v1.4 ¡Primero tengo que llegar a la v1.3.1... digo v1.3.2!

Así que he cogido y he hecho una lista de las prioridades de las cosas que tengo que hacer para la v1.3.2, las que podrían ir pero que no son obligatorias (aunque sí que irían en la 1.4), y las que finalmente sólo aparecerán en la versión que tengo planteada como final (aunque se me están acumulando ideas que darían para una 1.5).
Ahora, aunque es un poco más peñazo porque las cosas obligatorias me exigen pintar, que es algo que es lento y tedioso en según qué cosas (especialmente cuando no tengo ninguna inspiración para seguir), ya tengo de nuevo puestos los ojos en la ruta a seguir.

Lo primero ha sido dejar el nuevo motor de scroll tileado, que por lo pronto es opcional para la v1.3.2. Ya está hecho y sé que es más rápido, pero hay cosas que corren más prisa que andar experimentando con el nivel más bajo del código del juego.
Y eso son los fondos y la presentación de los jefes. Lo de los fondos ya sabeis que llevan planeados desde la primera versión, y tengo hechos como la mitad (faltan el nivel 1-2, 1/4 del 3, no se si hacer alguno para el 4-1, y el fondo del nivel 4-2).
Y lo de las presentaciones de los jefes también llevaba bastante tiempo en la lista, sobre todo cuando más de uno me preguntaba por el nombre de alguno de ellos. Pues bien, hoy puedo anunciar que, oficialmente, todos los jefes de nivel ya tienen nombre. Ya lo tenían si los buscabas entre los FPGs, pero ahora podreis verlos antes de la batalla, cada uno con su propia animación, como por ejemplo:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3585)

...Aunque aun tengo que pulir algún detalle, porque el texto del último jefe lo he hecho del mismo color que el propio jefe y me he dado cuenta después de aplicarle varios filtros y retoques a la imágen, y ponerlo en el propio juego. Ahora cambiarle el color puede ser una tortura :S Espero que mis conocimientos de Potochof me ayuden una vez más.

Tengo que seguir creando fondos, probar el nuevo motor... ¡y probar la última versión de Bennu aun! ¿No he dicho que llevo una semana muy disperso? :D ¿Para qué me recordarán que existe el XNALara? ^^U

¡Maricona! ¡Te ha dado por trabajar, eh?  8)

Pinta muy bien. Me vas a hacer currar, que te veo venir. ::)

Yo por mi parte también me 'disperso' bastante. Sobre todo porque si no, me 'quemo', y entonces me da por hacer otra cosa.

Creo que soy más productivo programando lo que me va apeteciendo, e incluso metiendo un poco de pixel art de vez en cuando.

¡La cuestión es que la diversión no decaiga! ;)

¿Que me ha dado por trabajar? Pero si no he parado desde... A ver, el TFM fue desde Marzo del año pasado hasta ¿Noviembre o Diciembre? Luego le estuve dando un poco a sus mejoras, vino la Game Jam, y luego me puse con el Tilemap Editor 2... Bueno, con Bennu llevo desde Diciembre :D :D :D

Lo de hacerte currar ya te lo dije hace tiempo: hay un set de tiles nuevos, los fondos, algunos enemigos... si tienes ganas de currar, tu mismo, pero cuando veas lo que hay planeado para el nivel 4-3 lo flipas (yo estoy encantado con lo bonitos que están quedando, pero estoy viendo que puedo ampliar los subniveles 4-1 y 4-2 y convertirlos en verdaderos niveles (es lo que comentaba de versión 1.5, añadiendo un 5º nivel espacial).
También hay muchas posibilidades de que te lleves una parte de los donativos que genere el juego, todo depende de que me ponga a ello. También he contactado con Caleb, a ver si se anima con la música.

Sí, ir haciendo lo que te gusta es la mejor manera de ser productivo, y la mejor forma de que te salga algo genial, pero para eso debes haber planificado mínimamente lo que quieres hacer: no puedes hacer el 4º nivel y que te quede más fácil que el 2º :D Por eso tengo una lista de lo obligatorio para esta versión y otra de posibles, por si me apetece hacer un posible más que un obligatorio... pero sin perder de vista los obligatorios... ni los fallos que hay que arreglar antes de que la bola de nieve se descontrole :D

solo posteo para suscribirme y leer tol tocho algun dia

Jajaja, tampoco es tanto... ¿no?
Además, yo hace poco me leí el tocho anterior del Echo y del SBTime... dos veces. Y fue lo que me dio ganas de continuar.

Y nada, pues llevo dos días de tranqui, porque no me acuesto a mi hora, y de día no rindo ^^U
Pero bueno, algo hay que ir haciendo. Por ejemplo, ya puedo dar por terminado el fondo del nivel 3... o casi, poque la nave espacial no parece una nave espacial, pero creo que ha quedado bastante apañado para no tener ni pajolera idea de lo que iba a hacer o cómo hacerlo ^^U
Y sí, al final potochof me ha salvado la papeleta y he podido cambiar el color del nombre del último boss sin tener que rehacer todo el trabajo.

Hoy me lo he tomado con más tranquilidad, y he estado resolviendo algunos bugs, como que se podía activar la pausa durante los eventos de conseguir el arma o la expansión de energía. También la interfaz tenía algunos que hacía que no se pintasen todo el gráfico de los números. Es que les he estado dando sombra a los números para que se puedan ver cuando hay un fondo blanco, por ejemplo, la Luna del primer nivel... pero no se termina de ver bien, creo, y también es posible que les cambie el color y los haga más parecido a los de Fede... Sí, ya que ha aportado al juego, que sirva de simbiosis ¿no? :D

Y ya que estaba, he acortado el tiempo de ejecución de la secuencia que aparece tras morir. Creo que le he quitado entre 6 y 10 segundos de duración. No es mucho, pero para acortarla más tengo que hacer que se superpongan eventos en el tiempo o si no me voy a cargar el timing (y creo que lo he hecho acelerando alguna cosa).

Aun no sé qué hacer con el fondo 1-2, y me da pánico el 4-2. Tengo que terminar con la interfaz, repasar la IA de algunos enemigos que dan problemas, y cambiar el color de algunas cosas que ahora se quedan ocultas con los nuevos colores de fondo del nivel 3.
Por cierto, me han sugerido que el nivel de la ciudad le queda muy soso el fondo por haberlo hecho monocromático. ¿Vosotros qué decís? Teneis una vista previa en el mensaje 25 de este hilo, en la segunda página.
Y otra pregunta ¿Música durante la pausa? ¿sí, no o al 50% de su volúmen? ¿o tengo que añadir dicha opción al menú de configuración?

A dormir, que mañana tengo tareas.

Sigo esperando votaciones a las preguntas del último mensaje ^^U

Pero bueno, al lio.
Al final, estos días estoy de bajón total. Con el calor que ha hecho no he dormido bien y me paso el día zombi perdido. apenas le he dedicado tiempo a algunos gráficos que tenía pendientes.
Para empezar, les he puesto sombra a los números de la interfaz y la cosa ha mejorado mucho, pero no me convencen: algunos números se siguen confundiendo porque el número tapa a la sombra, y me estoy planteando hacerlos de color oscuro, para que resalten sobre el fondo blanco transparente. No me gusta la idea de añadirles un borde de color (más que nada, porque ya lo ha hecho Fede :P ).

Por otro lado, hoy me he atrevido a trabajar en la ilustración que va a ir al final de los créditos. Es una imágen de 320x240, y si ya una de 48x64 me tiene de los nervios porque no sé qué hacer... Total, que he cogido el Sketchbook Pro (que aun me dura la licencia por el Máster de videojuegos) y... al final me he tirado al Potochof viejo, que me da más herramientas. Bueno, que he cogido el potochof, he conectado la tableta gráfica, y he empezado a pintar como buenamente he podido. Como mi destreza es mínima (y peor con la tableta), he optado por darle un toque "a pinceladas" a lo que ya era un estilo retro de pocos colores (vamos, que quería hacerlo como las viejas imágenes flash, pero como no sé, he dejado los degradados de los bordes del pincel :D ) y de momento el resultado es aceptable, bastante cercano a lo que quería originalmente.
La pega es que no os puedo mostrar nada de lo que he hecho, porque es la recompensa por pasarse el juego. Lo vereis cuando esté terminado y metido tras los créditos. Y no, no voy a hacer excepciones (salvo a Fede, para que me de su opinión y por si se atreve a superarlo :D :D :D ).

Ya son menos las cosas que quedan para su lanzamiento, pero con la Crap Compo en marcha, y que en unos días cierro el ordenador durante un mes (ya casi por motivos de salud :P), no sé si me va a dar tiempo a publicarlo en los 10 días que me quedan. Si me pongo en plan Game Jam seguro que sale, pero ya he dicho que no duermo lo suficiente para ello, y estos días no me van a dejar trabajar a gusto.

:S :S :S

el potocherl? mas facil es el Gimp, muy sencillo de usar, sino usa el inkscape que pa graficos vectoriales es perfect...
por ultimo puedes sobornarme con promesas que nunca vas a cumplir...

hace tiempo hice un pequeño manual de como funciono:
(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3603)

Sí, en su momento intenté aprender Gimp, y cuando estoy en Linux es lo que uso, pero aun tengo mucho que aprender de él, y el acceso a las funciones de la presión del lápiz están demasiado escondidas para mi gusto. Si lo tuviese también instalado en Windows, seguramente lo usaría más, pero me he hecho a potochof y ya conozco el 30% de sus filtros y funciones básicas :D :D :D
Inkscape es una tarea pendiente que tengo desde hace años. Siempre he querido aprender a manejarlo, pero nunca me pongo a hacer tutoriales. Conozco las bases de algunas cosas, pero no tengo ni idea de las técnicas ni de qué herramienta necesito en cada momento.

Y no, esta imágen es demasiado personal como para encargársela a otro o travestirme para ello. Además, ya te mandé una lista de gráficos para otro juego, y aun sigo esperando :D :D :D

Woops, eso se perdió en el...
Incendio de titanic... <:D

No te preocupes, yo tengo copias de toda la documentación del proyecto y del material generado (sí, los 300MB de gráficos que me mandaste en su día, junto a los de Fede y las músicas de Caleb y PrinceMegahit) ¡MWUAHAHAHAHAHA!
:D :D :D

De momento vamos a dejar a Panta tranquilo volando con sus latas de Pantosa, al menos hasta que esta semana programe lo que pueda de la Crap Compo y del Echo, y me desintoxique de ordenador durante el mes de Agosto (aunque haya quien se empeñe en hacerme recaer :D ).

Por ahora, ya he empezado a contar las cosas que me quedan pendientes de la lista y he reducido la misma a 5 gráficos.
Hoy he estado retocando la interfaz, que al final puede que con la sombra en los números baste. He cogido algunas de las ideas de Fede, y las he adaptado a cómo habría cambiado yo mis gráficos siguiendo mi estilo; es un poco difícil de entender, pero como ejemplo, vereis en la siguiente imágen que les he puesto color a las letras de "energy" y "w. exp", como hizo Fede, pero en lugar de pintarles un marco bonito y hacer que resalte, he mantenido mi linea minimalista y sólo he cambiado el color a las letras y les he dado sombra, igual que a los números, para que se vean mejor. También he cambiado el color del fondo de la interfaz, porque no podía usar blanco sobre blanco, y aunque me hubiese gustado ponerle un tono oscuro, quería que se pudiera seguir viendo el nivel por detrás.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3607)

También me he puesto en plan flojeras, y he resuelto dos o tres bugs que tenía en el código, incluyendo un comportamiento errático en los guerrilleros, que les daba por mirar en sentido contrario a donde estaba Echo cuando saltaban o caían mientras lo perseguían.
Pero la pregunta importante es ¿He terminado con esa imágen final, tan importante y difícil de hacer?...
... No, por desgracia. Hoy le he puesto la segunda capa más difícil de hacer a la imágen. La primera era el pelo de Echo (sí, podreis ver al chavalín sin el casco), que tenía miedo de que no me saliera, pero al final ha quedado bien, no perfecto, pero es un muy buen resultado. Y la de hoy implicaba un trozo de tela arrugada, algo que nunca (que yo recuerde) he tenido que pintar, más allá de replicar una imágen (soy "decente" copiando dibujos, pero aun me queda mucho que aprender para decir que sé manejar el lápiz).
Lo bueno es que la parte principal de la imágen está acabada, junto con un par de accesorios. Lo único que puedo decir es que me ha quedado más "kawaiiiii"... ^^U Mañana tengo que escalar una imágen para usarla de referencia en una de las dos últimas capas. La última, por supuesto, es el cartelito de "the end", que he decidido hacer a mano en lugar de usar una fuente.

De las otras imágenes que me quedan, una es el dichoso fondo del nivel 1-2, que sigo sin saber cómo envejecer y manchar unos ladrillos tan grandes, y luego son los dos fondos del nivel 4, que aun no sé a ciencia cierta qué voy a hacer. La quinta es un foreground, que si ya dije que un background con el scroll de Bennu se me iba a resentir en Wiz, este va con flag=4 incluido o alpha menor :S
A ver si antes del próximo viernes puedo subir esta versión a GameJolt, y notificarlo en los foros de GP32Spain y ¿sigue existiendo GP32X, el foro inglés?

El juego para la Crap Compo, lo veo difícil, la verdad :(

PD: Fede, he cambiado algunos de tus gráficos ¡MWAHAHAHAHA!
Nah, que con los nuevos fondos del nivel 3, las balas blancas de los guerrilleros quedaban ocultas en las brumas, y les he puesto el mismo tono gris oscuro que a los míos. Al fin y al cabo, es de los pocos gráficos que no cambiaste en los enemigos ^^U Las explosiones de las minas tuyas sí se ven, las mías no, y las he hecho radiactivas :P

Bueno, la cosa avanza despacio pero avanza:
El problema de hacer gráficos es que como no es lo mío, debo estar fresco para ponerme a ello, porque si tengo que pintar algo aleatorio pero que tenga algo de sentido, por ejemplo, las manchas de unas piedras a modo de ladrillos, acabo repitiendo patrones, acumulando colores en una zona, o desperdigándolos de forma poco agradable a la vista.
Así, que cuando tuve esta pared pintada así...

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3609)

Tuve que dejarla para después de la hora de la comida... y la hora de la siesta no ayuda, sobre todo con este calor ^^U
En fin, aunque en esa imágen la veais a medias, la pared ya está terminada. Quedan 3 gráficos, 2 si descuento el fondo de la fase 4-1 y dejo ese azul cielo caluroso y brillante, o 3 si finalmente añado 2 planos de scroll al fondo del nivel 4-2, que podría quedar interesante ¿Habeis visto el fondo en el Indiana Jones de SNES, la fase subterránea, en el Templo Maldito? Algo así, pero con menos corazones arrancados.

También me he puesto un poco con el código porque la interfaz seguía teniendo fallos: algunos números se tapaban entre sí, o cubrían el fondo sobre el que se pintaba, y tenía que ajustar dos sets de gráficos en lugar de uno (no le iba a hacer la faena a Fede de tener que cambiar sus números). Así que nada, ajustando al pixel para dos sets de números. Se me han ido dos horas tranquilamente en eso.

Y ahora a seguir con mi pesadilla. Como no soy artista, crear un fondo no es algo tan sencillo como pueda parecer, y más si quiero mantener el estilo retro del juego. En algún fondo y en el epílogo del juego me he permitido la licencia de tirar de potochof para darle un toque diferente, y aun así no me he pasado añadiendo colores o detalles, y he podido tirar de tableta.
Ahora estoy haciendo un fondo con Paint (que empieza a ser un "pain"). Después de muchos cálculos he podido estimar que lo que veis más adelante es el tamaño mínimo que le podía poner para darle un poco de scroll a la cosa. También he calculado un fondo grande, como el del nivel 3, sin que se pase de memoria (ese fondo ya ocupa más de medio Mega, y no hay ni un sólo nivel que ocupe más de 80KB... gráficos aparte), pero quedaría mejor si pudiera hacer un fondo cíclico horizontalmente, y eso me obligaría a crear un nuevo scroll a los tres que ya he hecho para los fondos. No es que sea una tarea ardua que me vaya a llevar días, usando copia/pega podría estar listo en cuestión de minutos, pero me lo tengo que pensar muy bien, ver si merece la pena el esfuerzo, y si ya con este fondo me vale:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3611)

Aun lo tengo que llenar de estalactitas, cristales como los del nivel, meterle reflejos al agua... mucho trabajo pendiente, y dudo que lo pueda terminar mañana. A ver si el martes es el último día, y si no, a ver si lo puedo intercalar con la programación del motor del juego de la crap compo (ya os digo que es lo más ambicioso que me he propuesto, al menos para una crap compo, y un colega me va a echar una mano a la vez que aprende a programar... o eso creo).

Lo que sí voy a necesitar será un betatester, que cuando acabe la versión 1.3.2 del Echo, me lo pueda probar (preferiblemente en Wiz) para ver que todo funciona y poder subirlo lo antes posible a GameJolt. Como dije es sólo una versión puente, de cómo debería haber quedado para el concurso del Hamster... mas unos cuantos toquecillos extra. Después de vacaciones, de la Crap Compo, y de evaluar si cierto juego aun no desvelado sobre un malvado ser submarino debería ser re-enfocado (porque lo he probado hoy y es de lo más difícil que he diseñado en videojuegos hasta la fecha), empezará el verdadero "road to 1.4".

Buenas nochzzzzzz...........

Vale, pues no ha quedado mal el fondo. No sé si justifica el uso del scroll, pues apenas se desplaza, pero sumándole los efectos del agua que ya tenía el nivel, las decoraciones y demás, el nivel ha ganado muchos enteros. Sigo pensando que debería modificar los tiles lisos añadiéndoles alguna textura, pero si ahora mismo no tengo claro si quiero añadir otra capa al scroll de este nivel, hacer lo otro no tiene mucho sentido ^^U

En teoría sólo quedaría el foreground del primer nivel, pero tengo mis dudas con el difuminado, no sé si la escala de blanco a negro con transparencias se va a ver feo y además de flag de transparencia tendría que usar flag aditivo. El rendimiento se cae por momentos. Menos mal que es opcional y se puede desactivar en el menú de opciones (para wiz, tanto fondos como foregrounds vienen desactivados por defecto).

Pero me han surgido dos problemas:
El primero es bastante serio, y es que en cierta parte del nivel hay pinchos bajo el agua. Tal como lo tengo programado, los tiles de agua aparecen porque en el mapa de tiles se han definido ciertos tiles especiales, que al ser detectados por el motor (mediante una modificación al mismo), generan el tile de suelo correspondiente, y un proceso de "agua" (un proceso transparente que actúa como un tile). Pero los pinchos se consideran ya como un tile especial de tipo "enemigo", y no puedo poner dos tiles especiales en la misma posición (no, al menos, hasta que esté el nuevo motor, consiga un rendimiento bueno, y pueda añadir una segunda capa). He tenido una idea muy loca que podría funcionar, pero si no, lo voy a dejar así, pendiente de arreglos para la 1.4.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3614)

El otro problema es el de añadir tiles especiales que se rompen bajo el peso de Echo. Estaba previsto para esta versión, y tengo el código hecho en otro proyecto. La pega es crear los gráficos de animación de rotura, posiblemente crear partículas (de nuevo, problemas de rendimiento), y ciertas partes del código requerirían de una nueva variable para el prota, que para ser limpios, debería añadirse al código del mismo (sí, revisar las 2000 líneas para sustituir ciertas constantes por esta variable). Eso significa que ni de cachondeo termino esto para el viernes.

Otra cosa que estoy evaluando es si añadir en esta versión la cuenta atrás del oxígeno restante de cuando Echo está bajo el agua. Había pensado en que en el momento en que se quedase sin aire, comenzase a perder energía hasta morir, y así resucitar en el mismo punto donde ha muerto, como siempre. Pero como le estoy dando vueltas a añadir checkpoints para volver a la vida en caso de morir por caidas (no, no se puede morir así en todo el juego, y mira que he habido sitios donde me hubiera gustado hacerlo), no lo tengo muy claro, porque si ahora hago que resucites "in situ" y más adelante lo cambio para que vayas para atrás, mucha gente se me va a tirar al cuello :S

Bueno, pues las opiniones son bienvenidas. Y lo mismo las ofertas de betatesting, que con tanto programar y dibujar no me van a quedar fuerzas para más de una partida completa.
A ver si me acuesto, que mañana me toca limpiar una cocina de camping antes de seguir programando... o sea, dibujando.

No sé si es el calor, que tengo la cabeza a 100 por hora o qué, no puedo dormir.
Total, como me han dado las 5 de la mañana despierto y a las 9 o así me iban a despertar para limpiar la cocina, pues me he puesto a programar. No me gusta hacerlo porque a estas horas suelo cometer muchos errores, y muy tontos, y luego me paso el día siguiente corrigiendo esos fallos (aparte de que me paso el día zombie). No son horas en las que pueda pensar con claridad, y los códigos medianamente complicados se me hacen imposibles de programar.

Pero al final ya tengo los scrolls de primer plano programados... bueno, EL scroll de primer plano (aunque lo repita en los niveles 1-1, 1-2 y 1-3).

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3616)

La imágen en cuestión la he hecho en unos 15-25 minutos... creo, no he mirado el reloj, gracias a potochof y la herramienta "emborronar con el dedo". Es muy útil para dar efectos de nubes difusas y niebla. Combinado con la herramienta "offset" he podido crear una imágen para el scroll cíclico.
Al final tenía razón, y el uso del flag de transparencia dejaba ver los tonos grises, así que lo he mezclado con el flag aditivo, haciendo que sea totalmente inviable en Wiz... supongo, porque aun no me he puesto a pasar archivos a la SD (y tampoco hay ganas). Es más, aunque el efecto mola y me encanta, los jugadores lo van a mantener desactivado por la falta de visibilidad. Bueno, la opción está ahí, ya es cuestión de preferencias.

Escribir el código no ha sido complicado, ya que es un copia y pega del scroll de fondo, con la salvedad de que el primer scroll no es el 0. Eso me ha hecho recordar que los scrolls de fondo siempre empiezan usando el scroll 0, y no hay forma de seleccionar el que se quiera, y va a ser un problema en cuando cambie el motor, así que he usado la última neurona que me quedaba más o menos despierta, y he conseguido (creo) estabecer el primer scroll a usar mediante una constante.
Al menos parece que no he roto nada.
Lo difícil ha sido dar con la Z adecuada para el scroll. En la imagen se ve que el foreground tapa el icono del arma seleccionada, pero eso ya está arreglado. Es que no me apetecía hacer otra captura, porque me he tenido que pasar las tres primeras pantallas unas 4 veces haciendo pruebas.

Pues sólo eso, estoy intentando rellenar tiempo hasta que den las 9 para no dormirme. A ver qué consigo hacer hoy, porque según la lista queda ese plano de scroll que dije hace unas horas que no iba a hacer, y lo de los tiles de agua sobre los pinchos, que con las neuronas a medio gas, imposible programar nada.

¡Ah! Me acabo de dar cuenta de que tenía una lista con los FPG que he ido añadiendo y modificando en la carpeta de gráficos de Fede. La he actualizado con todos los fondos y los cambios de estas semanas. Espero no olvidarme de borrarla en la versión final y mandársela al interesado.

En fin... pues... ya está saliendo el sol... Tengo sed...
...
Me aburro

Pues nada, otra vez escribiendo ^^U

Pues ya creo que está todo, así que he ido preparando la "versión release", tanto para Windows, Wiz y Caanoo... Eeeeeh, sí, debería preparar otra para Linux, pero primero tengo que ver si me funciona la última versión de Bennu en mi Kubuntu ^^U
He solucionado algunos bugs de última hora, tras hacer algunas pruebas mínimas en Wiz.

¿Cómo se comporta el juego en la negrita? Bueno, para empezar debo decir que usando el Pollux_set, es decir, overclockeando la consola a 750MHz, no se aprecia una diferencia notable entre usar Bennu r265 y la r335, va más o menos igual de suave y sigue teniendo los parones esos cada 16 pixels. Es curioso que el frameskip, en lugar de ayudar, hace lo contrario, porque cuando el scroll no se mueve va todo suave a sus 50 fps, pero en cuanto hay scroll, se nota el frameskip, e incluso parece que los tirones son aun más fuertes. Quizás ayude en los momentos con más carga de enemigos.
Eso sí, si subo la velocidad a 800MHz ya no son tan molestos los tirones y la primera pantalla se juega de lujo.

Pero bueno ¿y las novedades? eso es harina de otro costal. Si ya era complicado el funcionamiento a velocidad normal, en cuanto se añaden los fondos la cosa empeora. Al principio parecía que todo iba bien: el scroll se movía de forma fluida, Echo se desplazaba elegantemente a casi 50fps... pero comenzó a desplazarse el scroll tileado y aquello cayó. No es una caida muy drástica, pasaría de 50fps a 40 y pocos fps, pero sé que se va a resentir en las zonas más pobladas del juego.
Pero como le añadamos el scroll de primer plano, apaga y vámonos. Ese flag de transparencia mas el aditivo pone el juego, siendo generosos, apenas por encima del 50% de su velocidad real :S Ni aun añadiendo un frame de frameskip se salva la cosa (y con dos ya queda feo).

Y esto son las primeras impresiones, falta probar el juego entero y la versión de Caanoo. En portátiles ya estaba previsto que la cosa no pintaba bien, y por eso el nuevo motor de scroll tileado... pero en PC se juegs de lujo (salvo en mi portátil, por alguna razón la diagonal abajo a la derecha me bloquea la tecla de disparo, algo que no pasa en un teclado de ordenador normal).

Respecto al nuevo motor, sí, es MUY fácil añadirlo al Echo. Es "sustituir" los ficheros de código del antiguo por el nuevo, cambiar las llamadas (porque no le he puesto el mismo nombre al proceso que lo ejecuta), modificar un par de variables que no existían en el viejo, y eliminar la optimización de mapas (porque con este motor no dirve de nada).
¿Pero qué pasa? que el motor antiguo, al usar procesos en lugar de gráficos, permitía usar tiles de cualquier tamaño, y en más de una ocasión he usado tiles de 32x16, 16x32 o 32x32 en los mapas, y con el nuevo es OBLIGATORIO que el tamaño de los tiles sea, pues eso, de 16x16 (incluso los más pequeños).
Así que si quiero usar el nuevo motor, además de cambiar el código, debo modificar los tiles, los FPG y los mapas, y no se hace en un par de horas... y ahora mismo estoy KO.

Pues nada, quien se quiera apuntar al programa de betatesting, que avise, me mande un correo (si no lo tengo ya) y me diga qué versiones desea probar (PC, Wiz y caanoo; para Linux se puede usar la de Windows, cambiando el .bat y el runtime). Lo ideal es recibir los resultados de las pruebas el jueves o el viernes, que me de tiempo a corregir cosas sueltas y subirlo a GameJolt (si además me mandais algunas capturas sin marco, trabajo que me ahorrareis) antes del Sábado, que el Domingo ya me es imposible.

Un saludo. Cerrando sesión...

muy buena la transparencia de las nubes, si haces el grafico con alpha, te deberia funcionar sin el flag adictivo... simplemente usando el alpha del grafico...

Lo he probado, pero no, el reborde oscuro tirando a negro se queda transparente y oscurece esas zonas, queda fatal. Mañana a ver si te puedo hacer una captura para que veas como queda.
La otra opción sería hacer la niebla en 2 colores, pero dado que aun así el rendimiento en Wiz es penoso, lo dejo como "virguería gráfica" para la versión de PC:P

Nota mental: añadir a la lista de cosas para la v1.4 filtros 2x, 3x y 4x para PC usando scale_resolution.

Quote from: Drumpi on July 27, 2016, 12:23:25 AM
Lo he probado, pero no, el reborde oscuro tirando a negro se queda transparente y oscurece esas zonas, queda fatal. Mañana a ver si te puedo hacer una captura para que veas como queda.
La otra opción sería hacer la niebla en 2 colores, pero dado que aun así el rendimiento en Wiz es penoso, lo dejo como "virguería gráfica" para la versión de PC:P

Nota mental: añadir a la lista de cosas para la v1.4 filtros 2x, 3x y 4x para PC usando scale_resolution.

imagino que eso te pasa porque usas negro de fondo...

Obviamente. Y dada la escala cromática que uso en el nivel, elegir cualquier color haría que se notase y se vería igual o peor.
Y por eso uso el negro, para poder usar luego el flag aditivo.

¿Nadie para betatesting? ^^U

Bueno, pues en teoría mañana es el gran día... el primero de ellos.
No perdamos de vista que el hilo se llama "Echo v1.4: road to season two", y mañana lo que lanzo es la v1.3.2, que básicamente es un retoque estético de la v1.3.
Y sí, el "season two" que se añadió en la portada para el concurso del Hamster, ha desaparecido hasta nuevo aviso :D

Mientras que la v1.4 y final va a tener (al menos) 4 niveles completos, con bugfix gordos, etc, etc. En esta va a haber retoques más o menos mínimos por la parte visible.
De momento puedo adelantaros que sí, los escenarios ya tienen fondos, opcionales, pero los tienen. Incluso algunos de ellos hasta tienen foregrounds que no se van a poder usar en Wiz. Luego, los jefes de nivel... o jefes a secas, porque están esparcidos por todo el juego, por fin van a dar a conocer sus nombres, para que los maldigais a gusto. Y ese indicador para coger objetos, por fin.
Pero lo que no se ve es todo ese código reordenado. Yoquesecuantas mil líneas que han pasado de 14 ficheros de código a ¿112? Linux se debe estar liando ¿tantos? :S

Lo importante es que me he quitado algunas de las espinas que tenía clavadas desde hace tiempo. Aun me quedan unas cuantas como esos tiles de suelos que se rompen, el indicador de oxígeno, mejorar el redimiento o cambiar el sistema de salvado, que se quedan para la vuelta de vacaciones, junto con el final del nivel 4 y el inicio del nivel 2.

Los ficheros están subidos a GameJolt desde ayer, tras localizar tres bugs graves (todos relacionados con no haber copiado FPGs a la carpeta de Fede), pero no se van a activar hasta que me asegure de que no hay ningún bug extra suelto. Ya he estado juegando al juego entero una vez, sacando snapshots, e incluso improvisando algún gráfico de presentación porque no tengo los programas con los que hice algunos de los originales y GJ se empeña en que deben tener un tamaño 4 veces superior a los que tiene el juego en sí.
Un colega también se ha presentado voluntario para probarlo, y voy a reunirme con él esta tarde para hablar de ello.

En fin, stay tunned. Mañana me toca anunciar la salida oficial aquí, en GP32spain y en Facebook, mientras preparo las maletas para olvidarme durante un mes del wifi, los teclados y de los BEGIN-END que me llevan machacando 11 meses más de 8 horas diarias sin fines de semana que valgan :D

PD: ¡¡¡PIXEL!!! Responde a los privis.

Te acompaño en el sentimiento y mándame las ansiadas betas, je je

Hola de nuevo desde este pequeño diario de desarrollo.

No, no he vuelto a retomar el proyecto, al menos no de forma oficial (se retomará, pero ahora mismo estoy decidiendo qué camino tomar).
Pero sí que le he estado echando un vistacillo para meter el nuevo motor de scroll tileado, ese que pintaba sobre un gráfico que se ponía en un scroll de Bennu, y que se suponía que me iba a ahorrar todos esos procesos tiles que me ralentizaban tanto la Wiz. He hecho una prueba preliminar, incluyendo el scroll de una forma un poco tosca (tosca porque me aparecen tiles que no deben por todas partes, al no usar tiles de 16x16 en todos los sitios) y ha sido frustrante.

Al principio parecía que había ganado algo de suavidad, casi imperceptible, pero a poco que me iba adentrando en el juego, la pantalla se volvía más caótica (no pasa nada, estaba previsto) y todo iba cada vez más lento. Ahora no estoy seguro de si iba mejor antes con el scroll por procesos o ahora con un scroll más :S

He intentado mirar a través del profiler qué era lo que más recursos me estaba comiendo, pero parece que eso ya no existe. Parece que hay una relación directa entre el número de enemigos y cómo se ralentiza el juego, y hay algo que no me cuadra, porque creo recordar que hice que los enemigos que se alejasen de pantalla, desaparecieran y volvieran al mapa visible como datos. No sé qué es lo que hace que el juego vaya tan lento, porque incluso con el doble de procesos de cuando tenía el scroll por procesos parecía que se movía a la misma velocidad.

¿Puede ser que la detección de durezas sea un agujero negro de recursos? No debería porque a pesar de lo largo que es el código, se lee sólo una décima parte del mismo gracias a las sentencias SWITCH ¿Será la detección de colisiones? Tenía restringido el uso de collision a cuando el prota estaba cerca del enemigo, pero no sé si puedo reducirlo más sin que haya problemas, o sustituirlo por collision_box sin que haya quejas de que las colisiones no son muy reales. ¿Debería hacer un collision_box y despues, en caso afirmativo, un collision? ¿No se perdería aun más rendimiento?

Puedo reducir algunos cálculos si hago que se consulte una vez dos datos de la variable global info_prota.tilex, y se guarden en una variable privada (dichas variables se consultan en 160 lineas del proceso, pero en realidad son menos de 25 veces por frame), pero no creo que eso tenga mucho impacto en la velocidad.

Es que no me cuadra que cada 16 pixels que se avance haya un pequeño parón, el nuevo motor debería haber eliminado eso, porque teóricamente era lo que más recursos consumía, y ahora resulta que no, y ahora no sé si volver al motor anterior y probar otra cosa, o dejar este nuevo y arreglar los FPGs y los mapas para que funcionen correctamente con él (que es un trabajo que me llevaría como una semana o poco más dependiendo de la cantidad de problemas que de el testeo).

Si alguien tiene respuestas, serán bien recibidas. Especialmente sobre el profiler.

Mi opinión es que los juegos tienen un principio y un fin. No mola ver una y otra vez el mismo juego con ligeros toques de imagen (independientemente de drásticos retoques de errores.) Al final creo que aburre.
Mi consejo es que des por cerrado ya el juego. Y se quede tal cual está para siempre. Los fallos de un juego son los que hacen únicos al juego.

¿Que hubiera pasado del mortal kombat II si hubieran quitado el fallo de agacharte y saltar para atrás cuando llega el enemigo? un mortal kombat IIb con eso arreglado a lo mejor hasta se hubiera aceptado. pero y si hubieran segido con el IIc todo igual quitando el fallo de saokan de saltarle una y otra vez con patada y no dejar que deje de cubrise?

En fin, mirando para el caso contrario, que le pasa al street figther II, que si II plus, que si II ', que si II '2 alfa plus ..., ahora salto y salto y salto y me salgo por arriba y aparezco por abajo, ahora hecho mil bolas, ahora me mezclo entre mis bolas que no me dan....

En fin, en mi opinión deberías cerrar ya echo 1 y empezar con echo 2, mismos personajes, nuevas fases no repetidas nuevas armas y opciones nuevos enemigos, que lleve la esencia de echo, pero ya en otro nivel.

Si te das cuenta todas las compañias hacen eso y es lo que vende y engancha, lo unico que perdura son los persojanes nada mas y a veces ni eso ( FF :) ).
Diablo - Diablo II - Diablo III
Herores of migth and magic I - Herores of migth and magic II -Herores of migth and magic III - Herores of migth and magic IV
bueno por poner unos ejemplos. :D

Quizas la alternativa de repetir mismo juego con mejoras gráficas y nuevas fases podría guardarse para pasados unos años hacer un remake. :D caso del remake de abu simbel profanation para PC

Con esto no quiero decir que no prosigas, los resultados molan, a la vista está, es solo mi opinión personal.
Lo veo como mucho tiempo invertido en lo mismo que al final no será tan agradecido como se espera. Lo poco nuevo que aporta el juego no va a merecer la pena al gran trabajo realizado en ello.

Es probable, pero un juego con solo dos niveles me parece poca cosa :D
No es que el juego sea corto, que no lo es, sino que tenía planeado tres niveles en lugar de dos, y ya tengo empezado el cuarto sin haber tocado el segundo ^^U

Ya digo que no sería mala idea cerrar el Echo con los dos primeros niveles y empezar una segunda parte con otros dos niveles pero hay varias razones para hacerlo así:
- La jugabilidad de los dos nuevos niveles está entre lo ligeramente diferente y lo radicalmente distinto, y más que una segunda parte parecería un spin-off. El cuarto nivel tenía pensado que fuera un laberinto de puertas porque hice un juego hace años que molaba así, pero dado el feedback negativo que han tenido estos tipos de nivel a lo largo de los años (Crítico de la nostalgia: Bebe's Kids), creo que voy a optar más por un desarrollo tipo sandbox con minimisiones. Eso nos lleva al segundo punto.
- El objetivo del Echo siempre ha sido, en realidad, crear un motor para realizar el juego que tendría que haber sido: una aventura de plataformas, disparos y exploración, a medio camino entre Super Metroid y Cave Story. Poco a poco le he ido añadiendo cosas, lo he aprovechado en otros proyectos (he ido mejorando mi forma de programar) y lo del cuarto nivel me va a ayudar a preparar la parte de diálogos y cutscenes.
- Quiero aprovecharlo para subirlo una vez completo a GameJolt, y cobrar por él lo que la gente quiera pagar (aunque sea cero). Y si la cosa pinta bién, usarlo como muestra para crear un kickstarter para hacer esa aventura que digo: "Doggy!!!". En realidad, poca gente fuera del círculo de GP32spain, GP32x.com, Fenix y BennuGD conocen el juego, y si voy a expandir su difusión, quiero que esté lo más completo que pueda.

Pero no es algo que me obsesione. Ya lo dije en otro hilo, estoy dispuesto a seguir con otro proyecto si me llama la atención, ya sea en Bennu, PixTudio, Unity, Android o HTML5. Sólo me he puesto con el Echo porque lo tenía aparcado desde hace tres o cuatro años, y he usado parte de su código en varios juegos, y quería reaprovechar lo que añadí en esos otros proyectos aquí, pero estaba tan mal organizado que he tenido que hacer limpieza.
Ten en cuenta que la primera versión se desarrolló en tres meses (y uno fue para corregir y portar las detecciones de tiles de durezas), y contando los últimos 4 meses en plan tranquilo, no le habré dedicado más de un año neto.

Quiero intentar corregir los fallos que comento en el anterior mensaje porque es un problema gordo en Wiz, peor que las ralentizaciones en Sonic 2006, y a partir de ahí ya todo va rodado: terminar los pocos tiles que me faltan del nivel 4, desarrollar los del nivel 2, crear las nuevas físicas que necesito para el nivel 2, hacer unos pocos enemigos nuevos, aprender un poco de IA, y liarme a diseñar niveles, que es lo mío (y no descarto hacer modificaciones a los que ya estaban hechos, a ver si hago el nivel 3 un poco más interesante).

Por cierto, que el ejemplo que pones de SF2, Capcom estuvo vendiendo el mismo juego año tras año con ciertas mejoras, y poca gente se quejaba (al menos en mis círculos), y hoy día es lo que se hace con los paquetes de actualizaciones, DLCs, ediciones GotY... La diferencia es que yo no cobro, no tengo tanto feedback, ni tengo un equipo para añadir todo el contenido extra a lo largo de un único año :D :D :D

Le he cogido ganas al código, sólo un poco, porque quería corregir de una vez esos pequeños fallos de control que tiene el juego.
Para empezar, ese bug que hace que, a veces, al tocar el techo, perdiese toda la velocidad lateral. Lo he aislado y he impedido que eso suceda, pero ahora, si golpeas diagonalmente la esquina de un techo, hay un pequeño "teletransporte"... pero también es cierto que el control mejora muchísimo en los saltos, y que ha corregido el problema de entrar en espacios donde el suelo y el techo sólo tenían un tile de altura: ahora es 10 veces más fácil entrar.
Sigo buscando el "teletransporte" que te pega a las paredes en las caidas, o por qué Echo rebota al tocar el suelo tras un salto o una caida. Vale que esto último es más realista pero me está dando problemas con los saltos, y eso es malo para el jugador.

Hoy me he puesto a hacer un poquillo de limpieza en el código del prota. Sí, quedan cosas por limpiar, aunque más que limpieza es una corrección de un error de novato. Lo que he hecho ha sido cambiar varios valores numéricos por constantes, concretamente los valores que indican cuánto se puede "pegar" echo a las paredes y al techo, dado que Echo no mide 16x16 pixels. Esto tiene más que ver con el nivel 2, en el que me estoy planteando seriamente sustituir los tiles de 16x16 por otros de 24x24 ¿Por qué? Porque necesito que los sprites sean un poco más grandes; se podría usar 16x16, pero creo que quedaría mejor si puedo tener algunos pixels extra... Es que no quiero desvelar de qué se trata.

Lo que ya no tengo más remedio que desvelar es lo que quiero hacer en el nivel 4, porque mi cerebro simétrico no me deja decidir (de nuevo). Tengo dos opciones:
- Que el nivel sea un laberinto de puertas, como pensé originalmente. Sé que no es una mecánica muy popular, que es muy frustrante avanzar a la derecha para que una puerta te mande a la izquierda, el no saber hacia dónde ir, por dónde estás, si avanzas o retrocedes... Y sin embargo, en los 90 diseñé "Super Mario Door", un juego basado en "Super Mario World" con esta mecánica y era bastante divertido en mi opinión.
- Que el nivel sea un sandbox de plataformas. La idea sería plagar el nivel de mini misiones, con gente con la que hablar para que te den tareas, indicaciones, te abran caminos, etc, todas destinadas a que obtengas la llave final para enfrentarte al jefe del nivel (bueno, y alguna misión extra para conseguir objetos o armas nuevas). También cambiaría la mecánica global del juego sin perder la esencia de plataformas, exploración y combate, y me permitiría desarrollar el sistema de diálogos y eventos controlados por la máquina para "Doggy!!!" (que es un juego de aventuras, plagado de este tipo de escenas).

Bueno, aquí sí que necesito vuestra opinión. ¿Que os atrae más?

Ami lo que echa del hecho un poco para atrás es un poco lo laberíntico del juego; echo de menos que haya tres o cuatro pantallas de inicio que sean facilongas y con eso irse calentando

Yo me apunto a idea 2 también.
Y quiero probar ya el juego, deja alguna descarga ya >:(

Pero Futu ¿Llegaste a superar la parte de las columnas o te quedaste ahí? porque hasta esa parte casi todo es muy "straight forward" y nada complicado (a menos que dejes enemigos vivos que vayan detrás de ti).
Se me está pasando por la cabeza hacer un quinto nivel basado en el espacio, que no sé si sería lineal como Freddy Hardest o con minimisiones tipo Alien 3 de SNES, pero primero voy a centrarme en los dos que faltan que no son moco de pavo.

DCelso: pero si la descarga ya existe. La puse antes de irme de vacaciones en Gamejolt, y la semana pasada lo resubí a openhandhelds para Wiz y Caanoo:
http://gamejolt.com/games/the-amazing-adventures-of-echo/170481
Más detalles en el mensaje 49 y en http://forum.bennugd.org/index.php?topic=4308.0

A los demás, sigo esperando vuestros votos.

ostras, pues vi a ve.

¿que coño es un game jolt y como se puntua? :D

Creo que te tienes que registrar para puntuar y comentar.
Aparte de eso, es una página de juegos hechos por aficionados, tanto terminados como en desarrollo, gratuitos (aunque hace poco han añadido la posibilidad de vender los juegos) y en la que se pueden crear páginas de concursos para que participe quien quiera. Es donde se suelen subir los juegos de la Familiar Game Jam (la próxima es el fin de semana del cambio horario).

Bueno, sigo esperando opiniones sobre qué estilo de juego os apetece más en el cuarto nivel, si laberinto de puertas o pseudo-sandbox.
Lo cierto es que me llama más la atención el segundo estilo, casi estoy pensando usar el laberinto de puertas para el juego paperactivo de este año, y además conmemoro los 25 años de uno de mis juegos favoritos, "Super Mario World", haciendo "Super Mario Door 2: la puerta de las 7 llaves y media" (título provisional :D ).
Aunque estoy pensando que voy a tener problemas con los enemigos, porque actualmente la información de estos se almacena dentro de los mapas de tiles, y se eliminan del mapa a medida que se generan los procesos (aunque se restituyen si siguen vivos al alejarte demasiado). Esto significa que cada enemigo sólo se puede matar una vez en cada partida, no hay forma de "regenerarlos", y aunque es una práctica que nunca me ha gustado (lo de volver sobre tus pasos un poco y volver a encontrarte al enemigo que has matado diez segundos antes al volver a avanzar), es necesaria en un nivel que tienes que ir recorriendo una y otra vez... salvo que sea el objetivo del juego (como en Metroid II, donde tenías que eliminar todos los metroides del juego).

Pero bueno, los problemas de uno en uno.

Como sabeis, se ha estado celebrando la RetroBarcelona (a estas horas debe estar a punto de cerrar), y Ryo Suzuki me había pedido permiso para portar el Echo a Dreamcast. Aunque se lo concedí, no pudo hacerlo a tiempo, y yo no tengo ni DC ni entorno para desarrollar en ella, así que se ha pospuesto hasta que vuelva.
Gracias a L1nk3rn3l he podido hacer avances en la preparación de un "entorno de desarrollo" (a base de releases oficiales de Bennu y emulador de DC), pero no hasta el punto de tener algo funcionando más allá de un "hola mundo".

¿Y a qué viene este rollo? pues simplemente a que he añadido código específico para DC: un set_mode específico adaptado a su resolución, una inicialización de teclas por defecto para los valores del mando de DC, y la posibilidad de añadir al principio de las rutas de carga de recursos (FPG, PNG, WAV...) el famoso prefijo "/dc/".

Hoy estoy en modo "piloto automático" porque no he dormido bien, y me he puesto a depurar código.
He conseguido aislar el código que hacía que Echo rebotase. El problema venía de usar "resolution". Al recolocar a Echo, no tenía en cuenta los "decimales" y en ocasiones lo colocaba 6 décimas de pixel por encima del suelo, y al actuar la gravedad, que desplaza a Echo 0'2 pixels*frame, hacía que el prota volviera a entrar en modo "caida".
Le he dado tres soluciones al problema, y es curioso cómo en cada una de ellas reducía el número de cálculos de 12 operaciones (que incluía una operación módulo), a 9 y finalmente a 4 o 5 (usando sólo sumas, restas y multiplicaciones).

Actualmente estoy intentando resolver el teletransporte contra las paredes. He localizado el origen del problema, pero estoy demasiado ZZZZZ como para ver por qué aparecen esos valores y qué solución se le puede dar.
Lo malo es que sólo los más obsesivos del control van a notar la mejora que sale de todo esto. Para los demás no va a parecer gran cosa, pero os aseguro de que yo estoy viendo muchísimos cambios a la hora de jugar, para mejor, para mucho mejor: el botón de salto falla sólo un 10% de lo que lo hacía antes (sigue fallando en rampas :( ), los saltos con techo bajo ya no son una lotería saber si vas a llegar o no (va a ser culpa del jugador en un 95%), y entrar en esos pasillos estrechos es muchísimo más fácil.

Cuando acabe, tendré que trasladar todos estos cambios a los enemigos, y luego a los otros juegos que han usado el mismo motor de detección de durezas (aunque sólo se me vienen dos juegos a la cabeza: Montezuma, y el otro que nunca fue lanzado).
En fin, sigo esperando opiniones sobre el nivel 4 ¿laberinto de puertas o sandbox con misiones?

¿y por que no los tres? lol

nos vemos en retrosevilla, guiño guiño

misiones, pixa. misiones. mola mas.

¿conoces super paper mario?

Quote from: Futublock on October 09, 2016, 06:36:15 PM
¿y por que no los tres? lol

nos vemos en retrosevilla, guiño guiño

¿Qué tres? yo sólo he dicho dos (y deja algún estilo de juego para otras fases, si las hago :D).
¿Qué retrosevilla? ¿Cuándo es?
¿Y estás ligando conmigo? Como se entere Fede...

Quote from: DCelso on October 09, 2016, 07:01:04 PM
misiones, pixa. misiones. mola mas.

¿conoces super paper mario?

Lo conozco... pero no lo he jugado :( Es una saga que me gusta desde N64 y nunca he podido jugarla porque los juegos son carísimos. De momento me conformo con "Mario & Luigi: paper Jam bros" (qué peñazo conseguir los logros de batalla).
¿Por? ¿No me irás a ponerme a hacer giros 3D a la cámara? :D

yo me pasé el de wii. está chulo, porque es un estilo a tu juego, plataformas plan misiones, llaves y con diferentes herramientas para acceder a los distintos niveles.
tiene cosas chulas que a lo mejor te puedan dar ideas para el tuyo. No solo lo del giro 3d, que tambien  mola, sino lo de  los pixelitos o algunos super porderes.

http://www.retro-sevilla.com Llevaré una camiseta de  marciantos

Pues nada, a ver si lo veo barato y lo pruebo, porque gracias a los especuladores, a que Nintendo no rebaja sus juegos ni consolas hasta que se les ve el plumero, y que las tiendas de segunda mano están subiendo los precios para que hagas uso de sus oficinas de préstamos, es un sinsentido. ¡Imposible ver el de GC por menos de 40€ cuando dicen que es casi un refrito "HD" del primero!

Quote from: Futublock on October 10, 2016, 07:49:47 AM
http://www.retro-sevilla.com Llevaré una camiseta de  marciantos

Este viernes, lo que se celebra es la presentación del evento. Aun no hay fecha para el evento principal. Se va a anunciar allí. :P

vaya tela, del 21 al 23, pa la semana que viene...
(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3681)

Bien hecho, los cambios de cara a Dreamcast. Lo conseguiremos correr ahí también!!

Sería genial que pudiera estar para la Retro Sevilla de una forma u otra -PC o DC-, que por otro lado, me gustaría ir. Hace ahora muchos años que no voy a mi querida Andalucía!!

Okis, te pasaré los fuentes esta noche o en cuanto pueda, porque ahora mismo estoy corrigiendo bugs del movimiento de Echo, y tengo un porrón de SAYs por todo el código (bueno, por los 6 includes del prota). Si lo conseguimos será la versión con mejor control de todas las que hay :D Hoy he corregido el "teletransporte" que le hacía pegarse a las paredes cuando caía (otra vez por culpa de resolution), ahora intento evitar un salto que pega ocasionalmente en las rampas.
Eso sí, me tienes que pasar, aunque sean los binarios, del runtime de DC que andas usando tu, a ver si consigo llegar, al menos, a cómo tienes tu el código. A partir de ahí ya podría investigar qué leches pasa para que se cuelgue.

 :o
ninguna acepción es masculina.

http://dle.rae.es/?id=IYZhVtl

Según esta, sí:
https://es.wikipedia.org/wiki/Elipsis_(figura_ret%C3%B3rica)

Los ficheros fuentes son masculinos. Si se dice "las fuentes" pensamos directamente en Comic Sans, Arial, Windings... A menos que tu nivel friki sea inferior al 3, en cuyo caso estarías pensando en un paseo por el parque y agua cayendo :P

He estado dándole y está muy bien, la verdad.

También es bastante difícil o estoy perdiendo facultades:

(http://www.segasaturno.com/portal/files/images/2/echo.jpg)

Me ha matado el primer boss!!

mola.  :)

Pequeño tip del día: Guippo es vulnerable en la cabeza, los disparos hacen el doble de daño, pero ojo, la cola sólo recibe la mitad ¿Y qué importa la cola en un punto tan inaccesible? Bueno, en realidad...
No es difícil, sólo es que tiene mucha energía. Sus tres ataques son fácilmente esquivables. Es sólo tener paciencia.

Recuerda que puedes usar el set de gráficos STYLISH si no te gustan los míos desde el menu de configuración, y que la Leaf Blade es difícil de conseguir por algo :D

Guippo es fácil, lo difícil es no dejarse algo de mientras

Mola el juego, no recordaba que fuera tan dificil, ma costao pillarle el truco al dragón. Parecía invulnerable.  ;D

Antes de que se me hunda el hilo entre los proyectos de DCelso, voy a dar un pequeño update.

Parece que el estar medio zombie me convierte en el mejor buscador de bugs de mi mismo. Por lo general, con la cabeza despejada, no aguanto más de media hora, una como máximo, antes de aburrirme y dejar de buscar. Si tengo sueño, parece que pongo el piloto automático y no me importa mirar cualquier variable, gastar el tiempo probando cada pequeña cosa, ir una a una, hasta que doy con la tecla.
Hoy ha caido otro de los fallos de jugabilidad del prota: en algunas ocasiones, al bajar una rampa, hacía un pequeño teletransporte hacia arriba, de unos 15 pixels, que duraba entre 1 y 3 frames. He descubierto el origen del bug, y sí, otra vez es culpa de las imprecisiones de usar resolution y mis prisas por no verificar cada parte del código.
Como resultado del arreglo, ya se pueden bajar las rampas casi con toda suavidad, aun hay unos microsegundos en los que el prota se despega del suelo y no funciona el salto, pero parece que sólo ocurre al inicio de la rampa o cuando se va a muy baja velocidad. Como efecto secundario, los saltos en rampa son un 50% más efectivos, ya que anteriormente se daba el caso de que la mitad de las veces que se intentaba saltar no se podía, porque el personaje estaba en el aire.
No lo he testeado a fondo, pero sí que ha ganado estabilidad.

Y es que es importante acabar con estos bugs. No sé si lo he dicho, pero luego esto va a copiarse a los enemigos, a otro código dentro del juego, y luego a los demás juegos que he hecho (Montezuma, ¿SBTime?, el otro que no se lanzó...).

Aparte, la cosa va más lenta porque tengo que intentar lograr que funcione el port a Dreamcast, y tengo que terminar un juego paperactivo antes del 15 del mes que viene.
Como me va a ser imposible terminar el "Superpilotos 4" (un juego basado en cuando me iba con las bicis con los colegas a patrullar por el barrio, convertido en un Metroid con superbicis con habilidades únicas), he decidido rescatar un juego bastante sencillo de hacer en su día, y que me va a servir para dos propósitos: comprobar la viabilidad de los laberintos de puertas que quería implantar en el nivel 4 del Echo, y rendir homenaje a un juego que este año celebra su 25 aniversario. Estoy desarrollando "Super Mario Door 2".
Lo cierto es que me siento bastante cómodo desarrollando niveles al estilo SMW. Por lo general me tiro unos días intentando adaptarme al estilo del nivel y a dibujar sus gráficos, pero en apenas tres ratos ya tengo la mitad del nivel tutorial hecho. Hay previstos cuatro niveles, pero sólo dos son obligatorios: el tutorial y el gran castillo de Bowser (el original sólo contaba con un nivel, y se superaba en 15 minutos o así).

En fin, poco a poco. Mientras le dedique un rato a cada cosa, en algún momento se terminarán. :)
Necesito dormir.

Quote from: Drumpi on October 20, 2016, 12:24:29 AM
Antes de que se me hunda el hilo entre los proyectos de DCelso, voy a dar un pequeño update.

...

XDDDDDDDDDDDDDDD

A mi me pasa muy mucho que le doy a saltar y no salta.

Y me fastidia un huevo en saltos cortos y estrechos.

A lo mejor era culpa de esto.

Voy a ver.

En los pasos estrechos, el problema es otro, que ya comenté varios mensajes atrás.
Y no busques la actualización porque no la hay ^^U Esto es un worklog, nada más. Voy diciendo los cambios que hago al código, pero no se lanzan hasta que la versión está completa.

Pero bueno, si hay mucha insistencia, puedo mandar por correo una alpha en forma de DCB para sustituir el de la última versión (la v1.3.2), pero sólo por ser vosotros. Ya digo que sólo se han arreglado tres o cuatro bugs en el control del personaje (aparte del código extra para DC).

Bueno, esto es un DCB compilado con la última versión del Echo para pruebas en DC, en exclusiva para Ryo Suzuki. No intentéis descargarlo porque viene protegido con contraseña (¿a que soy malvado?).
Tampoco os perdeis gran cosa, porque sólo tiene código para DC y los bugs corregidos. He tenido un parón por otros proyectos, como la Familiar GameJam, y motivs varios, como diseñar el "level select" que me hace falta para testear el rendimiento en Wiz, dado que en mi última prueba, sustituir el scroll tileado de tile por proceso a capa por proceso no ha mejorado casi nada el rendimiento, y temo que el problema venga de la detección de durezas de los enemigos: es un trozo de código que, en teoría, no debería consumir gran cosa por todos los IF y switch que contiene, pero sus más de 1000 líneas a cada uno de los 20 o 30 enemigos que se pueden acumular (más si la gente pasa de eliminarlos) suponen una sobrecarga... supuestamente. Eso es lo que tengo que mirar, quitar los enemigos e ir a una de esas zonas que se ralentiza a lo bestia, pero es algún lugar intermedio del nivel 1-3 o 1-4, y eso es, como mínimo, 10 minutos de juego hasta llegar allí (y usando una de mis partidas guardadas, claro).

¿y ese avatar?

Recibido jefe, mañana lo pruebo que hoy es ya muy tarde.

A ver que says dice la Dreamcast a la consola del PC por BBA y descubrimos dónde se cuelga exactamente y qué está haciendo cuando se quedaba negro ahí freeze tras el menú, press start y demás....

Ah ¿pero conseguiste hacer funcionar el juego en la consola? Pensé que sólo lo habías hecho funcionar en el emulador (yo todavía ni eso ^^U).
Los Says sólo van a llegar hasta el menú principal. A partir de ahí... no lo he mirado, la verdad, porque hoy tenía clase y apenas te he podido descomentar los says que puse para probarlo yo en el emulador ^^U
Bueno, ya me dices lo que te sale y partiremos de ahí.

Bueno, a falta de una DC, voy a intentar seguir el desarrollo normal y, eventualmente, ir haciendo arreglos en función de los avances que se hagan por parte de Ryo e Indiket.
Esto es un consejo personal: nunca intenteis un port en una consola que no teneis a menos que sepais exactamente lo que estais haciendo o tengais mucho tiempo y alguien que te haga las pruebas en "tiempo real". Si todo funciona a la primera, irá de lujo, pero si no, podeis tener problemas insalvables, o que precisan de tantas prueba-error que tardaríais meses si teneis que andar con correos electrónicos o programas de subversion.

Bueno, de momento, escribo porque he hecho un pequeño receso en los proyectos "gobaug" y "montezuma" y me he puesto un rato con este proyecto.
Y ha sido eso, un rato. Ya más o menos tengo diseñado cómo va a ser el menú de selección de nivel, y me he puesto a programar. No recordaba que ya existía un proceso "level_select", que usaba para inicializar una serie de datos y ejecutar el nuevo nivel para el concurso del Hamster... bueno, sabía que existía, pero no que tenía ese nombre y que estaba guardado donde está. esto me ha dejado un poco descolocado porque hacía ya tiempo que no tocaba el código, pero pasado el susto inicial, y la búsqueda de las variables que iba a necesitar, empecé a programar... hasta que vi que necesitaba nuevos gráficos.
Por lo que hoy, he escrito 8 líneas, y he hecho unos 15 gráficos, que no son ni la mitad de los que necesito, pero bueno, como siempre digo, "mientras se vaya avanzando un poco en el proyecto, en algún momento se terminará".

Sé que me llamais pesado por no acabar ya con Echo, y soy el primero que quiero darle carpetazo y ponerme con algún RPG, el juego de carreras en Unity o yo que se (incluso "Doggy!!!", la secuela en plan aventura), pero quiero dejar el Echo cerrado completando el nivel que está a medias, pero necesito antes que funcione en Wiz, que es la plataforma destino al fin y al cabo. Podría dejarlo sólo para PC, me ahorraría muchísimo trabajo, pero su resolución nativa es la que es: 320x240, y no se puede cambiar.

Hoy le he dado otro empujón al proyecto. He conseguido mantener este menú de selección de niveles aislado del resto del código... más o menos.
El primer problema que he tenido es que el fichero de guardado que tenía no estaba bien, sólo había almacenado la mitad de los datos que necesitaba, así que he tenido que modificarlo con un editor hexadecimal. Con esto y la consola de bennu he ido comprobando que todos los apartados del menú funcionan correctamente.
Sin embargo se me está complicando por momentos. Hay cosas fáciles de hacer, como seleccionar las vidas. Otras no tanto, como la energía que quieres tener al inicio de la partida, porque dependerá de cuántos items de expansión de energía hayas encontrado en el juego y cuánta energía máxima quieres usar (sí, se podrá emular que no has cogido ninguna expansión de energía en el nivel 3, o empezar la partida como si los hubieras encontrado todos).
Ahora me enfrento a la selección de nivel al que quieres jugar, y es lo más complicado de todo: hay 4 niveles, pero el 2 no está hecho, cada nivel tiene un número diferente de subniveles, y según el nivel o subnivel, puedes empezar desde un checkpoint o no. No es tan sencillo como seleccionar 3 números y hala, a jugar, hay que restingir la selección a lo que existe y a lo que el jugador ha desbloqueado.

Si le dedico unas 5 horas lo terminaré... o algo más, porque quiero usar capturas de los niveles para el menú, para que quede bonito, y luego añadir un fondo monocromático con scroll.
Y se suponía que esto iba a ser sencillo y rápido ^^U

En fin, espero poder acabarlo rápido y así tener otra herramienta de desarrollo. Luego no sé si ponerme a añadir los checkpoints o ponerme con las optimizaciones de Wiz. Lo suyo serían los checkpoints, para poder acceder rápidamente a esas partes conflictivas.
Y cada vez veo más sensato dividir el nivel 4 en tres niveles diferentes. No quería, para ir terminando pronto, pero es que me gusta la idea de un nivel egipcio a lo Indiana Jones, la fase de las cavernas con más agua y caminos alternativos, y hacer el último nivel como lo planteé hace tiempo, una miniaventura con misiones en un nivel abierto a la exploración (con los checkpoints sería posible, ya que puedes guardar y seguir en otro momento).

...ya, ya, Gobaug, sí, lo tengo pendiente, pero cuando las ganas te vienen, hay que aprovechar :P

pero si no dije na...

¡PUES DEBERÍAS!

:D :D :D Nah, cuando terminemos de ajustar el prota y los enemigos, podremos seguir con el gobaug... más que nada porque ahora mismo no sé qué se necesita programar ^^U

Mientras tanto, puedo decir que el proyecto Echo cuenta ya oficialmente con un selector de niveles. No, no está acabado, aun necesita de algunos detalles gráficos para dejarlo bonito, como mostrar el nombre o algún snapshot del nivel, o tener un scroll de fondo. Lo que importa es que la parte funcional está hecha y ya lo he probado... un poco. He podido saltar al nivel que he querido, aunque eso sí, el level select es sólo para jugar UN UNICO NIVEL. Para jugar una partida y seguir donde se quede uno ya existen las partidas salvadas... aunque quiero eliminar la limitación de 6 partidas, y la obligación de guardar en el mismo slot en el que se empezó, pero vayamos paso a paso.

Lo que tengo que hacer ahora son los checkpoints, que no es una tarea tan sencilla como pueda parecer a simple vista. No es añadir un tile especial que, al pulsar abajo, guarde la partida. Debo hacer que el play_level los identifique como posible punto de inicio, evitar que los elimine como los otros puntos de inicio que ya existen, evitar que salven en modo level_select... bueno, una serie de operaciones extra. Luego podré usar el level_select para empezar en esa posición y ver por qué leches se ralentiza tanto en Wiz aun usando el nuevo motor de scroll tileado.

Y tengo que ir dejando el hueco al nivel 2 dentro del juego, que ya va siendo hora.
Y también ver cómo implemento las plataformas móviles, que también va siendo hora de hacer alguna :D

Bueno, pues ya está todo más o menos listo para recibir los checkpoints, la duda es ¿Qué leches uso de checkpoint?
Mi primera idea era poner un banderín de color triste/oscuro, iluminado por una luz desde abajo (para que resalte), que se volviese de color vivo al cogerlo, pero creo que está demasiado visto.
Luego he pensado en una espada en su pedestal, en plan épico, pero ¿entenderán los jugadores que eso es un punto de salvado?
Y ya no sé si poner un orbe, una gema o qué (admito ideas).

Mientras, le he dedicado un ratillo más al selector de nivel, y... no quería poner nada, pero me puede el ansia, y os muestro una versión casi acabada del menú, para que os de envidia :D

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3855)

Y bueno, eso es todo, de momento. Quizás necesite un voluntario para hacer de betatester, alguien que sea capaz de pasarse el juego entero del tirón, porque ahora mismo no garantizo que las partidas salvadas funcionen (aunque ni las he tocado). Es simplemente para ver que no me he cargado nada del modo de juego normal y que las fases se siguen reproduciendo una detrás de otra.

pon un boton de recreativa :D

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?...

Una pokeparada.

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

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

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

Por cierto, malas noticias:

(http://www.segasaturno.com/portal/files/images/2/consola.jpg)

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...

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

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.

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

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 :)

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?

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.

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.

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!!

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í).

Gracias, lo pruebo en cuanto tenga un hueco!

Si le quitamos los fx casi mejor, que te conozco y te crees que la Dreamcast tiene un buffer muy grande de sonido y pesaban un montón si no recuerdo mal ;D

Te paso en cuanto lo tenga un screenshot de lo que dice la consola del dc-load_ip!!

¡Pero si el juego completo, sin comprimir, ocupa 10'8MB! Lo más pesado son las músicas, y la más gorda son 4'3MB :D :D :D

Sound RAM tiene solo 2 megas... para todo!!

P.D: Para música podemos usar CDDA que no ocupa nada y funciona bien.

1'26MB todos los SFX, y no se cargan todos (de hecho, creo recordar que las armas sólo cargan el SFX del nivel en el que están, no los tres... creo) :P

Vale, necesito vuestra opinión, porque no quiero dejar esto más tiempo estancado.

El juego se diseñó para Wiz, y funciona decentemente bien, salvo zonas donde se acumulan una cantidad ingente de enemigos, que yo llamo "zonas de recarga" (porque están para que el jugador pueda recuperar vida y experiencia del arma, ya que no hay otra forma de hacerlo).

Pero para hacer que funcione bien debo reescribir el motor de detección de durezas por algo más sencillo, y es un trabajo del copón que no sé ni por dónde comenzar. Sé que debería mirar las durezas a nivel de pixel, empezando por los pies, y después las esquinas para no atravesar paredes o suelo, pero cuanto más lo pienso, peor lo veo porque veo más y más condicionantes, más ver lo que había antes, etc :S

Y aun tengo que meter, sí o sí, la segunda capa de tiles por detrás de Echo, porque hay una parte de nivel 4-2 donde debería verse agua y pinchos en el mismo tile, y no puedo poner la información de ambas cosas sin crear un tile específico. Y aun así, hay algunas cosas más que ganarían estéticamente con una segunda capa (¿verdad, Fede? :D ).

Esos son los tres problemas graves que tengo ahora mismo con la versión de Wiz. Si pudiera solucionarlos, podría seguir sin problemas. Todos se resumen en lo mismo: la detección de durezas de los enemigos es demasiado exigente en la portátil. Y si no puedo solucinar eso, las alternativas serían eliminar las zonas de recargas y crear mapas diferenciados para Wiz y PC (con una y dos capas respectivamente), pero no resolverían el problema.

Así que vuelvo a lo mismo de mi último mensaje:
- Cierro el juego con dos niveles (eliminando el nivel 4 por completo) para Wiz, y creo una especie de versión DX para PC con los 4 (o 6) niveles que va a tener el juego.
- Me olvido por completo de Wiz y tiro para adelante con lo planeado para PC.
- Tiro para adelante, intentando mantener la compatibilidad aunque se arrastre en Wiz.
- O merece la pena intentar salvar la versión de Wiz reescribiendo el motor de detección de durezas.

Lo ideal sería la última opción, pero voy a necesitar mucha ayuda con eso. Aun así me gustaría saber qué pensais vosotros, sobre todo porque esto afecta también al posible port a DC, que no sé hasta qué punto es potente para mover lo que ya hay.
Please, ¡¡consejos!!

Estoy de acuerdo que la ideal sería la ultima opción, pero tal vez es un despropósito en relación costo/beneficio. Para mi lo mejor es que trates de ir mejorando en general el juego, y lo que puedas lo vayas portando a la versión de wiz, pero sin romperte la cabeza porque ande fluido en esa consolita. Y aproveches en agregar mejoras, y features nuevos, que eso es lo mas divertido de hacer, jaja.

TL;DR: Voto por la 1.

Bueno, mientras sigo leyendo opiniones (que de momento parece que gana el seguir el proyecto, pero sin dedicarle demasiado esfuerzo a la Wiz), me gustaría saber si, Ryo Suziki, probaste la última versión que te mandé, para saber qué salida te dio la consola, a ver si podemos aislar el comando problemático en el menú principal.

Me ha sorprendido ver que hay bastante gente interesada en que se abandone el proyecto totalmente para Wiz y Caanoo. Por suerte, parece que la opción más razonable es la de seguir el desarrollo normal, intentando mantener la velocidad en las portátiles dentro de lo posible. No lo digo sólo por los votos, también por el razonamiento que me han ido dando en los comentarios.

Bueno, por ahora ando bastante liado para concentrar mis esfuerzos en... algo. Entre las clases de inglés, el curso de PHP (que por suerte, acabo esta semana o la siguiente, si me lío demasiado) y que me han llamado de un equipo de desarrollo de videojuegos de la universidad para trabajar como programador freelance en un pequeño proyecto, voy a andar justito de tiempo para hacer algo.
No, lo de la universidad de momento no va demasiado en serio. Es decir, sí que me han ofrecido un puesto de programador, pero aun no hay nada atado :P
(Ryu, no me he olvidado de ti, sigo esperando. Cuando puedas, me miras eso, ¿vale? ;) )

Bueno, y para seguir con esta racha de noticias buenas ¡estoy desarrollando Bitstrips 2! :D
No, simplemente quiero que cojais vuestras pajaritas (porque no os veo con ganas de poneros el esmoquin) porque hoy venimos de presentación. Se ha hecho de rogar, pero por fin, tras mes y pico en mi disco duro, y más de seis años después del inicio del proyecto que comenzó teniendo su nombre, os presento al único, al inigualable, al más fiel escudero del superhéroe de siete años, y esperemos que la parte principal del guión de una secuela de aventuras...

DOGGY!!!

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3909)

Aquí unos cuantos concept arts, con Doggy mirando a ambos lados (no, no hay espejado horizontal) y jugando con Echo.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=3910)

¿Qué os parece? ¿A que es una monada? :D Bueno, en "the amazing adventures of Echo" no va a ser un personaje jugable, ni va a ir siguiendo a Echo (porque eso tardaría eones en programarlo para que funcione de forma medio decente). De momento va a servir como "checkpoint" y permitirá salvar la partida.
Ya está implementado lo del "checkpoint", y se puede ir a su posición desde el selector de niveles, pero aun no he implementado lo de salvar.
También va a servir con un propósito más oscuro: ahora que ya existen puntos a los que volver, podré implementar la muerte por caidas o aplastamientos. Por si no os habíais fijado, la única forma de morir en el juego es por agotar la energía del prota, y esto era porque si morías cayendo, como al resucitar lo hacías en el mismo punto donde morías, entraba en un bucle de muerte-vida hasta el "game over". Como la única referencia guardada del mapa era el inicio del nivel, me sabía fatal tener que repetir el nivel entero porque se te haya deslizado mal el dedo durante un salto (especialmente en el nivel 3, "2012: alien invasion"). Ahora ya puedo añadir checkpoints donde quiera (más o menos) y sustituir hordas de enemigos por algo más mortal MWAHAHAHAHAHAHA!!!

Volviendo a Doggy, pues eso, de momento es un item más, pero tengo previsto que haga algo más en el consabido y largo tiempo olvidado "nivel 2". Me reservo la sorpresa, aunque ya os aviso que es una Drumpilocura en estado puro :)

Pues nada, ya podeis pasar a acariciarlo, mimarlo y dar vuestra opinión. Aun no sé si le gustan más los huesos o las galletas de perro, tengo que darle una vuelta a eso ^^U

Quote from: Drumpi on January 27, 2017, 01:10:40 AM
me gustaría saber si, Ryo Suziki, probaste la última versión que te mandé, para saber qué salida te dio la consola, a ver si podemos aislar el comando problemático en el menú principal.

Discúlpame que he estado muy ocupado y estos días no pasé por el foro.

No funcionaba, ni siquiera arrabancaba esta vez y sin tirar un error así que pueda ayudarnos.

Tengo que tener la foto con el móvil que le hice, pero es curioso que ni siquiera llegaba a la anterior versión.

A ver qué podemos hacer. Pasa si trato de hacer ports que casi siempre peta en Dreamcast, es bastante frustrante.


Ah! Me encanta Doggy!!

Bueno, se que ha pasado tiempo, y que llevo sin escribir en el foro... buf, pero hoy me ha dado por escribir código, y he decidido simplificar la detección de durezas de los enemigos a su mínima expresión. Así, las 1000 lineas las he reducido a:

         switch (enem_p_dir)
            case 1: p_libre = enem_dur[0][2]; end
            case 2: p_libre = enem_dur[1][2]; end
            case 3: p_libre = enem_dur[2][2]; end
            case 4: p_libre = enem_dur[0][1]; end
            case 5: p_libre = 0; end
            case 6: p_libre = enem_dur[2][1]; end
            case 7: p_libre = enem_dur[0][0]; end
            case 8: p_libre = enem_dur[1][0]; end
            case 9: p_libre = enem_dur[2][0]; end
         end //Switch
         
         if (p_libre > 0 && p_libre < 150)
            enem_mover_h = 0;
            vel_horiz = 0;
            vel_vert = 0;
         end
         
         x3 += vel_horiz;   //actualizamos posición
         y3 += vel_vert;
         
         enem_offsx = (x3 / resolution3) % id_tscroll.tmapa[0].ancho_tile;
         enem_offsy = (y3 / resolution3) % id_tscroll.tmapa[0].alto_tile;

LOL. Bueno, pues suponía que la detección de durezas se llevaba gran parte del rendimiento de Wiz y... ¡no!. Con este código, la zona con más enemigos del juego iba arrastrándose. WTF?
Luego me di una vuelta por versiones de prueba que, por suerte, tenía guardadas. No me acuerdo de qué hacían, pero tras un par de pruebas he supuesto qué era. Había una que iba casi a la velocidad adecuada, y he notado dos diferencias respecto a lo normal: usaba el motor de scroll tileado por gráfico (que ya dije que no mejoraba el rendimiento gran cosa) y los enemigos no colisionaban con nada. Bueno, la detección de durezas sí que funcionaba perfectamente, me refiero a la parte que usa "collision".

        //*************************
        //  ZONA DE IMPACTOS
        //*************************
        if (exists(info_prota.id_prota))
            //impacto con las balas
            if ((abs(x - info_prota.id_prota.x) < 350) && (abs(y - info_prota.id_prota.y) < 350))
                temp = collision(type normal_shot);
                while (temp != 0)
                    energia -= temp.energia;
                    //say("enemigo (" + itoa(enem_tx) + "," + itoa(enem_ty) + "): energía: " + itoa(energia));
                    //say("el disparo tenía energia: " + itoa(temp.energia));
                    temp.energia = 0;
                    if ((mi_temblor != 0) && exists(mi_temblor))
                        mi_temblor.energia = 3;
                    else
                        mi_temblor = enem_temblor(id, 3);
                    end
                    temp = collision(type normal_shot);
                end
            end
           
            if ((abs(x - info_prota.id_prota.x) < 50) && (abs(y - info_prota.id_prota.y) < 50))
                temp = collision(type espadazo);
                if ((temp != 0) && (temp != temp_espada))
                    energia -= temp.energia;
                    if ((mi_temblor != 0) && exists(mi_temblor))
                        mi_temblor.energia = 3;
                    else
                        mi_temblor = enem_temblor(id, 3);
                    end
                    temp_espada = temp;
                end
            end
               
            if (energia <= 0) break; end
       
            //impacto con el prota
            if ((abs(x - info_prota.id_prota.x) < 50) && (abs(y - info_prota.id_prota.y) < 50))
                if (collision(info_prota.id_prota))
                    info_prota.dano_id = id;
                    info_prota.dano_energia = 3;
                    info_prota.dano_exp = 3;
                    if (info_prota.id_prota.x2 > x2)
                  info_prota.dano_vel_horiz = 20;
                    else
                  info_prota.dano_vel_horiz = -20;
                    end
                end
            end
        end

Este parece ser el código problemático. Intenté reducir el impacto de collision limitando sus comprobaciones a la zona en la que Echo pudiera afectarles. La zona más grande es la de los disparos, porque su radio de acción es enorme, pero la espaza y el prota se limitan a unos pocos pixels. Aun así, parece ser que con 15 enemigos en pantalla, el uso de collision es demasiado.
Había pensado cambiar la comprobación de distancia por collision_box, y en caso de que la hubiera, entonces aplicar collision, pero no sé hasta qué punto mejoraría eso el rendimiento, ya que box collision tiene en cuenta size, angle y los bordes transparentes del gráfico.

Si alguien tiene experiencia con el asunto, le ruego que me cuente qué es lo que puedo hacer.

Hoy me quería haber puesto a añadir una segunda capa a los mapas existentes, o a modificar por completo el mapa del nivel 4-2, pero se me ha venido este código de las durezas, así que la segunda temporada de Echo tendrá que esperar un poco :D

No era collision_box() justamente mas eficiente que collision()?

O vos decis que la ganancia de rendimiento sería poca para justificar el uso, y que necesitarías algo del estilo collision_simple_box() que sea muy eficiente como para justificar el uso?

Amigo Gecko, esa es la pregunta del millón.
Teóricamente, Box_collision es mucho más eficiente que el cálculo de distancias en código Bennu, por aquello de que está una capa por debajo, tiene acceso a más hardware, y que si uso get_id para obtener una lista de procesos con un enemigo, cuando el segundo haga lo mismo no va a poder porque get_id no se reinicia hasta el siguiente frame (creo). En ese caso tendría que crear una función que obtuviera todas las IDs de enemigos, disparos, prota, etc, e hiciera las mediciones de distancia, marcase los procesos con posibilidad de colisión, y que luego estos hicieran la llamada a collision... un lío, vamos.

Hay que tener en cuenta que para hayar la distancia entre dos procesos hay que hacer la resta de sus componentes, sacar el valor absoluto y compararlo con un valor. Vamos algo como:
if ((abs(x - info_prota.id_prota.x) < 350) && (abs(y - info_prota.id_prota.y) < 350))

A lo que hay que sumar el AND y el if. Ocho operaciones que calculo que contarán como dieciseis en código C.
Si tan complicado es hacerlo así, normal que collision gaste tantísimos recursos en cuanto hay una cantidad interesante de enemigos y balas en pantalla. Y necesito ese rendimiento, ya no sólo para que vaya fluido en Wiz, es que quiero pasar el nivel 2 al 4, y convertir el 2 en un run'n'gun estilo "Gunstar Heroes" o algo así... aunque ya estuve barajando lo de eliminar las zonas infestadas de enemigos a cambio de enemigos más gordos y convertir a Doggy en estaciones de recarga.

En fin, eso, que estoy abierto a sugerencias para mejorar la eficiencia de las colisiones, que quiero meter mapas de dos capas de tiles.

Bueno, hoy he podido sustituir ese "if" por collision_box en todos los procesos enemigos. El resultado es que sigue habiendo ralentizaciones bastante graves en zonas cargadas de enemigos. Me atrevería a decir, a falta de una comparativa más exhaustiva, que en los momentos de mucha carga va más lento, pero en los de menos carga va más rápido. Repito, es una valoración a ojo y de memoria, necesito recompilar una versión "limpia" de la 1.3.3 para compararla con esta, y probar añadiendo el scroll tileado pintando en mapa, pero no auguro conseguir un rendimiento suave en Wiz ni por asomo.

Mi intención es esa, probar estas dos posibles mejoras, y si el conjunto no logra un aumento notable en el rendimiento, vuelvo al código que tenía antes y sigo el desarrollo como iba.
Por cierto, me temo que voy a hacer algo que no me gusta nada: ¿os acordais de los dos sub-niveles que se presentaron en la última versión? Pues creo que los voy a descartar en favor de dos niveles completos cada uno. Seguramente pueda mantener el nivel de Egipto como intro para una fase con pirámides, laberintos, momias (que fumen o no aun no lo sé), pero la de la cueva no, ya que es autocontenida (tiene inicio, nudo y desenlace, por aquello de que aparece arena al principio y se llega al final del scroll de fondo; está muy bien como lo que era, una transición entre Egipto y lo que vendrá después, pero creo que un nivel de cuevas y agua puede dar mucho más, si añado un poco de claustrofobia a la mezcla).
No me gusta descartar niveles, tal vez lo esconda por ahí, pero he hecho niveles subterráneos con mucha más chicha, y si le añado las plataformas que se rompen, las escaleras y las plataformas móviles, puede mejorar mucho... Es más, creo que por eso el nivel subterráneo de FenixLand era mejor, a pesar de ser mucho más corto y lento.

¡Arg! Acabo de acordarme de que tengo que arreglar un bug por el que Echo no para de rebotar en el suelo cando está bajo el agua. Ya lo solucioné fuera de ella (un problema con resolution) y creía que servía para el agua, pero por lo visto, en algo me equivoqué al hacer los cálculos... Y eso lleva más tiempo del que me gustaría :(

bueno , pero descargas donde ?

;D

pero, tienes tiempo? malandrin

Quote from: l1nk3rn3l on November 25, 2017, 02:26:10 AM
bueno , pero descargas donde ?

;D

Bueno, dado que estoy haciendo pruebas para mejorar el rendimiento, obviamente no hay descargas hasta que tenga una versión que considere "definitiva" (es decir, la que mejor rendimiento da) y estable.
Lo cierto es que no hay muchas cosas nuevas desde la 1.3.2, que es la última que se liberó para el concurso del Hamster, creo. se puede descargar desde mi página de GameJolt:
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481
Según mis apuntes, desde entonces, sólo ha habido resolución de bugs en el control (que es importante, desde luego, pero sólo le interesa a desarrolladores, y aun queda solucionar otro que hace que sea injugable bajo el agua) e intentos de port a Dreamcast (sin éxito por no se qué  problema con el port). Para el resto de los mortales, la única diferencia que hay es que completé el menú del "level select" (aun me queda por añadir un fondo, pero vamos...).
Si soluciono lo del bug, puedo plantearme enviar betas privadas para testeo antes de ponerme en serio con material nuevo, pero no quiero lanzar nuevas versiones hasta haber completado los nuevos niveles 3 y 4.

Quote from: Futu-block on November 25, 2017, 10:24:50 AM
pero, tienes tiempo? malandrin

No, no suelo tenerlo. Me he tirado un mes y medio a todo gas terminando un juego para el 25º aniversario de mis juegos en papel (a ver si saco fotos), y desde que estoy trabajando me siento agobiado con tanto programar y tanta prisa. Esta semana he conseguido terminar parte del proyecto y he podido bajar las revoluciones y programar cosas más sencillas, así que he podido sacar unas horitas para relajarme, y me ha dado por ponerme con el Echo (hace dos meses me relajaba con Blender :D).

Voy a intentar ver qué leches pasa con el bug ese bajo el agua. Creía haber solucionado esto reemplazando el movimiento por "pixels" a "posiciones de resolution". La última vez fueron dos horas de búsqueda y captura, y un dolor de cabeza, y hoy quería abrir mi editor de mapas de tiles para empezar a excavar túneles, pero lo primero es lo primero (y como me harte, me enchufo al Batman Arkham City).
Si os lo preguntais, el port a DC queda suspendido hasta que me compre una DC y pueda hacer una traza del programa en condiciones aceptables. Si por cada prueba tengo que esperar una semana por una respuesta o tener tiempo  para hacer otra, me van a dar las uvas, pero del 2020.

¡Ah! Hablando de ports: acabo de probar el collision_box con el supuestamente mejorado scroll tileado y los resultados son idénticos, o casi. No hay nada que hacer, el rendimiento cae en cuanto hay un buen puñado de enemigos en pantalla. No es que se vuelva injugable, sólo lento, pero ya me criticaron bastante cuando se producía un parón cada 16 pixels, así que, como ya comenté hace tiempo, voy a seguir adelante con el desarrollo tal cual estaba planeado. Lo siento. Como mucho, intentaré reproducir aquella prueba que iba super rápida, y se acabó, ya no sé qué más hacer para mejorar el rendimiento :(

¿Sabeis lo bueno de llevar un control de errores bien documentado? Que localizas la línea que corregiste hace 8 meses en un santiamen y puedes ponerte a pensar qué hiciste mal entonces.
¿Sabeis lo malo? Que cuando descubres que el error era que estabas usando la constante de gravedad en lugar de la variable que almacena el valor de la gravedad según las condiciones (en este caso, la constante de gravedad bajo el agua), tienes ganas de pegarte un tiro y de mandarlo todo a tomar (censurado).

Sí, el bug se ha solucionado sustituyendo una constante por una variable. Así de simple: tiempo de resolución, 5 minutos. Para darme una colleja.
En fin, no sé si seguir. Documentaré esto, haré copia de seguridad de esta versión y lo dejaré por hoy, creo. Si alguien quiere un binario, que me lo diga, pero aviso que sólo se lo voy a mandar a Bennuseros consagrados, es decir, que al menos hayan aportado juegos o material ala comunidad. No quiero que me lluevan los mensajes para probar una beta que no aporta casi nada a la versión anterior.

Mientras la sueltas me echare una partida online
https://coldev.sourceforge.io/bennugd/onlinedemos/EchoNacl/


Cambiando de opinión , Bueno suéltala ya que queremos jugarla...

;D

si, ya...
cambiando de idea...
(http://storage1.static.itmages.com/i/17/1126/h_1511690600_6039619_b28a24c3ef.png)
(http://storage2.static.itmages.com/i/17/1126/h_1511690665_9862373_2a65948019.png)

Requieres chrome para jugar Echo online

¿vale el chromiun de linux?

Bueno, L1nk, primero tengo que encontrar tu dirección de correo :D
Quiero además echar un vistazo al código de los enemigos, ya que es un copia-pega del Echo y sufren de los mismos problemas. Creo que con eso ya puedo dedicarme a crear los mapas de tiles con dos capas (por fin podremos ver a Echo a través de algunas paredes) y a crear nuevos niveles, que llevo toda la semana queriendo ponerme, pero siempre había un problema que resolver (lo he dicho en otro hilo, esta semana los ordenadores y yo nos hemos peleado casi a muerte, especialmente con los del trabajo).

¿vale el chromiun de linux?

No le he probado, pero se que en la tienda linux esta Chrome oficial ... y funciona OK (Solo requiere Chrome ...)

En el caso de tener un juego propio, Si quieres que bennu se ejecute online en navegador debes descargar el kit desarrollo de Bennuchrome y subir el juego a tu hosting
https://sourceforge.net/projects/coldev/files/chrome%20native%20client/ (https://sourceforge.net/projects/coldev/files/chrome%20native%20client/)


Bueno, L1nk, primero tengo que encontrar tu dirección de correo]Bueno, L1nk, primero tengo que encontrar tu dirección de correo

bueno esperando mi regalo de navidad para jugarlo..    infocoldev@gmail.com

;D

Bueno, L1nk, Papá Nöel se ha adelantado y te ha mandado un e-paquetito... si no me lo rechazan en aduanas :D
Por e-mail te he explicado un poco las "condiciones de uso", que espero que sean lo suficientemente tiránicas como para ganarme una reputación de max-bennu-developer-con-un-par :D

Y la próxima vez, tu dirección me la puedes mandar por PM, que para eso está ^^U
Y no, no se la voy a mandar a nadie más, a menos que tenga intenciones serias de hacer un port :D

estos de coldev son mu buenos, yo estoy deseando terminar con mis juegos para que me lo roben y exporten a todo lo que le den la gana, je je

Para eso:
1- Tienes que haber terminado un juego... o lo más parecido a eso, porque aquí nunca terminamos nada.
2- Tienes que haber hecho tu mismo algún port previamente, ya sea a Wiz, DC, PS2 o la lavadora (aun tengo que conseguir que funcione el programa de secado, por alguna razón se le enredan los mapas de 8bits).
3- El juego tiene que molar: o sea, ser terriblemente bueno, o terriblemente absurdo. Quedarse a medias no vale, porque un juego terrible no vale ni para una crap compo.
4- Tiene que estar en un lenguaje comprensible. Preferiblemente en binario, Bennu, Pixtudiano o Castellano. Si te empiezas a inventar palabros, no te entiende ni tu equipo de programación.
5- Nicolas Cage mola (acabo de terminar de ver una peli suya :D).

buf, no me hables de recuperar mis antiguos, a ver si con los nuevos los adaptos a un formato mas ''copia~pega'' y salen como churros

Prueba de observación: en la siguiente imágen podéis ver lo que he podido programar este finde. ¿Qué ha sido? :D

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=4030)

No es mucho pero será una gran diferencia visual, además, tengo un trancazo que no me ha dejado hacer más... Bueno, he empezado a modificar mi detección de tiles de durezas para poder crear personajes de dos tiles de altura, pero no he hecho gran cosa, apenas he revisado un 10% del código, y luego habrá que testearlo a fondo.
Y aun tengo que ver por qué tras los anteriores cambios, los pájaros atraviesan el suelo :S

Yo iba a decir que la niebla, pero como he estado siguiendo el hilo, igual es el echo que pasa por encima de los roles que antes no podía, cuestión de zetas

No, la niebla ya estaba en la anterior versión, tanto delante como detrás de la zona jugable.
Respecto a que Echo pasa por delante de algo, por ahí nada la cosa, pero no, no son las Z. Si te fijas bien o si recuerdas esa parte del nivel, seguro que ves algo más diferente :D

como no sea la luna lunera...

La luna sigue en el mismo sitio desde que se lanzó la primera beta del juego... bueno, creo que la pasé a un fondo en lugar de dibujar un círculo en el gráfico de fondo por aquello de unificarlo todo (añadir fondos de scroll y eso).
Pero sigue pensando, lo de las Z iba muy bien encaminado :D

no llegue a ese nivel, pero lo unico con Z que se me ocurre es el pasto y el Echo entre el mismo y las columnas... la verdad que ni idea.

ese nivel es el primero, señor Amato Yoshi, y es verdad, es el pasto...
creo

Vais bien, a ver si más gente se anima a participar :D Si no encontrais la solución, el viernes os lo digo.
Pero andais muy cerca, Splinter ya se lo huele cual trampa de queso :D

PD: Mira que lo puse fácil: la captura es la hice a los 10 segundos de juego, así que si no conoceis la localización de la imagen es que ni habeis ejecutado el juego siquiera :D :D :'(

jaja... si que jugue al juego... pero cada vez mas viejo, y el aleman no perdona...

pues ya me parecia! las cavernas tienen fondo... no se ve el cielo por detras...

ya que estamos podrias poner nubes por detras y algunas por delante... o al azar...

las nubes parallax de detras....

¡¡Dindindindin!! Splinter ya lo ha visto. Es la primera beta donde los mapas del scroll tileado tienen DOS capas: la que ya conoceis por delante, y una nueva por detrás :D
Falta medir el rendimiento en la Wiz, a ver si se nota o no el efecto, pero según las últimas pruebas (las de no conseguir ni un solo frame extra con diferentes motores), no debería suponer un gran costo computacional (no debería llegar ni al 0'5%, porque hablamos de una capa mayoritariamente vacía... de momento).

Mira que llevo todo el año siendo pesao con esto. Todo el tema de mejorar el rendimiento era porque quería meter las dos capas de una vez :D

Respecto a tu sugerencia, Splinter... Ya el primer nivel tiene nubes por detrás, usando tres scrolles nada menos, y la niebla por delante, que no es aleatoria, pero consume ella sola más del 10% de la memoria del juego y que hace que se arrastre en Wiz. Y cada nivel tiene una imágen diferente: paredes de ladrillos, infinitas salas con numerosos arcos, el futuro en ruinas tras la bruma... Mi favorito es el fondo del nivel subterráneo, es el más pequeño y no precisamente el más complejo de todos, pero ese contraste de colores, y cómo vamos pasando de una oscura cueva del desierto a un lago subterráneo de cristalinas aguas antes de llegar a... Tendreis que esperar a que se estrene la segunda temporada, no voy a hacer spoilers :D Pero los dos "niveles" que se vieron en la 1.3.2 fueron un pequeño adelanto de los tres que va a tener esta versión (y seguramente los amplíe). Van a estar relacionados entre sí y... si me da tiempo, lo mismo meto el nivel que no llegó a entrar a tiempo en la primera temporada :D

se me ocurre preguntar, es necesario que sean 2 capas? no puede ser 1 sola, total la parte donde no puede pasar (la capa que ahora es la de adelante) no permite pasar por ella, con lo que daria la sensacion de ser 2 capas... (creo, lo estoy pensando asi en el aire)

Eso era así, pero llevaba tiemppo queriendo que hubiera cosas por detrás, no sólo los murs por los que no se puede pasar.
Por ejemplo, quería hacer que Echo se viera transparente cuando atravesase paredes, y ahora puedo: en la capa de detrás el muro sólido, y ahora en la de delante el mismo tile pero en transparente.
Además, podré poner pinchos y agua en la actual fase 3-2, y hacer efectos en todo el primer nivel para tener zonas a cubierto y al aire libre. Ya lo verás :)

Sí es cierto que actualmente, salvo por el tema del agua, el juego funciona bien con una sola capa, por lo que si Wiz se resiente demasiado con dos, no me costaría nada configurar el juego para que cargue el mapa de 1 o de 2 capas, total, el motor es exactamente el mismo :D

Bueno, pues como pensaba, los peores temores se han confirmado: a Wiz le sientan mal los mapas de tiles de dos capas.
En general n hay una caida de rendimiento en condiciones normales, pero cuando llega el momento de cambiar de tile, la pausa ha aumentado al doble, incluso diría que a más.

El código se hizo intentando mantener un gasto razonable de CPU, manteniendo el uso de memoria al mínimo. Actualmente la cantidad de procesos tile que se crean y se destruyen es mínima, ya que gracias a una lista enlazada, se pueden ir reciclando (el que desaparece, antes de ser eliminado, espera a ver si necesita que le asignen uno nuevo). Sólo hay procesos tile dentro de la zona de pantalla (y 3 filas/columnas extra, para que no se vean cómo aparecen de improviso).

Pero sí es cierto que hay una parte que es costosa computacionalmente: obtener el número de tile. Actualmente uso una función, que comprueba si la posición solicitada está dentro del mapa, y según el tipo de dato, consulta un puntero a un array según el tipo de dato usado. Para calcular la posición, se realizan dos multiplicaciones y una suma: (capa * nTilesCapa) + (fila *nnTilesFila) + columna. La pega es que se llama a esta función por cada posible tile en pantalla, y creo que es la parte que más hace que se resienta todo: crear y eliminar la función ya lleva un tiempo de cómputo.
La idea que he tenido es suprimir dicha función, y usar índices para cada eje, de modo que pueda usar bucles para recorrer directamente los arrays dinámicos. En un principio descarté la idea porque era un riesgo el andar recorriendo punteros sin un control de errores, pero se va a hacer en un proceso de uso interno donde, supuestamente, no se va a tocar nada, así que creo que merece la pena intentarlo.

La cuestión es ¿Cuándo? ^^U

O también puedo probar con el motor de scroll sobre gráfico :D Las funciones draw no son precisamente rápidas, pero lo mismo aquí sí lo son, y mejoran el rendimiento al pasar de una media de 80 procesos tiles a 2 imágenes en srcoll, pintando filas o columnas de 16 pixels cada vez.

He intentado hacer lo que dije en el anterior mensaje, de recorrer el array manualmente, pero... ha sido un fracaso. Es cierto que apenas he hecho el esfuerzo, pero estoy de vacaciones y necesitaba descansar, así que cuando ha empezado a darme errores por punteros díscolos y he visto que tras 10 minutos de intentos no conseguía avanzar más, lo he dejado para otro momento, así que por ahora, Wiz tendrá que conformarse con mapas de una sola capa.
También he intentado arreglar los pájaros qe atraviesan suelos, pero pasa lo mismo: tenía una idea de por dónde podría provenir el problema, pero me equivocaba, y por tanto, me he vuelto a quedar atascado. Necesito reproducir las condiciones exactas del error y no guiarme a ojo, y eso lleva más tiempo del que estaba dispuesto a dedicarle hoy, así que de nuevo, se queda para otro momento.

Y ya me quedé sin fuerzas para empezar a desarrollar nuevos niveles, así que me puse un rato con Blender y otro con la consola, que llevaba tiempo sin cogerla. Mañana tengo que volver al trabajo, donde me han negado el día de vacaciones, y enfrentarme a un programa obsoleto, a ver si lo hago funcionar con una librería moderna o bien tengo que downgradear unos ficheros, volviéndolos a crear desde cero :S

envidio y odio ese chollo de trabajo mierda que tienes

Créeme si te digo que el editor de mapas de tiles, con todo lo complejo que es, con todas las capas, variables, funciones, clases, etc, etc que lleva, es más fácil de hacer que este mostrenco en VB6... Y eso que sólo estoy tocando menos del 10% del código. Si llego a tener que mantenerlo entero... lo habría pasado a VB.net y habría borrado el 70% del código, sin exagerar :D

Hola de nuevo:

Después de meses sin tocar ni una línea de código, he decidido darle un empujoncito al juego, a ver si podemos avanzar algo. Debido a la salida de la RG350, y al intento frustrado de Fede de portar el juego a la BitBoy, me dio por ponerme un rato y añadir el código que necesitaba para configurar la pantalla y los botones de la RG350, y pode rasí ejecutarse... más o menos bien, ya que lo que hice puede considerarse una chapuza (por alguna razón, el Bennu de la RG350 no reconoce el SO como OpenDingux, y sospecho que la BitBoy hace tres cuartos de lo mismo).

Tras esto, me siguieron quedando ganas de programar, así que fui trasladando los cambios, ahora sí, como es debido, al código principal. Ya más o menos he metido todo el código que implementé en el "parche", aunque quedan un par de detalles.

Pero la principal razón de no haber tocado el código, aparte de la falta de tiempo y ganas por pasarme 9 horas al día programando en el trabajo, es que hay un bug en la detección de durezas de uno de los enemigos: los Corvos. Por alguna razón que desconocía, los Corvos eran capaces de volar atravesando los suelos o las paredes desde la última actualización del código. Como ya mencioné alguna vez, el código que controla la detección de durezas alcanza las 2500 íneas de código, si bien en realidad sólo se ejecuta el 15% del mismo, si llega, y depurar semejante monstruosidad necesita de mucha paciencia, dedicación y dosis de suerte.

Y precisamente, con suerte y con ingenio pude dar con la clave. Por un lado, la detección de durezas se separó en 4 ficheros que se comparte a lo largo del código de aquellos enemigos y objetos que usan físicas. Son 4 trozos de código que se "incrustan" dentro del código de los procesos enemigos, directamente. Por otro lado, y es la parte afortunada, aun disponía de esos ficheros en una versión anterior, cuando aun funcionaban. Los cambios no eran excesivamente drásticos, y eran compatibles con el código actual, así que los sustituí para comprobar que con el motor "antiguo", los Corvos aun se comportaban como debían.

Confirmado esto, fui sustituyendo los ficheros uno a uno por los nuevos hasta que volvió a fallar. El tercero fue el que dio la voz de alarma, pero no quise meterme a ello hasta comprobar que el cuarto funcionaba correctamente. Definitvamente el tercero.
Este tercer fichero controlaba el comportamiento del enemigo si cambiaba de tile verticalmente. Tenía sentido, pues los Corvos atravesaban los suelos pero rara vez las paredes. Bien, pues usando Notepad++ (y una doble pantalla, no sabéis lo útil que puede llegar a ser) comparé ambos ficheros y había dos líneas que cambiaban: ambas controlaban una cosa, el reposicionamiento del enemigo si este intentaba atravesar un suelo sólido. En principio no veía nada raro, así que las dejé como en la versión anterior, y todo volvió a funcionar como debía.

Pero el cambio se hizo por algo: era un código que reducía los cálculos a la mitad, y tenía en cuenta la posición y el movimiento del enemigo en pantalla... un momento ¿los movimientos? Ahí estaba la respuesta ¿Por qué sólo los Corvos atravesaban los suelos y no el resto de enemigos? ¡Porque los Corvos tenían un valor cero para la variable "gravedad"! Esa era la clave.

Así que hice un IF: si tenían gravedad, usan los cálculos nuevos, si no, usan los cálculos antiguos, y así todo a funcionar como debía.


Con esto tan complejo ya fuera de la ecuación, he podido seguir con el desarrollo normal: crear nuevos tiles interactivos, nuevos gráficos, continuar con el nivel... pero eso es una historia para otro día.

Tendría que haber escrito esto hace ya hace una semana, pero lo de siempre: lo vas dejando, dices que es mucho rato, y al final...
Intentaré ir dosificando la información de lo que he ido haciendo, así, los días que no haga nada, tendré para seguir contando :D

Bueno, empecemos por el principio, porque creo que me lo salté. Una de las razones, quizás la principal, fue que Fede me pidió que portara el juego a la BitBoy. Hice deprisa y corriendo unos cambios y... eso me picó el gusanillo.
Me puse a leer acerca del juego, de cuando lo hice para el concurso. Aun está el hilo en los proyectos del foro inglés, bajo el nombre original del proyecto: Doggy!!! Ahora más o menos sabéis por qué. Luego seguí con este mismo hilo, ya no sólo por la nostalgia, sino porque es una fuente de información de lo que hice y cómo lo hice... más o menos, lo que me ha ayudado a retomar el proyecto por donde lo dejé.

Ya habéis leido acerca del error con el movimiento de los enemigos que ya he corregido. Pues el siguiente paso era añadir elementos que aumentasen las posibilidades de hacer puzles y plataformeo interesante, y aquí es donde interviene un proyecto que fue "cancelado", y que tenía intención de seguir (algo se ha hecho, pero me quería centrar en Echo). Dicho proyecto era, según su director, un clon del Echo, con otro personaje, y que cumpliera las características de cierto concurso que se suspendió por falta de participación.Dicho proyecto, aprovechando que tenía el motor hecho, y que tenía mucho más tiempo libre que ahora, le pude añadir una serie de tiles interactivos muy interesantes: suelos que se rompen, plataformas que aparecen y desaparecen de forma síncrona... Bueno, ya que estaban hechos, sólo había que añadirlo al Echo y... sí, funcionaron desde el primer momento, al menos los dos tipos de bloques que desaparecen al pisarlos, no me quise poner a probar los bloques síncronos por... exigencias del guión... Bueno ¡qué leches! Ya habéis visto que el nivel 3 (en realidad el 4) comienza en un desierto y termina en un agujero en lo que parecen unas ruinas egipcias, que daba paso al nivel de la cueva. El nivel de la cueva ha sido sustituido (más bien, aplazado) por un nivel subterráneo, una especie de pasadizo secreto que comunica la puerta con una entrada secreta a la gran pirámide, pero no penséis que la entrada va a ser sencilla, ya va a tener un pequeño adelanto de lo que nos espera dentro.También voy a adelantaros que la pirámide va a cumplir el mismo propósito que lo que se había diseñado para la "season two", sólo que ahora dicha temporada va a ser una trilogía de episodios. Esta pirámide esconde muchos secretos, y obviamente, un laberinto, pero el secreto más importante es el acceso a las cuevas que ya habéis visto, que serán el segundo capítulo. Las cuevas se ampliarán, usaran los bloques que se rompen, y se complicará un poco más, todo para servir de nexo al tercer capítulo de la trilogía: el "misterio en construcción" :D Lo siento, no voy a desvelarlo todo, y menos si aun no sé hasta dónde voy a llegar :P
Bueno, volviendo al diario, tras añadir y probar los nuevos tiles, era hora de intentar añadir un elemento que se me ha resistido desde los albores de Fenix: crear plataformas móviles. La dificultad reside en que dichas plataformas, además de moverse, tienen que mover al prota, ignorando las físicas normales de las durezas. Por tanto, el primer paso era poder "capturar" al prota cuando intentase atravesar dicha plataforma de arriba a abajo.La parte complicada es que el prota se comporta de forma diferente a la habitual y he creado un nuevo estado llamado "en plataforma", en cuyo caso se ignora la gravedad y actúa como si estuviera parado o andando. Como la plataforma no debe actuar directamente sobre el prota, porque no entiende las durezas del entorno, se me ocurrió un sistema pasivo, similar al que tengo para los golpes: la estructura info_prota ahora cuenta con una variable "plataforma_id", en la que si una plataforma "captura" al prota, pondrá ahí su ID, y ya el prota sabrá qué hacer.En concreto, lo que debe hacer la plataforma es indicarle al prota cuanto "debería" moverse para seguirla, además de su movimiento normal, mientras siga sobre ella.
Aquí se plantean dos cuestiones: como "liberarse" de la plataforma, y cómo afecta el movimiento extra al prota.De momento, liberarse es fácil: si el prota salta, ya no está "en plataforma". Aun quedan dos asuntos por resolver, que son "si se aleja demasiado de la plataforma" (que se caería de ella) o si "la plataforma atraviesa una dureza y posa al prta en un suelo", pero quiero dejarlo para más adelante, porque quiero aprovechar el modo "en plataforma" todo lo que pueda en una zona controlada.Y es lo que nos lleva a la segunda parte: interactuar con las durezas usando el movimiento extra. Mi primera idea era "desplazar" al prota, y luego sumarle el movimiento propio, y las durezas le impedirían avanzar. Pues resulta que no, Echo empezó a atravesar suelos y paredes cual fantasma, vaya horror. Entonces decidí que lo que haría sería sumar las velocidades calculadas de gravedad y aceleración para andar con la de la plataforma... y funcionar funcionó, pero aun hace cosas muy raras, como que no puede acelerar en contra del movimiento de la plataforma.
Aun tengo un poco de lío cerebral con el tema de qué velocidades deben reducirse al contacto con una dureza, si debería mantener la velocidad propia del prota y la de la plataforma unidas, o cómo le podría afectar el cambio de tile.De momento descubrí que si la plataforma se movía hacia abajo, y atravesaba un tile, el detector de durezas activava el estado "en caida" y atravesaba la plataforma. Eso lo he corregido forzando el estado en caso de que "plataforma_id" siga siendo distinto de -1. Pero aun no sé por qué hace algunas cosas raras con la aceleración, o por qué el prota se mueve con 1 frame de retraso. Eso será una historia para otro momento.
En el próximo episodio, hablaré de cómo seguí el desarrollo por otro lado.

Para el tema del frame de retraso del personaje cuando está en la plataforma (problema típico que se puede ver hasta en los juegos comerciales de consolas de 8/16 bits) tienes que intercambiar la prioridad del proceso plataforma (con la variable local priority) respecto a la del proceso prota para que tenga una prioridad superior la plataforma cuando el prota esté encima y devolverle la prioridad al prota cuando no está en ella.

Esto me ha pasado en el engine que estoy  haciendo,quería que el prota fuera  a 40 frames y la plataforma a distintos frames y aunque lo aclara se producía un temblor en el protagonista según cuánto avanzaba la plataforma,para salir del paso todo va a los mismos frames, probaré eso de priority más a fondo pues lo hice pero no hacía nada.

Como reflexión debería ya el propio bennugd o derivado de div tener un motor tipo tiles ,pues es lo más laborioso , tengo  tropecientas líneas y me quedan aún más para considerarlo terminado .

Sí, eso es lo que hago:
Inicialmente, la plataforma tiene una prioridad inferior que la del prota, porque necesito que el prota se desplace antes de detectar la captura de la plataforma, de forma que si se produce, pueda "recolocar" la imagen del prota (sólo la imagen, no la posición dentro del scroll) antes del final del frame (el renderizado), y luego se pone su prioridad a una superior a la del prota.
En el siguiente frame, la plataforma se mueve, y le manda las velocidades X e Y mediante las variables de la estructura info_prota, como ya mencioné antes. El prota entonces se debería ejecutar, ver que ha sido "capturado", ponerse en modo plataforma, y reajustar su posición de acuerdo a la modificación que le hizo la plataforma en el frame anterior. En teoría, en este frame ignoraría las velocidades (creo, no tengo el código delante), pero no importa que se ignore el primer "impulso" mientras coja los siguientes.

Tengo que verificarlo bien, pero diría que o bien no se está alterando correctamente la prioridad, o por alguna razón, hay un frame de retraso, o una actualización erronea de la posición del prota en el scroll tileado.


Hablando de scroll tileado, en realidad no es tan laborioso... Bueno, un poco lo es, pero después de haber implementado como ¿5 versiones? tampoco es demasiado complejo.
Es cierto que se echa de menos, pero es que no hay aun siquiera un consenso sobre un formato de mapas de tiles. Hay una librería de scroll de mapas de tiles hecha por un forero, no recuerdo quién, y el código fuente de mi scroll está disponible por aquí, por si lo quieres mirar o directamente usar, oscarg.

Gracias por el detalle,le echaré un  vistazo el domingo que es mi día libre y veré cómo lo has implementado, siempre y claro me aclare con el código  :)

Creo que está explicado en el mismo hilo.
Básicamente tengo una lista con un proceso por tile no nulo. Cada vez que la cámara al desplazarse cambia de tile, se comprueba el mapa de tiles, y se modifican los procesos tile (gráfico y posición), borrando de la lista los procesos sobrantes, o añadiendo según la necesidad.
La ventaja es que hay un fichero, add_tile.inc, que es donde va el código que añade el tile a la lista, y puede ser modificado para que, en lugar de generar un proceso tile, genere cualquier otro tipo de proceso, como enemigos, botones o lo que sea, por lo que se puede usar el mapa de tiles más que para mostrar los escenarios.

A la hora de usarlo, he intentado que sea simple: load_tmf, se setean algunas variables, start_tscroll y a correr. Al menos, tan simple como pueda ser el scroll de Bennu, salvando las distancias.

Lo más complejo es calcular la posición de la cámara respecto al mapa, y tener en cuenta si este se repite horizontal o verticalmente.
También hice el típico scroll pintando en un mapa, pero era muy lento, y luego hice un híbrido de pintado en mapa y uso del scroll de Bennu que no recuerdo si lo liberé... o si encontré cierto bug que lo rompía.

Buf, lo siento, debería estar actualizando el diario y no lo estoy haciendo.

Sí, el desarrollo del juego sigue adelante. No tan rápido como me gustaría, y estoy viendo que me va a ser imposible  añadir los dos niveles que tenía previsto para la primera semana de Marzo... De hecho, es muy probable que ni siquiera termine uno de ellos, porque a medida que avanzo en el desarrollo se me van acumulando cosas, en lugar de reducirse:

Para empezar, voy a tener que crear un set de tiles nuevo para la tercera parte del nivel egipcio. Tenía pensado usar los tiles ya creados, y añadirle dos o tres nuevos, pero resulta que la ambientación dentro de la pirámide es diferente a la de fuera. Me he documentado, y el interior debería tener más aspecto de templo que lo visto hasta ahora, con colores vivos, jeroglíficos (ya estoy hablando con una experta en el tema para darle un poco de "legitimidad" al asunto... y que si no lo hago, va a dejar de hablarme :D ) y mucha decoración. Voy a intentar reutilizar algunos tiles ya creados, pero estoy limitado a 100 tiles diferentes como máximo, y cambiar esa restricción me iba a hacer cambiar todos los FPGs y un montón de cosas en el código: a partir del tile 100 se generan objetos especiales, y tendría que revisar el código para no meter la pata, y ahora no tengo tiempo para eso.
También he tenido que crear diversos tiles para la segunda parte del nivel, que al ser subterránea, hay tiles que debía "oscurecer". Por fortuna, dispongo de tiles de FBustamante para tal propósito, y su edición no supondrá un problema.

Aun tengo que lidiar con un problema con los tiles de agua, que no puedo resolver, de momento, sin mapas de tiles de 2 capas, y no sé si es buena idea incluirlos ya, porque... vale, mientras se incluya la información en la capa 0, y se deje la capa 1 para tiles normales, no hay pegas, pero hay tiles que al crear un objeto (un enemigo, por ejemplo) modifican el contenido para evitar que esté generándose a cada frame, pero no tienen en cuenta el tema de las capas, y es algo que precisa revisión. Al igual que con lo de ampliar el número de tiles, no tengo tiempo para eso.

Y se le suma que tengo que crear dos jefes de fase, con su IA; dos tipos de enemigos nuevos, con una IA bastante compleja; que hay que reordenar en el código los niveles que se van a ejecutar y, si fuera posible, cambiar la numeración de los niveles, por constantes, para que fuera más simple esta tarea; una sala nueva para el boss del nivel con unas reglas muy específicas... A cada día que pasa se añaden cosas... no nuevas, sino que no había pensado que fueran tan complejas.


Pero dejemos de hablar de lo que falta por hacer, y pongámonos con lo que se ha hecho. Lo voy a hacer sin ningún orden concreto, porque hay tantos detalles que si no, seguro que se me pasa algo.

De vuelta a las plataformas móviles, me alegra anunciar que la mayoría de los problemas están resueltos, o eso creo. El principal problema que estoy teniendo es cuando el prota choca con una dureza, porque esto provoca una variación de las variables internas de velocidad. Como ya comenté anteriormente, las plataformas móviles suman su velocidad a la que ya tuviera el prota, y la idea es que la detección de durezas intente mantenerla, o modificarla en caso de que se choque con algo. Al no ser velocidades separadas, la del prota y la de la plataforma, esta variación de velocidad está provocando efectos no deseados al no ser capaz de distingur si afecta a una velocidad o a otra... aunque creo que eso poco tiene que ver. El caso es que he podido resolver todos los efectos no deseados, como no poder acelerar en dirección opuesta al movimiento de la plataforma, atravesar paredes o suelos, e incluso caer cuando se cambia de tile hacia abajo. Ahora mismo quedan dos cosas por resolver: si se choca con una pared lateralmente, Echo se queda en el sitio, pero hace la animación de andar en lugar de quedarse quieto, y si al bajar la plataforma Echo "choca" con algún suelo (o sea, la plataforma atraviesa una dureza mientras baja) no se pierde el contacto con la plataforma y sigue ligada a ella.
En cuanto resuelva lo de la animación, podré seguir adelante, porque lo otro, de momento, para este nivel, no afecta... aunque debo arreglarlo, claro.

También está implementado la mayoría del código referente a OpenDingux: qué control usar, qué resolución, opciones por defecto, etc. Incluso he añadido lectura de parámetros para el BGDI, para que se pueda forzar el OS_ID, como en el caso de la RG350, que lo detecta como Linux. Lo único que está sin implementar es un proceso para configurar las teclas; ahora mismo se está usando el de PC, que hace uso de SCANCODE, y funciona relativamente bien, salvo para los botones A y B, que por alguna razón, se les asigna el mismo valor, y luego no funcionan.

Y sobre los niveles, el segundo mapa ya tiene terminado la parte de las durezas, por lo que es jugable de principio a fin. Ahora estoy en la parte de asignarle los tiles visibles adecuados, y luego llegará la parte de añadir enemigos, que es la que me preocupa, porque en esta parte hay agua, y ya he dicho que aun no está 100% implementada. Lo peor es que va a haber lava, y no sé qué hacer con las muertes, si va a ser muerte instantánea, progresiva, si hacer que vuelvas al último checkpoint (y cómo distinguirlo de una muerte "normal")... tengo muchas dudas de cómo implementar esto, y me tendré que enfrentar a ello en breve. Me pone de los nervios porque si a la gente ya le parece injusto el actual sistema de muertes, que te deja en el mismo sitio en el que muriste, el tener que hacerles ir para atrás al caer en la lava... Cualquier sugerencia será bienvenida.

Sí, he empezado con el mapa de durezas de la tercera parte... pero no última, ya que la lucha contra el boss va a tener lugar en una sala aparte. Una vez vencido, en lugar de terminar el nivel, como hasta ahora, se volverá al sub-nivel 3, y se completará un camino secreto que nos llevará al nivel 5: el de las cuevas.

Y luego está el tema de la música, que salvo milagro, me temo que van a ser tres "sub-niveles" muy silenciosos, salvo por los bosses. Tengo un comienzo de melodía, pero como ya sabéis, lo mío no es componer música.

Bueno, creo que eso resume, más o menos, por dónde anda la cosa a día de hoy. Quedan 3 semanas para terminarlo todo, y veo que no llego al ritmo actual, pero tampoco es que pueda acelerarlo mucho más, el tiempo que tengo es el que es, y las fuerzas las tengo que dosificar para no acabar reventado, y que afecte a mi trabajo o al juego. Voy a intentar tener, al menos, la fase esta de Egipto para el día 7 de Marzo, aunque tenga que posponer el desarrollo del mid-boss a la siguiente revisión, pero ya veremos cómo se presenta la cosa. Una cosa es hacer recortes, pero si quito demasiadas cosas, no va a tener sustancia :D

Hola drumpi,
disculpa por mi pereza...pero me puedes poner el link del motor de tiles donde lo pueda compilar y ejecutar?¿?
Otra cuestion,cuantos procesos ,tiles tienes ejecutando a la vez?¿?lo expreso para saber si lo puedo trasladar el motor a divgo sin que afecte a su rendimiento.Todavia no lo veo claro,pues por ejemplo, si tengo un simple mapa de 320x240 de tiles de 8x8.. son 40x30=1200 procesos o tiles solo para la primera capa...me parece que se me escapa algun detalle . :P

Pues lo cierto es que haces bien en preguntar.
Aunque hay una versión 3.2.1:
http://forum.bennugd.org/index.php/topic,4294.0.html (http://forum.bennugd.org/index.php/topic,4294.0.html)
Por lo que leo, se le dejó añadida la función que hace zoom al scroll. Si el rendimiento no importa y quieres probar a hacer efectos chulos, usa esa (en el primer mensaje está adjunto). Si no, te recomiendo que pruebes la 3.2:
http://forum.bennugd.org/index.php/topic,819.0.html (http://forum.bennugd.org/index.php/topic,819.0.html)

Tendría que comprobar si realmente es la última que tengo, pero creo que sí. Si no, te sirve para hacerte una idea.
Traen diversos ejemplos de uso (incluso para un scroll isométrico que se quedó de forma experimental), por lo que empieza por ellos.

Antes de que preguntes, los formatos TMF y TPR los genero con este programita: http://forum.bennugd.org/index.php/topic,4207.0.html (http://forum.bennugd.org/index.php/topic,4207.0.html)
El formato TMG no es más que un FPG, con mapas de 8 o 16 bits, donde cada valor de pixel es el número del tile.

Sobre cuántos procesos uso... eso depende: en el peor de los casos uso (ancho_pantalla/ancho_tile) * (alto_pantalla/alto_tile) * capas (entendiendo por "pantalla" la zona donde se pinta el scroll, no tengo forma de acceder a la información de las regiones), pero puedes añadir filas y columnas de más, por si necesitas que aparezcan tiles "fuera de pantalla". En el mejor de los casos se usan 0 procesos.
Sí, cero. El motor genera un tile, siempre que dicha posición sea >0 (si está vacío, ¿para qué generar un proceso?). Si el mapa tiene muchas zonas vacías, el rendimiento mejorará, y si hay muchos tiles, pues empeorará. Truco avanzado: los tiles no tienen por qué ser todos del mismo tamaño, en ocasiones en el Echo uso tiles de 32x16 para ahorrarme un tile, o de 32x32 para ahorrarme 3 :D Sólo tienes que tener cuidado de colocar el centro del gráfico en la posición (7,7).


Por cierto: si usas la versión del zoom, si no recuerdo mal, el número de procesos tiles varía con dicho zoom. Si haces los tiles más grandes, habrá menos procesos, pero si los haces más pequeños, habrá más.

El Echo tiene una resolución de 320x240 con tiles de 16x16. Aun usando 2 capas, en Wiz he conseguido velocidades superiores a 60fps, pero el juego en sí sufre de ralentizaciones y no he podido determinar si es por culpa del motor de scroll tileado, por la detección de durezas, por la cantidad de elementos en pantalla, por el código de tantas cosas, por las colisiones o la suma de todas ellas.
Sin embargo, en PC, con un AMD K7 1600XP, pude mostrar los 650x50 tiles del nivel 2 en el editor de mapas de tiles al mismo tiempo sin ralentizaciones.
Ten en cuenta que los procesos tile son procesos vacíos, en estado sleep. Haz tus pruebas.

Si tienes alguna duda, no dudes, pregunta :D

Bueno, no tengo mucho más que añadir a lo escrito el lunes pasado, porque como he comentado más de una vez, mi trabajo en ocasiones me exige que esté hasta tarde, y llego a casa con tiempo de cambiarme, asear e ir a cenar :D

De todas formas, me he obligado a sentarme aunque sean 30 minutos antes de acostarme y avanzar algo.
Me he centrado más que nada en la segunda pantalla del nivel, para ir puliendo detalles, que siempre se cuentan por decenas y consumen mucho tiempo. He ido decorando el nivel, y creando tiles a medida que me han ido haciendo falta, nada super complejo, pero bueno, ahí van saliendo, e incluso he ido coloreando algunos tiles de la primera pantalla para poder usarlos en la tercera. Ya tengo casi todos los tiles colocados a falta de tres o cuatro que aun tengo que crear, y podré centrarme en añadir enemigos...
Le he estado dando vueltas, y no sé si tengo suficientes enemigos... bueno, o al menos, enemigos lo suficientemente originales, porque no sé si los que desarrollé para la primera pantalla me van a servir para la segunda o incluso para la tercera. Recordemos que tengo gusanos, langostas, la cosa esa que excava la arena, las cabezas de Anubis, los pinchos y las bolas de energía que necesitan un nuevo gráfico para este nivel. Y ahora voy a añadir momias que no se van a poder matar, pero necesito añadir más cosas, aunque reutilice procesos, pero quiero evitar recurrir de nuevo a clichés tipo serpientes, escorpiones, murciélagos...

Voy a intentar priorizar cosas para que salgan los niveles con la mayor cantidad de cosas terminadas, para que sea un nivel interesante, y que no haya que cambiar demasiado su estructura en versiones posteriores.

Bueno, pues aquí sigue el informe semanal de avances del juego :D
Ya sé que debería hacerlos más a menudo, pero entre semana no me da tiempo a hacer cosas y escribir :P

Bueno, no he avanzado tanto como me hubiese gustado, pero como ya dije, las cosas son más largas de lo que se planearon inicialmente. En el segundo nivel egipcio, el que ya comenté que tenía las durezas hechas, he estado poniendo tiles en el mapa visible. Obviamente había varios tiles que no tenía y los he tenido que ir haciendo sobre la marcha. Ya los tengo casi todos colocados y he hecho algunas modificaciones porque me he dado cuenta de algunos fallos. Este proceso es lento y prefiero irlo haciendo en varios días, porque suelo encontrar un fallo, arreglarlo, probar y encontrar otro, por lo que repetir este bucle una y otra vez se tarda mucho y es muy tedioso, así que por mi propia salud mental, prefiero arreglar uno o dos fallos, hacer otra cosa, y volver al cabo de un tiempo (obviamente, anotando los fallos que voy viendo).
Hoy ha habido mucho de esto último.
Luego, he ido colocando ya algunos enemigos, para darle un poco de picante al asunto, aunque he de reconocer que el nivel no se diseñó para albergar ninguna fauna :D

Y ya hablando de fauna, he puesto el primer enemigo que se ha diseñado para la tercera pantalla en esta segunda. Es un enemigo implacable, terrorífico e inmortal, así que aprovechando una "zona segura" del nivel, he colocado uno de ellos a modo de "entrenamiento". Hay suficiente espacio para esquivar, disparar y hacer de todo, para que aprendáis lo que podáis antes de enfrentaros a hordas de estos enemigos en pantallas posteriores. También es cierto que se requiere cierta pericia para llegar a donde se encuentra, así que consideradlo una recompensa para los buenos jugadores.

Y ya que añadía un nuevo enemigo a la lista de códigos a cargar, he reordenado un poco el código interno del juego. Básicamente toda la parte de carga de gráficos y de niveles, porque ya no hay nivel 4-1 y 4-2, sino que habrá niveles 4-1 al 4-4 y un quinto nivel, que es el de las cuevas, y todo eso hay que modificarlo. La última limpieza de código ha hecho maravillas ahí, pero aun debo reorganizarlo mejor, porque hay muchos pasos previos para poder ejecutar un nivel, y sigo usando un array fijo para almacenar los códigos de los FPGs cargados, y estoy desperdiciando la mitad del espacio :D

Por cierto, ya tengo listos los gráficos de otro enemigo más. Lo que no me aclaro es qué comportamiento darle, porque al ser acorazado, puede servir de animal terrestre. Puede volar, por lo que también puede servir como los corvos. Y no me cabe ninguna duda de que podría ir lanzando disparos como los Flozat del nivel 3. Me ahorraría el hacer gráficos de nuevos enemigos y usar estos para tener 3 versiones del mismo, pero... no sé.Y quiero usar el código del super guerrillero para crear un enemigo complicado de matar, pero no sé si voy a tener tiempo de diseñar un gato cachas... o un chacal, o un loro, o...

El nivel 4-3 sigue en desarrollo. Iba a subiros una captura de cómo va el mapa, pero al final se me ha pasado ^^U Llevo como un 25-30% del mapa de durezas, y todavía no tengo los tiles visibles. A este ritmo me parece que no me va a dar tiempo a terminarlo. De hecho, estoy valorando muy seriamente lanzar esta versión sólo con la compatibilidad con RG350 y con el nivel 4-2, nada más. No quiero subirlo con una versión inacabada de algún nivel.
Aun así, sigo avanzando, va a ser difícil que esté listo en dos semanas sin dedicarle el esfuerzo de una Game Jam... pero hay que intentarlo. El fin de semana que viene va a tener 3 días, así que puede que le de un buen empujón, si las fuerzas acompañan y la gente me deja trabajar tranquilo. Ya sabéis, cuando es puente, las personas quieren pasar su tiempo libre gastando el de otras :D :D :D

Pero bueno, no todo lo que se ha avanzado ha sido algo tangible. He estado planificando el jefe del nivel. Al principio pensaba en crear un enfrentamiento con un personaje de la vida internetil en plan venganza personal, pero se me ha ocurrido una idea que me ha gustado más. Ya os avanzo que va a ser un homenaje a un videojuego clásico, al que dediqué incontables horas de mi infancia, hasta que le pillé el truco y podía superar niveles una y otra vez sin problemas. Ya el nivel iba a contar con alguna referencia, como uno de los enemigos y la melodía (ahora sólo será en parte), pero creo que este enfrentamiento será a la vez nostálgico y épico. La mecánica del escenario será la misma, pero no la de acabar con el jefe porque... en el original no había jefe, y no se le disparaba para acabar con él. De hecho va a requerir el uso de un arma exclusiva de esta zona, tan exclusiva que no se va a poder usar en ninguna otra parte del juego :D
Ahora os estaréis preguntando a qué juego me estoy refiriendo. Pues no, no os lo voy a decir, y la verdad, dudo mucho que la gente lo conozca. Tampoco quiero dar pistas, porque con dar un par de ellas, ya sabréis cuál es, a poco que conozcáis el catálogo de aquel viejo ordenador... ¡ups! :D
Bueno, ya lo dejo aquí. Es muy tarde, mañana madrugo, y tengo que echar horas para poder salir el jueves y hacer lo que tenía previsto para el viernes, que estará todo cerrado. Iré haciendo cositas sueltas de aquí al viernes, a ver si para entonces tengo los tiles básicos del nivel 4-3 y varias de las funciones que necesito para el jefe de la fase.
Que durmáis bien.

Bueno, pues hoy me acabo de echar un jarro de agua fría, yo mismo, y no era ningún "challenge" de esos de Youtube.
Resulta que estaba pensando en que los gráficos de la tercera pantalla de la pirámide, lo mismo quedaban algo sosos si compratían ambientación con los anteriores niveles, aunque tuvieran colores, y estuve echando un vistazo a unas notas antiguas que encontré con ideas para el futuro. Había unas notas escritas sobre la ambientación de la pirámide, que tenían mucho que ver con una idea que me surgió mirando jeroglíficos, y la idea es genial... quizás demasiado extrema, pero eso implica cambiar mucho del diseño de tiles que ya tenía/tengo...
...Aunque pensándolo en frío, en realidad no tengo tantos tiles hechos, no tengo que deshacer nada. Sí que aumenta el número de tiles, pero como ya tenía la idea de dar diferentes tonos de luminosidad a las salas de la pirámide, al final no es tan gordo el problema. Lo es por el tiempo que tengo y la limitación de tiles, que tengo que cuadruplicar los tiles básicos, que son 11, quizás 12.
Hablando de la pirámide, ayer se me quedó en el tintero mostraros una captura de lo que va a ser el mapa de la tercera pantalla. Aquí la tenéis

(http://forum.bennugd.org/index.php?action=dlattach;topic=4256.0;attach=4257)
Sí, como siempre, no me puedo ir a lo sencillo ^^U. En número de tiles, creo que igualaba al nivel de los guerrilleros y los aliens, pero como casi todo va a transcurrir dentro de la pirámide, el área efectiva es de la mitad, y como dije, es un laberinto (espero), por lo que no todas las salas tienen que ser visitadas. También he intentado imitar un poco los mapas que he visto de los interiores, con sus entradas en rampas, sus salas, recovecos, etc, y encima hacer caminos que se entrecruzan, pero no se mezclan.

Volviendo al desarrollo, tengo un problema que no sé resolver, y es que lo ideal es que dentro de la pirámide se tenga un scroll de fondo con una imágen oscura, adornada con jeroglíficos y eso, pero fuera debería verse el mismo cielo superiluminado de la primera pantalla. Como pasaba con el nivel 1-4, eso es fácil hacerlo cuando tienes dos capas de tiles, pero aquí sólo tenemos uno y debo idear algo (tengo pensado algo, pero es un poco cutre, que no es más que poner una imágen azul diagonal persiguiendo al scroll, colocándose estratégicamente delante del fondo de la pirámide cuando estás en la parte de fuera)...
En fin, en el lado positivo, he podido extraer varios tiles que me van a hacer falta en estas dos pantallas de la captura de Fede (ahora me toca diseñar los míos :D ) y he generado el FPG del nuevo enemigo para el caso de que sea volador; si fuera terrestre tiene una animación muy chula, pero debo escoger si quiero mostrarlo porque le pega al nivel, o volver a poner los gusanos por tener una variedad mayor de enemigos.
A ver hasta dónde puedo llegar de aquí al viernes.

Buenas de nuevo:

Debo daros malas noticias. A pesar de haberle dado un gran empujón al juego estos tres días, la cantidad de cosas y detalles que quedan pendientes para un lanzamiento que podamos considerar "completo" son demasiados para poder terminarlas para el sábado.
El plan B era poder sacar una versión compatible con RG350, y con al menos una nueva pantalla jugable, pero aunque lo segundo sea posible, lo primero no, pero voy a explicarlo bien.

Este fin de semana le he dedicado bastante tiempo al código, porque aun había bastantes cosas que cambiar para mover lo que antes se conocía como nivel 4-2 (el nivel de las cuevas) al nivel 5, y hacer sitio a lo que es el nuevo nivel 4-2. También quería ir llevando adelante lo que pudiera del nivel 4-4, más conocido como el "escenario del boss del nivel 4", porque había muchas cosas que programar, y bastante complicadas, por lo que para no saturar el cerebro mi método es hacer algo complicado cada cierto tiempo, y rellenar el tiempo de en medio con tareas más sencillas.
En este aspecto se ha avanzado bastante, porque tengo parte del código que modifica el escenario, y parte del código del boss, por lo que puedo estimar que está en un 45% de estar completo.

Pero el problema ha venido por la parte del código de la RG350. El viernes le dediqué buena parte de la tarde a probar el juego en la portátil, y funcionar funciona. Le he tenido que añadir ciertos cambios al código de configuación de las teclas para refinarlo... pero por alguna razón, la función que escanea las teclas (las teclas, no las tet...) hace cosas raras con el "backspace": según la documentación, está asignado al botón R1, y así pude comprobarlo con cierto código que diseñé para su testeo... pero una vez en la consola, al pulsar R1 se configura el botón B. WTF?
Dado que el sistema para depurar que tengo es bastante... cromañónico (compila, copia a SD, métela en el dispositivo, prueba, lee el log, repite), averiguar a ciencia cierta qué pasa me iba a llevar demasiado tiempo. He intentado buscarle un hueco el resto del fin de semana para ir depurando, pero me ha sido imposible, por lo que una compatibilidad del 100% con la consola es inviable en los próximos 6 días.

A eso hay que añadir que aun quedan cosas por programar para que funcione el nivel 4-2 correctamente: tengo que programar la lava, pero tengo el problema de que el sistema de daños del prota me hace muy difícil suministrar un daño continuo (es decir, 1 unidad de daño por frame). Por otro lado, aun no he podido arreglar las dos cosas que quedan pendientes de las plataformas móviles.


Por otro lado, el nivel 4-2 está casi terminado. Aun quedan un par de tiles que están sin hacer, pero por lo demás, está casi completo... pero sin el código que falta no se puede dar por terminado.


¿Y qué pasa con el nivel 4-3?. Bueno, ha seguido avanzando aquí y allá.
Lo que son las durezas ya llevo cerca de la mitad del nivel hecho, aunque no estoy metiendo todas las mecánicas nuevas, y debería estar haciéndolo ^^U De hecho, tengo que programar un par de ellas, que no es que sean complicadas de hacer, pero hay que hacerlas. Tiles hay un montón hechos, pero son todos de tipo básico (paredes, suelos, techos y rampas, sólo para sustituir a las durezas). Hay alguno de decoración, pero aun faltan bastantes por hacer para darle color al nivel.

Y es importante terminar el nivel 4-4 para terminar el 4-3. Como creo que ya comenté, la idea es llegar a una parte del 4-3 que te lleve a la sala del boss, en la 4-4, y al terminar el combate, poder volver y recorrer la última parte del camino.


Como veis, aun quedan bastantes cosas por hacer, y de aquí al sábado apenas voy a poder dedicarle un total de 4 horas sin acabar reventado, por lo que tener algo hecho de cara al usuario final es imposible. Como mucho, podré subir una beta con propósitos de depuración a nivel interno, pero ni por asomo una v1.3.1

Quién sabe si de aquí al sábado ocurre un milagro, pero no soy optimista en ese sentido. Se va a intentar, pero...
Lo siento.

Bueno, anoche decidí dedicarle un ratito a escribir algo de código, a ver si podía hacer una prueba preliminar de los tiles de lava... y al final estuve hora y media ^^U
Realmente, el código de los tiles de lava no es demasiado complicado. Lleva más tiempo reservarle un valor dentro del motor de scroll tileado, para que genere dicho tile de forma diferente al de los visibles, añadir el include al proyecto y diversos tratamientos adicionales (como enviarle la señal de pausa, por ejemplo), que el código en sí.
Dicho lo cual, el código base de un tile de lava está hecho, y la reacción del prota también... pero no se ha probado ¿Esto qué significa? Que sólo está hecha la mitad de lo necesario para que funcione :D Nunca subestiméis el tiempo necesario para realizar las pruebas, siempre es igual o mayor que el empleado en escribir el código.

Pero fijaos que digo "código base". Eso implica un tile de lava normal y corriente, un cuadrado rojo con un alpha de 190, que envía un par de valores al prota en cuanto está demasiado cerca. Quiero añadir al tile la capacidad de regular su altura, para poder hacer la superficie un poco más abajo y darle un poco de respiro cuando el jugador intente salir, es decir, que el tile de lava que está en la parte más alta de la piscina, pueda tener sólo 12 pixels de alto que le hagan daño de verdad a Echo.
También quiero poder añadir animaciones. El código ya está hecho en los tiles especiales... animados :D (si os pasasteis la versión anterior, recordaréis las cascadas de agua), pero antes de ponerme con todas esas "pijadas" (traducción para SplinterGU: elementos accesorios que sólo sirven para que quede bonito) tengo que conseguir que funcione la versión más básica: un cuadrado rojo que hace daño en cuanto lo tocas.

Espero poder terminarlo esta tarde y rellenar de lava el nivel 4-2. Con eso estaría casi terminado... salvo por los 30 detallitos que seguro que aun faltan por terminar :P
Y la mitad, relacionados con los gráficos de Fede :D

Finalmente, las pruebas han sido un éxito :D
Al principio, obviamente, no funcionaba, pero tras corregir las dos tonterías por las que fallaba, Echo empezó a perder energía al entrar en contacto con estos tiles... demasiado rápido, así que testeé la otra parte del código que se había hecho para reducir la energía más lentamente, y también funcionó. Aun estoy equilibrando la velocidad a la que se drena la energía, para que no sea ni muy rápida ni muy lenta, teniendo en cuenta la energía que podría tener el jugador en esta parte del juego y cuánto tiempo quiero que pase en la lava.
También me ha dado tiempo a implementar las animaciones y ya tengo dos tiles diferentes de lava (superficie y relleno). Por desgracia, la animación es tan simple como una ola que se va desplazando, y quiero que se vean burbujas inflándose y explotando, y añadir tonos naranjas y amarillos, y no un rojo plano como está ahora.

...y ya está, no me ha dado tiempo a más. Si hoy salgo pronto del trabajo y no estoy mentalmente agotado, intentaré añadir los tres tiles que faltan al nivel 4-2 y hacer las pruebas con los gráficos de Fede... o intentar averiguar por simple inspección qué puede estar pasando en el código de la RG350 para que no funcionen de forma adecuada los botones en el escaneo.
Tengo que revisar la lista de tareas, pero diría que con eso y unos cambios que tengo pendientes con las plataformas móviles tendría completo el nivel 4-2 :D Si no me he cargado nada del "modo historia" y he enlazado bien el nivel 5, es posible que pueda lanzar la versión 1.3.1 el sábado, o el domingo. Lo que no sé si de forma pública o por privado.

Pues... ya he añadido los tiles que faltaban... aunque debería añadir algún enemigo más por ahí... y quitar las plataformas móviles que he puesto para testeo.
Y he probado los tiles de Fede en el nivel, añadiendo los dos que faltaban.
He comprobado los botones de RG350 en el código y he sustituido A y B, que usaban _CONTROL y _ALT, por _L_CONTROL y _L_ALT, pero no los he probado en la consola.
Y según el código, el "modo historia" debería ejecutar las 4 pantallas del nivel 1, el nivel 3, las dos pantallas del nivel 4 y lanzar el nivel 5... pero los efectos sobre el fichero de guardado son una incógnita, aun. A ver si esta tarde lo pruebo.

Y ya está. No he podido hacer más. Le he podido dedicar una hora. A ver qué puedo hacer hoy. :D

Pues ayer hice una prueba general de funcionamiento, prácticamente íntegra desde la RG350. Me hubiese gustado haber tenido los resultados hace varios días por parte de algún betatester, y estar dedicándome a corregir los fallos, porque van a salir muchos, muy tontos, y el ciclo prueba-detecta-corrige se va a repetir mucho.


De momento, estos son los resultados de ayer:

Para empezar, me alegra anunciar que los botones ya funcionan correctamente en la RG350. Todos los botones (salvo los de volumen) son reconocidos por la configuración. Más tarde me daré cuenta de que los botones para cambiar al siguiente o a la anterior arma están invertidos, y estuve buscando la razón, pero no di con la tecla (badum tssssshh).

El modo historia iba funcionando bien, los controles respondían perfectamente y todo estaba en su sitio. Al llegar a Gravor pasó algo raro: me mató dos vidas. Por lo general, es un enemigo que elimino en unos 30-50 segundos con la espada cargada a tope, pero por alguna razón que aun no he descubierto, su punto débil, el interior de la boca, aunque recibía los impactos, no disparaba la secuencia que deja al descubierto su abdomen. Esto ya pasó anteriormente cuando el "escudo invisible" que protegía el interior de la boca detenía las balas antes de que impactaran en el punto débil, así que supongo que es más de lo mismo, tendré que revisarlo. Sólo espero que no se deba a un impacto contra las lineas mal hechas que aparecen cuando un proceso se rota o se escala en la versión de BennuGD de la consola. No sé si podré arreglarlo a tiempo, pero finalmente tuve que superar el boss en el PC... y el nivel entero :S

Esa es otra cosa que noté, los checkpoints no estaban funcionando... o al menos no estaban grabando la partida porque...

... Tras acabar con Satavamp, el nivel me hizo comenzar en el nivel 3, a mitad de camino del final. Un efecto secundario del cambio del método de numeración de los niveles. Ya está arreglado, aunque aun no lo he probado.

El nivel 4 está correctamente integrado. Tras derrotar al jefe alien, empieza el nivel en el desierto, luego se ejecuta el nuevo nivel y al acabar volvemos a las cuevas. Incluso el evento que dice "continuará", los créditos y la imagen final aparecen correctamente :)

Ya sólo queda modificar algunos tiles del nivel 4-1 que puse temporalmente en el FPG de Fede, hacer algunos arreglos al 4-2 añadiendo algún que otro enemigo aquí y allá, e intentar resolver los dos problemas gordos que he encontrado (Gravor y los botones de cambiar arma). Confío en que esta tarde, cuando vuelva a superar el nivel 1-4, aparezca al principio del nivel 3. Lo que ya tengo dudas es si arreglar o no lo de los checkpoints, porque me da en la nariz que no se hizo nada, y trastocar ahora todo el sistema de salvado de partida puede ser un desastre, ahora que todo apunta a que mañana podré tener una versión 1.3.3 para celebrar el aniversario.

Después podré seguir más tranquilamente con el desarrollo, con el nivel 4-3, el boss, modificar el 5, eliminar cosas de la enoooorme lista de cosas por hacer... y a ver si añado los mapas de dos capas sin cargarme la versión de Wiz, y me pongo definitivamente con el nivel 2 (sólo adelantaré que habrá ninjas, no hay género de acción en el cine o en las series si no hay ninjas... mmm ¿ninjas power rangers? :P).

Hola a todos:

Me alegra anunciar que finalmente la versión 1.3.4 de "the Amazing Adventures of Echo" está disponible para su descarga para PC, Wiz, Caanoo y como novedad, RG350.
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481

Sí, la 1.3.4. Por l visto ya existía una beta de la 1.3.3, así que he tenido que aumentar la versión ^^U
Las novedades creo que ya las he comentado un millón de veces a lo largo del hilo :D Pero a modo de repaso, todo se basa en la inclusión del nivel 4-2 (ya sabéis, en realidad es el tercero pero porque aun no se ha realizado el verdadero nivel 2) y la integración de código para que funcione en RG350.

Finalmente pude añadir los tiles que faltaban a los gráficos "stylish" del nivel 4-1 y añadir unos cuantos enemigos más al 4-2. Hice la prueba de superar el nivel 1-4, y efectivamente comencé en el principio del nivel 3, como esperaba.

Lo que no esperaba era que al cargar el nivel 4-2 no se vieran los nuevos enemigos, lo que me obligó a volver a la mesa de trabajo a aladir un par de líneas que cargaban los FPGs para ese nivel ^^U

Después, hoy llegó el día de empaquetar, subir y presentar. Odio esa parte :D Y hoy ha sido otro ejemplo de ello:
Con todo ya listo y empaquetado, llega la hora de hacer la prueba final y... en la RG350 me doy cuenta de que los valores por defecto de los controles están mal, en Wiz los controles no funcionan porque tienen un fichero de configuración que no le corresponde, y la caanoo está sin batería.
Elimino los ficheros de configuración de las consolas y de los paquetes y hago una nueva prueba: RG350 bien, Wiz bien, Caanoo no lo ejecuta. Reviso el script de arranque de caanoo y tiene un nombre de dcb incorrecto (el de Wiz, concretamente). Una vez corregido, nueva prueba y va... bueno, arranca, pero no recordaba que fuera tan a tirones, la Wiz no iba a tirones momentos atrás... Nueva prueba en Wiz, sí, da unos tironcillos, más graves en otros niveles, pero es buena señal, significa que el overclock funciona :D

Bien ya está todo... o casi. Me doy cuenta de que el level select no carga bien los niveles, que falta una captura del nuevo nivel... ¿me daría tiempo a arreglarlo? Pues sí, en unos 45 minutos ya lo tengo listo, así que de nuevo, a modificar los FPGs de la versión de desarrollo, de los 4 zips, de la versión final y de la copia de seguridad... por duplicado: gráficos "classic" y "gráficos "stylish"... y de nuevo a compilar y copiar.

Hay que hacer los ficheros de changelogs, anotar los cambios realizados, comprobar que los cambios están en la versión correcta...
Luego llega la hora de enfrentarse a la subida a la web, donde hay que repetir lo de los cambios efectuados, buscar dónde leches se ponen las diferentes versiones...
En fin, mucho rollo "burocrático", pero ya está subido el juego a la web de Gamejolt, a mi perfil.

Descargadlo, probadlo y reportadme los problemas que veáis. Los agradecimientos también son bienvenidos.
Pero obviamente esto no queda aquí. El hilo se llama "Echo 1.4: road to season two", no 1.3.4, aun nos queda el desenlace del episodio 4, la reedición del episodio 5, y la conclusión de la trilogía en el episodio 6, eso sin contar con que los de post-producción acaben de editar el metraje del episodio 2. El desarrollo seguirá adelante, sólo que sin una fecha determinada de salida (lo cual puede ser un problema, ya que era la motivación que tenía hasta ahora... y se me puede venir encima el "periodo entre proyectos" y puede ser desastroso).

Stay tuned. Same hour, same channel!!

Hola,lo acabo de probar esta chulo..el sistema de rampas y saltos perfecto.Observo que puedes bajar o subir cualquier cosa sin importar el angulo de inclinacion ,lo tengo que mirar por la red a ver como lo logro yo tambien ;D

Estaria bien que en futuras versiones se pudiera jugar a pantalla completa,pues en pc con mi monitor lo veo todo demasiado pequeño.
No veo ralentizacion alguna y eso que me expresas que todo se basa en tiles,joe..
En futuras versiones me gustaria poder eligir tipo de suavizado.

1.La musica esta muy bien,aunque como la fase1 es tan larga,al final se vuelve algo repetitiva.

2.Eso de poder elegir fase es un plus.esta muy bien acertado,aunque su sistema de seleccion es algo rebuscado.

3.Cuando te matan la escena de su animacion es demasiado larga y no suena ningun tipo de musica.Supongo que lo has dejado aparcado para mejorarlo en el futuro.
Veo que te queda mucho ,mucho trabajo para darlo como acabado,pues los mapas son muy extensos , cuando hagas otro juego de este tipo,no temas en hacer los sprites mas grandes,en otra ocasion haz una mega araña que realmente al verla te cause respeto.

4.Algo que si cambiaria y  repercute en su jugabilidad,cuando salto entre columnas estas se dibujan por encima del prota y no se entiende o se percibe bien que tiene una baldosa o suelo donde puedo pisarla.

5.Por finalizar sobre mejoras,es algo muy personal,a mi me gusta los juegos pausados,me explico,yo avanzo hacia adelante y llega un momento que no puedo,bien porque me sale el enemigo de turno que lo tengo que eliminar o bien porque hay una palaca que tengo que tocar y asi abrir una compuerta.Aqui he notado que puedo avanzar a saco en ciertos momentos y luego me encuentro que me sigue una tropa de enemigos en plan deseosos de quitarme la vida,si los he dejado atras,caray!!dejadme de perseguirme, pesados!!!si avanzo,avanzo,pero tampoco me gusta de esos que avanzas y avanzas y no haces nada solo ver pantallas  y mas pantallas,lo dicho,un juego con pausas.
Asi!!..una cosa para que mires el codigo,hay un momento del juego que los pajaros se quedan trabados, no pueden avanzar y se produce el indeseable "tembleque"mas de uno dira,es que sufren de parkinson,de ahi sus espasmos,pero creo que no cuela. :P

Muchas gracias por probar el juego, me alegra que te guste.

El tema de subir y bajar es un poco "a mi manera", ya que en lugar de mapas de durezas, como en "Castle of Dr. Malvado" (juego que conviene analizar, a poder ser, con el "manual avanzado de DIV" que comentábamos en otro hilo reciente) uso "tiles de durezas", y en mi caso le digo que si la posición cae por debajo de la diagonal, recoloque el prota sobre el suelo. Casi todas las durezas hacen lo mismo y es lo que provoca que, en ocasiones, cuando una de las comprobaciones de durezas no está bien hecha, se noten esos "saltos" en el movimiento.
Bajar las rampas, básicamente, es que cuando detecta que está sobre una de ellas, y está en modo "andando", fuerzo a que se pegue al suelo, incrementando la gravedad temporalmente (truco sacado del Castle...).

Respecto a tus sugerencias, sonará a tópico, pero las tendré en cuenta
Una cosa que hay que entender es que el juego se diseñó para consolas portátiles, de ahí que los sprites sean pequeños, que el tamaño de pantalla también lo sea... No puedo trabajar con una resolución de 320x240 y otra de 1366x724 o superior Sería hacer un port HD del juego.
Lo que sí está pendiente, y no recuerdo en qué juego se hizo, es la de poder definir el multiplicador de pantalla. En PC tengo activo el 2xScale, pero creo que puedo usar el ScaleResolution para multiplicar x3 el tamaño, quizás x4... pero en ese caso, los filtros del 2XScale no se podrían aplicar, así que tiene que ser o una cosa o la otra, ahí no tengo control.

Lo de la música en el nivel 1 lo entiendo, en su momento era genial, pero cuando llevas una hora jugando se hace demasiado monótona, por culpa de la flauta... que fue sugerencia mía al músico ^^U Ya he hablado con él por si se podía hacer una variación para ir alternando en las diferentes pantallas, pero me temo que anda demasiado ocupado con otras cosas (no lo culpo, las melodías se las pedí hace 10 años), así que me toca ocuparme del tema sonoro a mi, que no tengo ni idea de componer. Intentaré replicar la melodía con lo que tengo, y a partir de ahí veremos qué puedo cambiar. Y lo mismo para el nivel 3.

Lo de la animación de la muerte... me perseguirá hasta el fin de los tiempos Ya la reduje a la mitad de lo que duraba inicialmente. No quise reducirla más porque se me complicaba mucho el código y no tenía tiempo. Ahora tengo más tiempo, por lo que sí, está en la lista de tareas pendientes

Las columnas: sí, tienes razón, deberían dibujarse por detrás, pero sólo tengo una capa de scroll tileado, lo que significa que o bien la pongo por delante o por detrás del prota, y la mayoría de los tiles debían ir por delante. Ya he comentado que estoy preparando una opción que permita cargar mapas de 2 capas, ahora que tengo un editor que me permite hacerlo, pero tengo que mantener las de 1 capa, porque aunque tooodos esos procesos tiles funcionan muy bien en PC, en Wiz no tanto, y la segunda capa se nota, y ya opté por intentar mantener la compatibilidad con esas consolas mientras fuera posible en una encuesta que hice hará cosa de un año o más. Lo bueno de los mapas de 2 capas es que podré hacer que se vea a Echo mientras atraviesa las paredes, y quizás hasta pueda poner tiles transparentes por encima y lograr un buen efecto.

¿Los enemigos te persiguen sin descanso? Acaba con ellos No, en serio, en teoría, los enemigos que salen de pantalla y se alejan bastante, deberían volver a sus puestos, pero apenas empecé a hacerlo y no recuerdo qué enemigos lo hacen y cuáles no. Me vendría bien elaborar una lista, pero eso, tienen que salir de pantalla unos 32 pixels más o menos. De hecho, es una medida para ahorrar ciclos de cómputo en las consolas portátiles, donde el rendimiento es esencial, e incluso hay ciertas partes del juego donde se hace una "purga" de "enemigos viejos".
Los que se quedan atascados son los voladores con los techos. Es algo que tengo que mirar, porque también afecta a Echo. Hay algo mal en el comprobador de durezas que no ha salido hasta varias semanas después de la última revisión.

Aun así, aun tengo una lista de 20 o 30 cosas pendientes de hacer, así que voy alternando el "bug hunting" con hacer cosas nuevas. Me paso varias horas en el trabajo solucionando fallos, por lo que al llegar a casa estoy cansado, y tengo que estar en "modo Rambo" para acabar con los más gordos. A pesar de ello, siempre estoy dispuesto a añadir cosas a la lista si veis que son necesarias.

¡Ajá! Apuesto a que pensábais que no iba a volver a tocar el código en varios meses...

...y esa es la razón por la que nunca apuesto. Ni os lo habéis planteado :'(
En fin, pues nada, anoche no tenía sueño y decidí darle un toquecito al Echo, y me puse a programar un suelo que, al pulsar un botón, se recogía. Es como los puentes, que aparecen al pulsar el botón, pero al revés, que permiten abrir caminos o quitar plataformas para no volver a acceder a ciertas zonas.
De momento he estado programándolo, aun no está terminado y... lo cierto es que aun no tengo muy claro su funcionamiento, si los tiles van a ser unos predeterminados o si voy a usar los que estén en el mapa visible, si las durezas van a ser traspasables desde abajo, o no, o dependerá del mapa de durezas o de algún parámetro... no sé, tengo que pensar qué me va a dar más posibilidades con la menor cantidad de código, sin que se llegue a complicar demasiado.

...Y ya está, eso es todo. Oye, yo también tengo derecho a descansar de vez en cuando y pasarme algún juego que no haya hecho yo ¿no?
... ¿no? :'(

Bueno, pues al final hasta el fin de semana no he podido tocar más código, y sólo el Sábado, porque el Domingo no tenía el día para ponerme a trabajar.
No, no por depresión por tener que estar encerrado (al final no es tan distinto de uno de mis días normales :D ), sino por cansancio y sueño.

Bueno, el caso es que le dediqué bastante raro a reorganizar tiles que iba a necesitar para el nivel 4-3, concretamente a preparar los tiles de las puertas, los puentes, y meter en el FPG cuales son los tiles de cada enemigo, los de los botones... vamos, que estuve el día adaptando los gráficos para añadir interactividad al nuevo nivel. También en el código: estuve revisando lo que hacía falta para ejecutar el nivel, como la carga de los mapas (que aun no estaban en la carpeta del proyecto, porque aun está en construcción), los gráficos, etc.
Hablando de tiles interactivos, creo que ya tengo listo el puente que se retrae cuando activamos algún botón, pero no lo he probado. Le estoy dando vueltas porque también quiero hacer palancas o algo que se pueda activar y desactivar, y no sólo activar, y cómo hacer que eso afecte a las puertas y puentes que ya hay.

Ya de paso, estuve retocando el nuevo nivel. No hice nada nuevo respecto a durezas, pero sí que fui emplazando algunos tiles visibles, enemigos, plataformas móviles, puertas, puentes, y cambiando una parte del nivel donde había un Horus (las cabezas esas de chacal que te disparan si te ven) a ras de suelo, por arena y un excaver (el bicho ese que va bajo tierra y que sólo deja ver una cortina de arena). También coloqué un poco de agua y lava que hacía falta, y eso requería de pasos extra en el código.
Aun le queda mucho para estar terminado. Lo que es el diseño jugable está al 30%, y aun no tengo casi ningún tile de decoración hecho para el mapa visible. Me voy quitando poco a poco los detallitos de lo que ya está hecho, pero me dedico al nivel sólo cuando sé que voy a dedicarme exclusivamente a él, necesito entrar en un modo muy concreto de concentración si quiero que el nivel sea jugablemente interesante.

Y hablando de detalles, llevo tiempo mirando la lista de cosas pendientes y, aunque le dedico tiempo a algunas cosas de esta, es como si al final no hiciera nada, y encima se añadiesen cosas para terminar lo que ya hay... como si se multiplicasen las tareas, pero sin añadir nada a la lista ¿es eso posible? :S

Bueno, voy avanzando poco a poco, compaginando el proyecto, el trabajo y volverme histérico con el encierro forzoso :D
En realidad esto último no es verdad.

Buenas. Ya no toco el código tan a menudo, pero tampoco es que haya tenido demasiado tiempo. Entre semana estoy trabajando, ya sabéis.

Pero bueno, anoche me cogí un ratillo y se lo dediqué a preparar el código para que un amigo, que se aburre muchísimo por la situación actual de enclaustramiento, pudiera hacer sus pruebas con el juego, y de paso, me testease una pare del código fundamental para el nivel 2.
Básicamente he añadido código para cargar un nuevo nivel, con sus gráficos, sus mapas de tiles, etc... No fue demasiado problemático (menos mal) pero quizás lo podría haber hecho de otra forma.
Y ya está, eso es todo. Bueno, a ver si esta tarde empieza ya, y puedo ponerme a escribir un poco más de código o de lo que surja.

Hola a todos:

Perdón por el silencio de radio, pero he estado en una época de muchas incidencias en el trabajo, y luego prisas por el retraso que han provocado en otros proyectos. No estaba por la labor de ponerme a programar.
Pero sí que he ido haciendo algnas cosillas, aunque no las he comentado en su momento.

Hace cosa ya de dos semanas... o tres, no recuerdo bien, le dediqué un ratillo para poder terminar las momias. Si habéis probado el nuevo nivel, habréis visto una momia en la parte superior, cerca del final. Sí, la momia es inmune a todas las armas, pero ya comenté, creo, que está para que experimentéis un poquito antes de enfrentaros en serio a ellas en el 4-3. El caso es que a las momias les faltaba por implementar el "baile de sambito" random, es decir, esa especie de baile que hacen cuando chocan contra una pared, pero ahora lo pueden ejecutar aleatoriamente en cualquier momento, igual como pasaba en el juego en el que se inspiran ¿cuál? No os preocupéis, tendréis más pistas cuando complete el nivel 4.

Hace una semana, tuve un poco más de tiempo y estuve implementando un menú para modificar la resolución de pantalla. Tiene 3 opciones: la primera permite seleccionar por cuántas veces se va a multiplicar la resolución nativa del juego (320x240), desde x1 hasta x17, por si alguien está usando una tele 8K :D; la segunda opción son los filtros 2X, que sólo funcionan si se ha seleccionado multiplicar la resolución por dos, ya que, claro, son los filtros SCALE2X de Bennu; y la tercera y última opción es para poner el juego a pantalla completa o en ventana. Estas opciones se guardarán en el fichero .cfg de la carpeta save, y no hace falta que se borre la anterior. Eso sí, dicho menú sólo es accesible si se juega en PC, el resto de dispositivos van a resolución fija.
Y ya, de paso, le he metido un poco más de velocidad al cambio de opciones en el menú principal :D

Por último, lo que he estado programando hasta hace unos minutos. Aprovechando que hoy es festivo, me he levantado como si fuera día laborable... bueno, un poco más tarde, que anoche me dieron las tantas despierto :D Le he dedicado casi todo el día a implementar la IA de los secuaces del jefe final del nivel. Sí, más momias, pero estas, aunque comparten gráficos con las de los niveles anteriores, se comportan de forma radicalmente distinta a aquellas, de hecho, ignoran todas las leyes de la física (total, ya ignoraban las de la vida y de la muerte :D ). Me ha llevado horas conseguir que funcionen con una IA demasiado simple, pero creo que van a dar suficiente juego, especialmente si se sube el nivel de dificultad :D

Ya por hoy, estoy mentalmente cansado, y no sé si me dará tiempo a haer alguna cosa más, pero por lo menos, una de las tareas complicadas está tachada de la lista.
La siguiente es averiguar cómo hacer para que un tile sepa que el prota ha andado alrededor suyo :p

Buenas de nuevo:

Cualquiera diría que echo de menos el trabajo durante el puente, viéndome programar :D (espero que no :S).
Ayer le dediqué un rato a una de las animaciones más complejas que he hecho hasta la fecha... que viendo lo que es, no dice mucho a mi favor :S Bueno, el caso es que, si probásteis la última versión, habréis visto que se añadió lava como amenaza para el juego. La lava incluso estaba animada, pero claro, era una animación muy simple, en plan olas, y daba la impresión más de ser agua que otra cosa. Bueno, pues estoy trabajando en eso. Ya ralenticé la animación un poco para que parezca más espesa, pero es que ahora la estoy haciendo más burbujeante. Pues sí, estoy animando burbujas que crecen, se mantienen un par de frames y explotan. Tengo que añadir varias de esas burbujas, y hacerlas de diferentes tamaños.
Lo bueno es que en esta ocasión tengo una herramienta que me está ayudando mucho, llamada "Piskel". Permite crear animaciones, seleccionar los colores en una paleta interna, trabajar con capas... todo con herramientas muy sencillas, pero que me están facilitando el tener las cosas bien ordenadas, y no estar con 16 ventanas abiertas.

Hoy le he dedicado una hora y pico al código, concretamente a algo que programé hace tiempo y no tuve la oportunidad de probar: puentes y suelos que se abren al disparar a un botón. Naturalmente, el código falló... pero no por el código en sí: he detectado un fallo que no se había dado hasta ahora, y es que cargaba los gráficos del scroll después de iniciarlo. Esto se hacía así porque hay algunos tipos de mapas de tiles que pueden cargar su propio FPG, pero como no es el caso, me he podido permitir hacerlo al revés de lo normal. ¿Cuál era el problema? Que en el primer frame, el scroll tileado generaba distintos procesos que se quedaban "huérfanos" (dependían del proceso de control), estos eran las puertas, puentes y demás, y al generarlos se les asignaba el file del tscroll, que en ese momento está a 0. Al cambiar el orden, el FPG se carga y pueden ser asignados a estos procesos.
Ya sólo me queda generar los correspondientes tiles, y añadirlos al nivel, y ya tendremos una nueva mecánica jugable.

Poco a poco, pero vamos avanzando... salvo por la parte del boss, que aun no sé cómo plantear lo de rodear los tiles.

Esta entrada que estoy escribiendo, bien podría haber sido una edición en el mensaje anterior, porque tan pronnto como terminé de escribir aquellas líneas, se me encendió la bombilla :D
Le había estado dando muchas vueltas a cómo hacer lo de rodear los tiles: si usar una función con la posición del tile, si que fuera el propio proceso tile el que se encargara de la comprobación, si leer el mapa de durezas, el mapa visible, si usar un array bidimensional privado... En todas y cada una de las ideas encontraba un problema, como pérdida de rendimiento, o que en los mapas de tiles había datos que no podía escribir porque ya había un dato importante para el prota.

La solución fue crear un array bidimensional privado, del mismo tamaño que el mapa de tiles (que tampoco es que fuera muy grande) y hacer las comprobaciones en el mismo proceso. Las comprobaciones se harían cada vez que el prota cambiase de tile, y sólo a aquellos suficientemente cerca del nuevo tile (antes lo planteaba al revés, si eran los tiles los que estaban suficientemente cerca del prota, o dentro de un rango de alcance... bueno, no me voy a enrollar porque si tengo que hablar de todas las ideas rechazadas podría escribir tres capítulos de un libro de algoritmos de programación :D)

El caso es que pude implementarlo esa misma noche, en apenas una treintena de líneas, y probarlo al día siguiente (y por spuesto corregir los 40 fallos tontos que había cometido). Ya casi está la parte jugable del boss terminada, al menos, un boceto, pero lo suficiente como para comprobar que va a ser divertida, o casi tanto como el juego original (aunque con un giro diferente, como pasó con el boss del Pang, al poder saltar y disparar de lado :D).
Lo que pasa es que, como al juego original, rodear los tiles no basta, el jugador necesita feedback, y si no marco las casilla por las que ya se ha pasado, la tensión puede desquiciar a los jugadores más impacientes. Y en eso estoy, generando las "marcas", nuevos gráficos que no estaban previstos, que me están quedando muy bien... y que no consigo que se vean, no sé por qué.

He cargado el FPG, se hace de forma correcta, he asignado el file adecuado, los graphs están bien... de hecho, funcionan si le pongo otro FPG cargado al mismo tiempo, pero es como si el que le estoy pasando no le gustase, y no entiendo el por qué.

En fin, hoy ya había programado mucho, cosas muy complicadas de C# y Xamarin, y sólo le dediqué poco más de media hora, no estaba de ánimos para seguir depurando cosas, así que espero poder corregirlo mañana, si la horda zombie que inunda las calles no se comen mi cerebro cuando salga a comprar :D
Voy a acostarme, a ver si descanso algo, que llevo sueño retrasado.

Que descanseis.

Bueno, de momento quiero informaros que el desarrollo va avanzando, poco a poco, pero van saliendo cosas.

Antes que nada, decir que al poco de escribir las líneas anteriores, empezaron a rondarme sospechas de por dónde podía venir el fallo. En esta ocasión no tenía nada que ver: el FPG estaba bien construido, se cargaba... pero en cuanto puse un par de SAYs ya cantó el fallo.
Cuando digo que para hacer debig no se debe dar nada por sentado, quiero decir nada, ni siquiera que 1+1==2. Efectivamente, el FPG cargaba, pero el FILE que se le asignaba a los nuevos procesos no era el mismo. Fue entonces cuando caí en la cuenta de que había dos FPG que estaban guardando su ID en la misma variable. En cuanto creé una nueva, todo resuelto.

Bueno, de vuelta al tajo, he seguido haciendo las marcas que mencionaba anteriormente. Necesitaba un buen número de ellas, para evitar la monotonía, y además quería darles un efecto guay, por lo que además de crear 11 gráficos de 16x16, tuve que utilizar GIMP para decorarlos un poco.
Por otro lado, necesitaba más gráficos para el boss, y con eso he estado. Me he pasado más tiempo con Paint y Gimp que con Notepad++. Incluso hace unos minutos estaba desarrollando más gráficos, y es que este boss está tomando ya la envergadura de un juego en sí mismo, corto, pero prácticamente un juego dentro del juego, y algunos nostálgicos lo van a agradecer, sobre todo por el cambio de mecánicas :D

Además, dado que todo se ambienta en Egipto, he tenido que documentarme y dar un curso acelerado de jeroglíficos... más que nada, porque conozco a cierta "egiptóloga", que si no hago las cosas como Ra manda, me pega :D :D :D
Me ha servido para poder ir haciendo algunas de las decoraciones. De momento de parte de la sala del boss, pero confío en que pueda usarlos a continuación en el nivel 4-3.

Además, un colega, que voy a tener que añadirlo a los créditos por su labor de testeo, me ha pasado algunos SFX que me van a hacer falta, aunque no sé si usaré esos o si podré currarme una versión propia.

En fin, que esto me está tomando mucho más tiempo del que pensaba. Creía que podría tener el nivel terminado en un mes, y toda la segunda temporada estaría para finales de este, pero bueno, aun estoy así, y tampoco le puedo meter mucha más prisa, al fin y al cabo, esto es un hobby, no me pagan por ello. Aun quedan 4 bloques importantes que programar para terminar el boss, y la mitad del nivel 4-3, al que tengo que añadir nuevos elementos jugables, los tiles decorativos, y pensarme qué enemigos quiero meter además de los dos o tres que ya están.

Buenas Drumpi, ya lo he descargado y luego lo pruebo. Veo que sigues el desarrollo después de tantos años tiene mucho merito. Felicidades y gracias por tu trabajo. karma up. Saludos!

Muchas gracias, blostec. Ya me contarás qué te parece el juego y en qué se puede mejorar.
Ya lo del mérito... :D Cuando tienes a dos o tres personas diciéndote "vamos a hacer un juego como el Echo pero sin Echo" al final terminas por seguir con el Echo :D

Pero me alegra ver que no soy el único que se pasa de vez en cuando por el foro :D

Volviendo al meollo... lo siento pero, sin comentarios. Este fin de semana no me he puesto con el ordenador. Me han surgido un par de problemas que he tenido que ir resolviendo. Uno ya no está en mis manos y el otro estoy a la espectativa :P
He intentado seguir con los gráficos. Al no ser grafista, me cuesta mucho ir rápido con ellos, y si mi estilo ya es minimalista... Y es que ese es el problema, estoy en una fase que, intente hacer lo que intente hacer, me encuentro con que necesito gráficos ¿El boss 4? Gráficos ¿El arma para derrotar al boss 4? Gráficos ¿Las plataformas que aparecen y desaparecen? Gráficos ¿Más del nivel 4-3? Gráficos ¿Los gráficos de los tiles que se rompen al pisarlo?...
Lo único que puedo seguir haciendo sin gráficos es debug de algunos fallos en la detección de durezas, pero para dureza lo que estoy haciendo en el trabajo, que a pesar de estar copiando código, no responde y ¡¡AAARGH!!

En fin, necesito un respiro. Voy a darle un poco de oxígeno al proyecto y lo iré retomando cuando pueda, y cuando mis neuronas me lo permitan. Quería haberme puesto hoy, que es fiesta local (la cancelada Feria de Abril) pero como siempre, hay una lista de tareas ajenas a mi pendientes de mi tiempo. A ver si este puente puedo hacer algo.

Ánimo chaval, ¿pa que me voy a ofrecer de grafista si ya hice los del plactom? je je

Pos eso, que con los del punkarra me felicitaron, es tambien como te coja el momento, hay momentos de lucidez que todo sale bien y otros que está uno mas espeso que que...

Pues me temo que de momento el proyecto está en stand-by. Llevo una temporada que me siento más cansado de lo habitual, y cuando llega la hora de "salir del curro" (teniendo en cuenta que ahora mi oficina es la misma habitación donde duermo, lo de salir es relativo), lo último que me apetece es seguir con el ordenador. Ya ni programo, ni gráficos, ni Blender, lo único que quiero es sentarme y descansar, incluso sólo ponerme a leer, ni consola siquiera.

Pero bueno, mejor eso que hacerlo con desganas, porque eso se nota en el producto final. Ahora me ha dado por el diseño de niveles en cartulina de un proyecto que tenía aparcado desde hace unos pocos años, y hace unos días estaba haciéndome unas gafas de VR para el móvil con cartón, de diseño propio (con estas gafas puedo ajustar la distancia entre los ojos, y la de las lentes a la pantalla :D ).

Volveré a ponerme con el juego en cuanto consiga recomponerme un poco. Espero que no sea a más tardar porque ya estaba bastante encarrilado el nivel, y aun quedan otros dos por hacer para dar por concluida la versión 1.4... al menos, hasta donde estaba previsto (lo suyo es incluir el nivel 2, pero como ya he dicho, el cambio de jugabilidad va a requerir de mucho tiempo de desarrollo).


Futu, como ya te dije, el problema del plactom ese no es que me mandes 200 tiles para un nivel, primero porque sólo puedo añadir un máximo de 95 por nivel :lol: , y segundo, porque hay varios niveles y hasta ahora tengo sólo 2 sets de tiles, 3 si separamos los del primer set entre madera y "metálicos"... y aun así, realmente, no sé cuántos sets necesitamos realmente :D
Además, te lías a mandarme gráficos, pero no haces los que te pido, y los cambios que te sugiero se te olvidan a los 10 segundos :P
Jajajaja.

ja ja, es lo que tiene trabajar de grati, lol

Pues si esperas que te pague por un proyecto del cual eres el director, lo llevas claro :D

En fin, la cosa sigue en stand-by. Poco a poco parece que recupero las ganas, pero no durante la semana. Hay varias partes a las que me gustaría meterle mano, pero siempre hay algo... más o menos complicado que me retiene: quiero hacer una nueva "arma" (entre comillas, porque no es permanente) pero no puedo porque programar la estación de recarga requiere de cierta animación y una modificación medio complicada de hacer en el mapa; quiero seguir con el nivel de la pirámide, pero no puedo porque tengo que probar los nuevos elementos de jugabilidad y reformular parte del nivel para incluirlos; quiero terminar con el boss del nivel pero tengo que comprobar la IA...

Bueno, si salgo del interbloqueo, seguiré avanzando en el juego... pero es que mi jefe me tiene frito con las prisas y con que me ajuste a los tiempos :S

Hola a todos:

Parece increíble que hayan pasado 3 años desde la última vez que toqué el código del Echo. Un año, vale; dos, ya me genera dudas ¿pero tres? :S
Bueno, teniendo en cuenta que el máximo de tiempo que le dedicaba a programar juegos, fuera de una GameJam, eran tres o cuatro horas, y que ahora me paso alrededor de 9h en el trabajo, creo que se entiende este parón.

El caso es que el jueves pasado, aprovechando que era fiesta, y no sé si movido por la inercia de trabajar entre semana, me dio por abrir el código del Echo y echarle un vistazo.
Se me ocurrió que podía dedicarle unos minutillos a escribir un poco de código, y eso se convirtieron en un par de horas.

Total, que en ese día, escribí suficiente código para que, a falta de algunos efectos visuales (ya sabéis: gráficos), se revelase el jefe del nivel 4 en toda su ¿gloria? A ver, no dejaba de ser una momia como las que ya había hecho (en especial, las últimas que mencionaba, que desafiaban la ley de la gravedad), pero en color morado (sí, me puse a recolorear sprites también ese día), por eso, la parte épica como que se resentía un poco :D

El caso es que esa parte está hecha, y también otra parte del boss, que no quiero revelar para no arruinar la sorpresa.

La buena noticia es que no ha sido cosa de un día. El fin de semana y los últimos dos días le he podido ir dedicando algunos ratillos sueltos y he podido seguir avanzando. No gran cosa, pero mejor eso que nada.

El caso es que al día siguiente estuve solucionando diversos fallos que había detectado en la lucha con el boss:
La generación del mismo no estaba teniendo en cuenta el scroll y algunos elementos se quedaban "pillados" al moverse.
Por otro lado, el combate tiene lugar en diversas "fases", y es necesario recargar y modificar el escenario tras cada una de ellas. Tenía un código provisional para probar el cambio, pero no era, ni de lejos, todo lo que había que hacer, y le dediqué bastantes minutos a añadir y corregir cosas. Aún no he terminado esta parte, pero es porque tampoco está implementada toda la lógica del combate.
El boss tampoco respondía correctamente. Por alguna razón, además de "volar", le dio por atravesar paredes. Vale que tenga poderes sobrenaturales, pero el "modo Dios" sólo lo puedo tener yo :D

Con todo esto, ya podía hacer una simulación de lo que será el combate completo (salvo porque aún no hay "arma" para vencer al boss, y no se le puede derrotar... aún), y estuve un buen rato probando, y cuando llegué a la última parte, un escalofrío recorrió mi espalda, una sensación que hacía mucho que no sentía, mezcla de nostalgia, diversión, y orgullo por un trabajo bien hecho. ¿Recordáis esa sensación cuando vuestro primer sprite se movía por la pantalla? pues algo así.

Y así llegamos a la última parte del diario de hoy. Anoche, por fin, di por finalizada la animación de la lava. Como ya comenté, estuve usando Piskel, y es una herramienta muy útil para hacer pequeñas animaciones en pixelart. Me ha llevado su tiempo, porque si ya me cuesta hacer gráficos, animaciones ni os cuento. Creo que ha quedado bien, pero aún no he podido probarlo in-game, así que a ver si hoy saco un ratillo y lo pruebo.

Aún quedan cosas para terminar el boss 4, y el nivel hace mucho que no lo toco, por lo que tengo que revisar qué está hecho, qué falta, qué hay que cambiar para añadir las nuevas mecánicas con las que estuve experimentando los últimos días, y añadir la decoración del nivel, porque de momento, estoy usando los tiles más básicos de suelos, paredes y rampas, y quiero que quede todo muy bien ornamentado :)

falta el diario de gp32spain

No, ya avisé por allí que he escrito esto.
Ten en cuenta que el diario de desarrollo oficial es este :D

jaja faltaria mas, fallar en gp32

¿Qué culpa tengo yo de que os hayáis ido todos a Discord? No puedo instalar el programa en el ordenador del trabajo, y no me voy a poner a usar el móvil. Al menos, puedo consultar los foros en modo oculto :D :D :D

PD: ayer empecé una pequeña animación, pero no hice mucho porque apenas le dediqué media hora :D

Bueno, pues creo que por hoy voy a terminar, y me voy a viciar un rato a la consola, que creo que me lo he ganado :D

Pues nada, estos días he estado, por un lado, de testeo de lo que ya había hecho.
Por otro lado, con la animación que decía, y como el boss ya está funcionando... o casi, porque he descubierto un caso por el que vuelve a atravesar paredes (las momias y su manía de no respetar las normas que les imponen los dioses). Bueno, como decía, como el boss ya está (casi) funcionando, el siguiente paso es que interactúe con los disparos, pero como ya dije, sólo le afecta un "arma" y claro, tengo que hacer que Echo pueda cogerla. Así que el trabajo de este fin de semana ha sido prepararlo todo para que Echo pueda conseguirla: añadir hueco al inventario, preparar la interfaz, arreglar los 40 errores que han salido por intentar leer fuera de los límites del array o de procesos que no existen...
Veo que he aprendido mucho desde que escribí el código del Echo (y lo medio desastre que era cuando lo hice ^^U), y desde luego, Notepad++ no es la mejor forma de programar, después de haber usado VS y su autocompletar, sus accesos directos a funciones, etc... pues se hecha de menos, pero aún tengo mis trucos bajo la manga (más difíciles de encontrar, porque con el calor, voy en manga corta).

En fin, que, en principio ya están hechos los dos huecos, y creo que tengo las versiones definitivas de los iconos y... espera ¿dos huecos? Pues sí, si habéis jugado al desierto, seguramente hayáis encontrado la cueva secreta en la que hay un pedestal vacío. se suponía que iba a contener un nuevo arma que, por falta de tiempo, no se pudo añadir ni en el tercer concurso al que se presentó ni en la edición del 10º aniversario.
Y he ahí una de las razones por las que se interrumpió el diseño del nivel 4-3, esta arma tiene una característica especial, que afecta a la jugabilidad, y quería añadirla en este nivel, además de otros como plataformas, los puentes retráctiles, los interruptores que se pueden desactivar...
Así que mis próximos objetivos deben ser elaborar las dos armas, de forma que me sirva una para terminar el nivel 4-3, y la otra para hacer daño al boss.

Aparte de eso, también he estado trabajando en algunos gráficos. Uno de ellos es para la zona del nuevo arma, y por otro lado, los iconos de estas. De momento sólo me he dedicado a mis gráficos, pero supongo que tendré que dedicarle un rato (muy largo) a crear las versiones stylish, ya que Fede no anda con ánimos de añadir más gráficos al juego.
Lo cierto es que eso me pone en un compromiso, porque yo no conozco las herramientas que él usa, ni sé si voy a poder imitar su estilo, y si tengo que intentarlo, me iba a retrasar muchísimo, y no quiero que eso pase, por lo que es muy probable que me vea forzado a eliminar los gráficos stylish del juego. De momento lo dejo en el aire, a cuenta de que quiera retomar su trabajo, o encuentre quién le sustituya.

Y algo parecido me pasa en el apartado sonoro: Caleb anda desaparecido... bueno, ha aparecido recientemente, pero ya me dijo que perdió los "fuentes" de las músicas que hizo, y no lo veo por la labor de continuar. Princemegahit también se ofreció cuando lancé la versión aniversario, pero también me ha dicho que anda corto de tiempo, por lo que me toca a mi hacerme responsable de las músicas. Ya no sólo es que tenga que crear melodías para el nuevo nivel, sino que tengo que recomponer melodías para alternar con las de los niveles previos.

Pero bueno, son muchas cosas las que hay pendientes, y mirar la lista de lo que falta sólo va a hacer que abandone antes de empezar, así que vamos a ir atacando a los problemas uno a uno, a medida que me vaya apeteciendo hacer una cosa u otra. Como dije, mi objetivo es terminar el boss del nivel 4, y luego el nivel, y para ello, mi tarea más inmediata es hacer el arma que lo matará (otra vez), y de paso, pues a ver si puedo hacer el otro arma y mato dos pájaros de un tiro... pun not intended.

Bueno, otro fin de semana y con ello, algo de tiempo para dedicarle al juego.
Entre semana me ha sido imposible, porque aparte de que por la tarde llego sin ganas ninguna de ponerme al teclado, también he estado liado, y por la noche... con el calor que ha hecho, ya me costaba suficiente dormirme, no era cuestión de echar más leña al fuego.

En fin, a lo que vamos: sí, he seguido con el tema del arma. Por desgracia los avances son bastantes escasos vistos desde fuera. He dedicado la mayor parte del tiempo a crear los gráficos, tanto de las armas en sí, como sus explosiones, disparos, gráficos para la animación de conseguirla... ya tenía el diseño de una, pero para la otra, la que acabará con la momia, tuve una inspiración cuando el sábado me pasé por una exposición de momias escaneadas por tomografía de alta resolución: una de las piezas expuestas era un ojo de Ra, y tenía una forma que era ideal para un arma automática, así que la usé de base.

El problema es el arma que se podrá coger en el nivel 4-1. Os puedo adelantar que es una especie de granada, que servirá para romper algunas paredes (tranquilos que las que sean obligatorias tendrán un gráfico con grietas que las distingan... aunque no prometo que no añada paredes rompibles que no se distingan :D ) y esto me da varios problemas:
Por un lado, no sé cómo gestionar la limitación de su uso: es un arma muy potente que puede eliminar varios enemigos a la vez, o causar daño a los jefes, por lo que lo normal es que tenga un contador que indique cuántas se pueden usar. La pega es que si romper paredes forma parte de la mecánica principal del juego, no puedo dejar al jugador sin granadas cuando es lo único que le permitirá seguir. Creo que puedo poner lugares de recarga, pero lo dicho, son demasiado potentes para que se disponga de un uso ilimitado... no sé cómo plantearlo.
Por otro, el gráfico de la explosión que he hecho tampoco me convence, y me tiré como dos horas el sábado con ella. La explosión tiene un radio de 6x6 tiles, y usará dos gráficos giratorios con transparencia... aunque me estoy planteando que funcionen de forma diferente.
De hecho, he planteado muchas cosas que no sé si cambiaré: se podrá lanzar en 8 direcciones, habrá un medidor de fuerza para lanzarlas, y no tengo claro si detonará por tiempo o al chocar (esto último puede ser muy problemático por la cantidad de procesos con los que podría interactuar, y aquí hecho de menos la herencia de C#).

Encima, no pude usar DIV2 para generar los gráficos de cuando se consigue el arma (la máquina virtual que usaba para ejecutarlo ha dejado de funcionar :S), y tuve que improvisar con lo que tenía. No ha quedado mal del todo, pero aún necesito retocarlo un poco, y he perdido como una hora y media haciéndolos, lo cual es una barbaridad de tiempo, teniendo en cuenta el que le dedico a la semana.

Pero bueno, finalmente el arma está en su sitio y ya se puede coger. Aún no se puede usar, y dadas las dudas que tengo, casi que mejor. A ver qué pienso esta semana.

A parte de las armas, le estuve echando un vistazo al nivel de testeo, que hace eones que no lo veía, y lo necesito para hacer las pruebas de las armas. Ya de momento la "granada" se ve enorme en las manos de Echo, es casi tan grande como él :D Lo cual es hasta gracioso, y sería muy útil para el caso en que el "problema" que compense la potencia de la granada, sea el tiempo que se tarda en poder lanzar la siguiente. Con una granada tan grande se puede ver el momento en que se puede lanzar otra de forma más fácil.

En fin, tengo unas cuantas cosas en las que pensar. Cualquier idea es bienvenida.

Lo siento por el silencio de radio, pero este fin de semana me ha sido imposible dedicarle tiempo al Echo. Tuve que salir para arreglarle algo a mi madre y estuve todo el fin de semana liado, y eso incluyó algunos días previos al viernes.
Además, ya lo dije, tampoco es plan de ponerme entre semana a las tantas de la noche a programar si tengo que madrugar para ir a trabajar :D

De momento, lo único que puedo contar (porque no he hecho más) es que he reducido el tamaño de la nueva bomba, a un tamaño más manejable por Echo, aunque creo que, definitivamente, voy a usar el sprite de 11x11 para cuando la granada llegue al nivel 3. Me interesa que el jugador pueda saber cuándo se ha llegado a ese nivel porque va a funcionar de forma diferente: como ya comenté (creo), la idea es que en nivel 1 la granada explote por contacto, con un radio mínimo; en nivel 2 la explosión será mayor, pero la granada se quedará pegada un par de segundos antes de explotar; y el nivel 3, el radio de explosión va a ser muy considerable, pero la granada rebotará en las paredes y explotará con el tiempo, y por eso me interesa que el jugador sepa cuándo la granada se detendrá en su destino o cuándo va a empezar a dar vueltas por ahí.

Pues eso, que he hecho un sprite más pequeño y que lo he estado probando, a ver qué tal se veía... y de paso he revisado el evento al conseguir dicha arma.

Por otro lado, me he puesto a mirar el código de control del arma, para añadir lo que necesita la granada para funcionar. Hay muchas cosas que quiero agregar, porque quería implementar un medidor de fuerza, por lo que tengo que poner el medidor, moverlo para que apunte en la dirección de lanzamiento, implementar los distintos estados (reposo, cargando, lanzar, ¿tiempo de recarga?)... Así que, como le dedico ratos sueltos, y quiero ir por partes, he cogido y he creado una estructura básica en el código, que no es más que la "máquina de estados": he planteado las 4 zonas, una por estado, y qué tiene que pasar para cambiar de una a otra (pulsar el botón, soltarlo...), aunque no están todas aún. Luego, entre comentarios, he puesto qué se tiene que hacer en cada una de las secciones, y la idea es ir sustituyendo cada comentario por su código, de esta forma sé lo que tengo que hacer en cada momento, lo que me falta, y programar aquello que me apetece en ese momento.

Creo que es la primera vez que empleo este sistema. Por lo general suelo tener la lista de cosas por hacer en la cabeza o en un documento de texto. A ver qué tal sale.

Debería intentar terminar con la granada este fin de semana... aunque debería terminar con el arma del boss para poder ir terminando esa parte, pero bueno, soy muy veleta y prefiero programar según me apetece en ese momento, especialmente si sólo tengo un rato, porque no me gusta ponerme con las cosas difíciles sin haber "calentado" previamente con algo sencillo.
En fin, ya lo iremos viendo. No quiero adelantarme porque no suelo cumplir mis propios plazos, ya sea por una cosa o por otra, y este mes creo que voy a tener un poco más de tarea de lo habitual, y cuando me vaya de vacaciones, voy a dejar los ordenadores aparcados, para descansar un poco de ellos.

¿Nunca os ha pasado que no teníais ganas de sentaros delante del ordenador, que te obligas a escribir, al menos, 15 minutos de código, y cuando te das cuenta, llevas una hora? Pues eso mismo me pasó ayer. Tenía como 30 minutos antes de tener que ponerme a hacer la cena, y no me apetecía mucho ponerme a programar, pero tampoco quería desaprovechar el tiempo libre que tenía jugando a una consola.

Total, que encendí el ordenador, ya más o menos con las ideas de lo que quería desarrollar, y empecé a escribir algo de código. La guía que creé ayer fue de mucha ayuda, porque sabía dónde tenía que meter mano. Quería preparar, al menos, la flecha que indicaba la dirección y la fuerza hacia la que tirar la granada (más sobre esto, después), y pensaba que sería fácil, con unas 5 o 6 líneas y se acabó... pero como andar con trigonometría, ángulos, denos y cosenos era un engorro (y recordemos que la Wiz ya está lo suficientemente saturada como para meterle cuentas difíciles), preferí hacerlo "a la antigua", y eso implicaba escribir mucho más código.

Empecé colocando la flecha, luego haciendo que mirara en la dirección correcta, luego trasladé el código a los otros estados, añadí el indicador de fuerza y cuando me quise dar cuenta... estaba programando en la oscuridad ^^U
También había avanzado mucho más de lo que me había propuesto: puse la flecha señalando hacia dónde iba el lanzamiento, un medidor de fuerza que crece mientras mantienes el botón pulsado, e incluso que descontase la exp del arma al lanzar la granada. Sólo faltó precisamente eso, lanzar el nuevo objeto, que está sin programar, y el tema de la "recarga", o sea, poner un tiempo entre que se lanzó la granada y se pueda lanzar la siguiente. Para lo primero, tengo que repasar el código de los objetos que aumentan la experiencia del arma, ya que el comportamiento es similar (hasta la parte en que explota).

El caso es que, estaba haciendo las pruebas, y algo que me empezó a preocupar ayer se hizo visible en ese momento. Estoy dudando si el tema de tener que "cargar" el lanzamiento es buena idea o no. Eso obliga al jugador a ser previsible, y estar pulsando el disparo antes del momento de lanzar la granada, y además, a coordinarlo con la fuerza justa para que alcance su objetivo. Y lo peor de todo, moviéndose todo el rato, porque mientras cargas el arma, echo se sigue moviendo, y tienes que mantener los cursores pulsados para definir la dirección de lanzamiento.
Aún no he hecho las pruebas pertinentes, quizás le estoy dando demasiadas vueltas y es el comportamiento normal de este tipo de disparos, pero no dejo de preguntarme si hay forma de simplificar esto. No sé, por ejemplo, que no haya indicador de fuerza, y todos los lanzamientos son iguales de fuertes. O que mientras cargas, que no te puedas mover (sería complicado de programar, tal como está la cosa, pero tendría que mirarlo). No lo sé, hasta que no pueda lanzar cosas en un entorno controlado, no tendré la certeza de estar haciendo lo más cómodo para el jugador.

También hay que tener en cuenta que las granadas son un arma que sólo usarán bien los expertos, porque tenerlas en su máxima potencia es muy complicado: no solo pierdes EXP al ser golpeado, sino que también, cualquier uso de ella reduce dicho indicador. A eso le sumamos que la barra de EXP sólo tiene 10 unidades (¿eran 10 o lo bajé a 9?), y sólo las 3 más altas te permiten lanzar el verdadero "Solar Blast". A cambio, estamos hablando de una explosión de 6 tiles de diámetro (96 pixels), que causa 12 puntos de daño (frente a los 10 que hace la Leaf Blade a máxima potencia) a todos los enemigos a los que alcanza, y que puede permanecer suficiente tiempo como para volver a dañar a los enemigos a los que ya ha hecho daño.
...Aunque esto último debo revisarlo, creo que los enemigos, al colisionar con un "impacto de arma" (un proceso secundario que llevan todas las armas para hacer colisión... o así lo recuerdo), reducen la energía del impacto para que así muera, y si eso pasa, la onda expansiva sólo podría afectar a 1 enemigo por frame. Crear un nuevo tipo de colisión significa añadir el mismo código a más de 25 tipos de enemigos.

Y eso es otra cosa que me preocupa: tengo que hacer que la granada, en sus dos niveles inferiores, explote al impactar con un enemigo, y no puedo ir haciendo collision con todos los tipos de enemigo que existen (por un lado, porque como digo, son muchos tipos, y segundo, porque sería usar demasiadas veces "collision" y eso va a penalizar el rendimiento).
Aunque acabo de recordar que tuve hace tiempo una idea, y la voy a escribir para que no se me olvide: que la granada tenga un "impacto de arma" activo, con 1pto de daño. Así, al acercarse a un enemigo, este recibirá un daño inicial que los de alrededor no, "matará" al impacto, y eso activará la explosión. De nuevo, tengo que revisar el tema de la invulnerabilidad de los enemigos tras recibir un impacto... y creo que la Leaf Blade tiene mucho que decir al respecto.


Por último, quería anotar algunas ideas para usar a Doggy en el juego, tal como mencioné en el foro de GP32Spain, pero este mensaje se ha alargado mucho más de lo esperado, así que lo dejaré para otra ocasión.

Bueno, otro fin de semana, y otro empujoncito al juego. No demasiado porque tampoco le he dedicado un montón de horas, pero han sido productivas.

Me he centrado de nuevo en una de las nuevas armas: la Solar Blast. Ya hablé de ella, y finalmente he conseguido que en el nivel 1 explot... desaparezcan al contactar con una pared, porque no me he puesto a crear la animación de la explosión, aún (ya sabéis que me cuesta mucho ponerme a dibujar, y más a animar). También que en el nivel 2 se pegue a las paredes y, al cabo de un momento, explot... desaparezca.
Las del nivel 3 también rebotan contra paredes, suelo y techo (más sobre esto después), y al cabo de un rato, explotan... sí, estas sí explotan. No me gusta el gráfico de la explosión ni el tamaño de la misma, pero sí he conseguido darle el efecto que quería.

Por desgracia he tenido que prescindir del lanzamiento en 8 direcciones. Hice pruebas y era anti-intuitivo, no conseguía lanzar las bombas a donde quería, y encima, al tener que cargar el disparo, tenía problemas para mantener todos los botones funcionando a la vez. Total, que hice otra prueba y, finalmente, el funcionamiento será similar a las armas: las bombas se lanzarán en arco tanto a izquierda como derecha, con las únicas excepciones verticalmente, tanto arriba como abajo. Esto será muy útil a la hora de disparar al suelo mientras se salta de una plataforma a otra. Aún tengo que ajustar el tiempo de carga y el arco, pero de momento funciona.

El caso es que me ha retrasado mucho más de lo esperado. Hace mucho que no leía el código y se me habían olvidado algunos detalles, y en programación los detalles son imprescindibles. Tras un rato de experimentación y de leer código, ya lo entendí y pude arreglarlo todo (la mitad del tiempo de ayer fue solucionando problemas).


Lo peor pasó el sábado: mientras programaba, en una de las pruebas, en concreto, en la parte donde se lanzaban las bombas, vi que era muy divertido intentar lanzarlas y acertar a una posición concreta, y se me empezaron a ocurrir un montón de situaciones en las que sería muy útil tirar una bomba por encima de una pared, hacer que esta rebote... era como un minijuego en sí mismo... pero no era lo que buscaba. De hecho, sería interesante que se puedan lanzar con un apuntado básico mientras se corre, o bien, cuando se está quieto, poder apuntar con precisión y con la fuerza necesaria. Y que además, se puedan detonar con una segunda pulsación.
Y entonces esto me planteaba un dilema: usar las bombas que ya tenía planificadas, que tenían su utilidad, o estas nuevas, que daban mucho juego... y como tengo el cerebro simétrico, pues no me decidía. Aún hoy tengo mis dudas y, cuanto más lo pienso, más me gusta la idea de las nuevas. De momento he seguido el plan trazado, y he dejado una copia de este tipo de granadas por si quiero usarlas.

Aún tengo que sopesarlo, pero no me gustaría escribir código que no voy a utilizar, dado el tiempo que tengo. También me gustaría oír opiniones, ya sea por este foro como por el otro. Ya digo que me tiré un buen rato lanzando granadas sólo por diversión :D

...aunque se me está ocurriendo que se pueden fusionar ambas ideas... que las bombas, aparte de explosionar por tiempo (o no), que se puedan detonar con una segunda pulsación... Mmmm

No, no se ha parado el desarrollo (de momento). Es sólo que esta semana no he tenido tiempo de ponerme a escribir los avances del fin de semana pasado. Teníamos una entrega en el trabajo a un cliente y... bueno, que se ha liado la cosa.

Por desgracia, esta semana no tengo muchos avances que contaros. Si la semana pasada estuve probando el lanzamiento de granadas e implementando los 3 niveles diferentes de uso, en esta estuve haciendo ajustes a la explosión, pues como creo que ya comenté, me la esperaba mucho más grande.
Así que estuve experimentando con diferentes tamaños, lo cual me llevó un buen rato hasta que di con el que andaba buscando, y tras eso... me entró una depresión ¿tenía que rehacer el gráfico? Uff, qué pereza. Me llevó casi una hora, no pensaba repetirlo. Así que hice un reescalado guarro, y lo dejé a modo de guía, hasta que se me ocurra cómo mejorarla. Eso me llevó a otro problema: no tenía las animaciones de las explosiones medianas y pequeña, y como no andaba con ánimos (ni ideas) para gráficos, lo dejé aparcado.

Lo que sí tenía que ir haciendo era el proceso de colisión que afectaría a las paredes y enemigos, así que me puse a programarlo, a crear sus gráficos de colisión (unas circunferencias que tendrán alpha = 0), a sus invocaciones y a probar. Cuando ya tenía su tamaño definido, y el tiempo de duración, me puse a programar los tiles que se podrían romper con ellos y... Bueno, programados están, pero no los he añadido al mapa de testeo ni los he probado. Ese es el siguiente paso.

También tuve que reordenar algunos gráficos, de cara a añadir los gráficos de colisión, de explosión y una pequeña animación para indicar que la bomba está a punto de explotar por expirar el tiempo.

Desde entonces, ha sido una cosa detrás de otra y no he podido ver si la cosa funcionaba (al menos, de forma burda, sin animaciones ni efectos). Creo que tengo pensado cómo animar la rotura del tile, pero eso será a partir de mañana.
En fin, que eso es lo que hay. Poco a poco, pero avanzando. A ver si termino ya la granada y me pongo a... no sé si será hacer las modificaciones para usarla en los tres subniveles correspondientes, o a programar el arma para liquidar al boss. Ya veremos.

Perdón por el silencio de... ¿radio? Bueno, el caso es que tampoco hay mucho que contar, porque estos días he estado muy liado por temas ajenos, ya no sólo del trabajo.

Pero vamos a lo que importa.
Sí, finalmente empecé a probar las colisiones, y por supuesto, no funcionaban, así que me tiré un buen rato intentando ver por qué fallaban. Cuando lo hicieron, pues me dio por ponerme con la rotura del bloque: hice una animación sencilla, básicamente creé cuatro procesos que eran lanzados en 4 direcciones, a los que les afectaba la gravedad, y al llegar a la parte de abajo de la pantalla, desaparecían. Hice algunas pruebas, con diferentes tamaños, diferentes velocidades y diferentes velocidades de rotación y quedó algo curioso, mucho más vistoso que el que desaparezcan los tiles sin más.

Hablando de lo cual, y después de ajustar mejor los tamaños de las explosiones, me puse a probar qué tal se manejaría el lanzamiento de bombas. Creo que ya lo expliqué antes, pero tengo problemas con la carga del disparo, porque el teclado no me permite usar Z, X y dos cursores al mismo tiempo, lo cual es extremadamente problemático. Tengo que darle una vuelta a eso y buscarle una solución cuanto antes, porque si no, voy a tener que prescindir de la fuerza de lanzamiento.
Pero a pesar de eso, estuve probando con una pared de ladrillos, y hay una jugabilidad interesante ahí, teniendo que saber cómo romper los ladrillos, y teniendo puntería, para poder hacer escaleras, pasadizos... me ha molado, y me ha traído recuerdos del Tails Adventures.
De hecho, si os acordáis, ya mencioné que había desarrollado otra bomba antes que la de ahora, que me había salido por accidente. Pues si hago que se pueda detonar con una segunda pulsación del botón de disparo, pues tenemos las bombas remotas, y eso da muchísimo juego. Me gustaría poder añadirlas más adelante como las "Fox bombs" o algo así.

Poco más he hecho dese entonces. He podido comprobar que los disparos normales también me habrían servido para romper las paredes (en un análisis previo, me decía que no, que estos colisionaban con la pared y perdían la energía antes de ser detectados por el tile). He hecho algún ajuste extra y ya está. También he estado investigando diversas animaciones de explosiones, para diseñar un par de ellas para los niveles 1 y 2 de la explosión, y dejar, de momento, la que ya tengo para el nivel 3.
Lo cierto es que ahora no sé por dónde seguir, porque tenía pensado que el arma para derrotar al boss 4 también se disparara cargando el disparo, pero visto lo visto voy a tener que rechazar la idea. En fin, ya veremos.

De momento tengo que terminar un par de cosas, puede que esté sin escribir unos cuantos días. Ya os contaré entonces cómo va la cosa.

Hay alguna demo de este proyecto? Para los curiosos jeje

Buenas de nuevo:

He tenido que darle otro parón al desarrollo... y a venir al foro ^^U Cuando el trabajo se pone intensito...
Bueno, antes de enrollarme: demo no, lo que hay es versión completa en mi página de GameJolt, la 1.3.algo (recordemos que estoy intentando crear la 1.4)
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481

A ver, que por qué este parón... Bueno, este verano no he tocado el ordenador, como hago todos los veranos (y qué bien me ha venido), y a la vuelta, pues tampoco había ganas ^^U. No, pero el motivo principal ha sido que, como todos los años, debo terminar un juego paperactivo, y esta vez me he propuesto acabar uno que empecé en el lejano 1990 y muchos, junto con un colega: una cosa a medio camino de un GTA y un juego de rol de Mortadelo y Filemon. A día de hoy, el juego base está acabado, pero aún me queda una semana para añadidos y otras cosas que he querido mejorar en estos años (minijuegos para ganar dinero, más NPCs...).
También he medio metido un proyecto para hacer un vídeo sobe cómo construiros una Game Paperactiva 2, una consola de cartón que hará las delicias de vuestros hijos e hijas. Ahora mismo está grabado todo el proceso y el guión escrito. La semana que viene me pondré con el "voice over" y la edición.


Bien, respecto al juego, pues buenas noticias: parece ser que si en lugar de usar los botones Z y X para el salto y el disparo, uso X y C, ya no tengo el problema de la carga del disparo, por lo que puedo seguir el desarrollo, tan pronto como cambie los botones por defecto en PC (y guarde mi nueva configuración :P).
Por lo demás, no hay más que contar. Puede que alguna noche haya puesto un par de pixels en la animación de la lava, pero poco más.

Vienen días de poca actividad en este sentido: temporada alta en el trabajo, las visitas navideñas, terminar el vídeo, y ya veremos si no hay otro proyecto paperactivo metiendo baza también. De todas formas, intentaré dedicarle algún ratillo los fines de semana. Ya os iré contando.

Bueno, voy a actualizar esto un poco, que está muy desangelado :D

Ciertamente, en este tiempo no he podido avanzar con el Echo, se me han juntado varios factores que me lo han impedido.
Para empezar, como siempre, el trabajo, que parece que en Navidades vamos a tener una temporada tranquila, especialmente yo, que me dedico al desarrollo y no suelen pedir nada nuevo para esta época, pero se han juntado una serie de tareas urgentes con un desarrollo que he tenido que acelerar para solucionar otros... total, que me tienen trabajando al 110%
Por otro lado, como ya comenté. este verano y otoño se ha despertado mucho interés por la "Game Paperactiva 2", una "consola" de cartón que hice para algunos de mis juegos paperactivos, y que ha gustado a algunos chavalines y padres ociosos, así que decidí hacer un vídeo de cómo se hace. Quiero mantener el vídeo lo más sencillo posible, pero ya sabéis, yo soy yo, y si no me complico de una manera u otra, pues no estoy tranquilo. Por cierto, ya llevo la introducción, los materiales y las medidas, estoy por la parte de los cortes, a falta de la pantalla, el doblado y las conclusiones, aunque constantemente vuelvo atrás para hacer revisión... y aún no tengo ni una música de fondo ^^U

Pero bueno, al menos hay alguna novedad. No quiero dar falsas esperanzas a nadie, pero estoy haciendo pruebas a un "port" que ha hecho SplinterGU para una beta de BennuGD2, y de momento pinta bien, quitando algunos detalles, fruto de ciertos comportamientos que han cambiado de una versión a otra, pero me parece increíble que un juego tan ¿complejo?, bueno, más bien "completo", funcione al 98% sin muchos cambios (o al menos, es lo que parece). Quizás es demasiado prematuro decir 98%, pues apenas he podido avanzar una pantalla del juego. Ya iré informando... a SplinterGU :D

En cuanto pueda terminar con el vídeo, a ver si le puedo dar un empujoncito más al juego.

maravilloso! (la version de bennugd2, es oficial, en desarrollo...)

Bueno, tras varias pruebas con la versión modificada del Echo que ha hecho Splinter, he podido sacar algunas conclusiones:

Primero, el juego (en la segunda versión que me ha pasado Splinter) funciona casi perfectamente hasta donde he podido probar. Hubo una primera versión en que los "fades" fallaban, porque los hago "a mano" (empleo una imagen pintada en negro, para distintos efectos de transparencia, como que la pausa deje el juego más oscuro pero no en negro), y es que el color 1 ya no es el negro opaco, al cambiar los colores de RGB 565 a RGBA 8888 (ya no hay modos de color de 8 o 16 bits). En la última eso está corregido.

Segundo: que hacer un port no es algo que se pueda hacer de forma directa. Hay cambios en los tipos de dato (los antiguos INT eran de 32, los nuevos son de 64), en el manejo de las posiciones en pantalla (ahora se usan decimales), en la gestión de controles, hay que crear una gestión de rutas (las partidas las guardo en la carpeta /save junto a los binarios del juego, pero por lo visto, algunos sistemas exigen el uso de una ruta específica de usuario), y la que peor me ha sentado, hay que reescribir todo el tema de colisiones.

El juego usaba collision. Bueno, primero comprobaba si había algo lo suficientemente cerca para hacer colisión, y luego hacía dicha comprobación. El caso es que las colisiones eran "pixel perfect". Eso, en BennuGD2 ya no existe, y las colisiones se hacen en base a primitivas, por tanto, en el port se estaban usando colisiones cuadradas con el gráfico, lo cual, en el 90% no es problemático, porque eso significa una caja de colisión mayor para eliminar enemigos... pero también para que te hagan daño por contacto. No suele ser un problema porque los gráficos están bastante ajustados, pero en lugares donde te tienes que situar entre dos enemigos muy juntos es especialmente problemático.
Donde la cosa se vuelve crítica es con los jefes. Usan sprites enormes, y la mayoría con formas irregulares, con huecos y salientes, y que el gráfico entero sea una caja de colisión es injusto para el jugador.
El peor caso se lo lleva "Gravor", el dragón de la pantalla 1-3: para acabar con él, hay que dispararle al interior de la boca, hasta que sufre el suficiente daño como para que levante la garra y deje su torso al descubierto. El caso es que la boca tiene un par de gráficos invisibles (alpha = 0) que hacen de barrera, e impiden que pasen los disparos al interior de la boca, que tienen la forma de la parte exterior del hocico. Pues al usar todo el gráfico, al abrir la boca, los disparos hacen colisión con la parte "no pintada" de las durezas, y evitan que alcance el interior de la boca, por lo que nunca sufre daño, nunca levanta la protección, y el jefe se vuelve invencible... que ha sido lo más lejos que he llegado.

"Bueno, pues lo corriges y ya está".
Ojalá fuera tan sencillo. Actualmente estoy en mitad del desarrollo de la versión 1.4, y la que ha usado Splinter es la versión que se lanzó para el aniversario, por lo que hay muchos cambios que no están en el port, así que, para empezar, tengo que terminar la v1.4 antes de pensar en hacer un nuevo port.
Por otro lado, ya dije que intentaría que el juego fuera aún compatible con Wiz (ya que fue la plataforma objetivo desde el inicio), y a  día de hoy, BennuGD2 no es compatible, lo cual es problemático para mi. He estado preguntando en GP32Spain, y sí que parece que hubo una SDL2 para Wiz, porque en una lista de compatibilidad (no sé si oficial) se dice que "fue compatible en algún momento", pero no sé si sigue en mantenimiento. Habría que preguntar en los foros de OpenHandhelds, que es donde están los de Pandora, y el que creo que hizo el port de SDL2 a Wiz.

Bueno, para ir concluyendo, he hablado con Splinter, y se le han ocurrido un par de ideas que podrían mejorar el rendimiento del scroll tileado. Intentaré implementarlo lo antes posible, antes de que se me olviden, y a ver qué resultados obtengo, pero como digo, estoy muy liado últimamente y apenas tengo tiempo ni ganas.