Autor Tema: Echo v1.4: road to season two  (Leído 24669 veces)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #150 en: Enero 21, 2020, 06:21:49 pm »
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.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #151 en: Febrero 04, 2020, 01:14:38 am »
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.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

warrior_rockk

  • Sr. Member
  • ****
  • Mensajes: 253
  • Karma: 11
Re:Echo v1.4: road to season two
« Respuesta #152 en: Febrero 04, 2020, 02:31:51 pm »
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.

oskarg

  • Full Member
  • ***
  • Mensajes: 193
  • Karma: 3
Re:Echo v1.4: road to season two
« Respuesta #153 en: Febrero 04, 2020, 03:31:43 pm »
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 .

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #154 en: Febrero 05, 2020, 12:07:57 pm »
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.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

oskarg

  • Full Member
  • ***
  • Mensajes: 193
  • Karma: 3
Re:Echo v1.4: road to season two
« Respuesta #155 en: Febrero 05, 2020, 08:23:39 pm »
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  :)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #156 en: Febrero 06, 2020, 12:44:38 pm »
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.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #157 en: Febrero 17, 2020, 12:22:06 pm »
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
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

oskarg

  • Full Member
  • ***
  • Mensajes: 193
  • Karma: 3
Re:Echo v1.4: road to season two
« Respuesta #158 en: Febrero 17, 2020, 12:42:33 pm »
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

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #159 en: Febrero 18, 2020, 04:26:17 pm »
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
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

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
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
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Drumpi

  • Hero Member
  • *****
  • Mensajes: 6383
  • Karma: 164
  • Odio el periodo "entre proyectos"
    • La web de Drumpi
Re:Echo v1.4: road to season two
« Respuesta #160 en: Febrero 20, 2020, 10:33:30 am »
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.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)