Dudas para continuar con "The amazing adventures of Echo"

[Drumpi]

Voy a copiar el texto del último mensaje del proyecto Echo, porque me da que, como el hilo es tan largo y tan denso, no teneis ganas de leerlo, pero es que necesito vuestra opinión sobre qué haces con el Echo y su port a Wiz (aunque en realidad el port es a PC ^^U).

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

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 tengo las siguientes opciones a la hora de seguir con el juego:
- 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.
También me interesa saber cuánta gente sigue interesada en jugarlo en Wiz, y cuánto le molesta los tirones y las ralentizaciones que hay en la última versión, por si realmente merece la pena el esfuerzo.
Please, ¡¡consejos!!

[oskarg]

lo ideal seria crear un unico engine para hacer juegos con tiles,es decir que bennugd,por defecto ya tuviera tal funcion y estuviera optimizado..Pues si lo estas haciendo tu solo este proyecto,entiendo que te llegues a desesperar ,pues facil supongo que no es..

luego esta el rendimiento.¿No seria mas optimo hacer un simple mapa de la resolucion del juego(320x240+32 de alto+32 ancho) y a medida que avanzas ir pintando la filas y columnas nuevas que se visualizan?¿?,lo expreso porque a priori me parece muy costoso que todos los graficos sean tiles aunque los congeles etc......tenia en el disco duro en div,un mini motor que me dibujaba un mapa infinito de multiples direcciones,un mapeado tipo rol..... y aplicaba lo que he dicho anteriormente,hacia mapblockcopy al mapa del juego y santa pascuas cada vez que avanzaba 32 pixeles,pues el tile era de 32 pixeles,pero en realidad no utilizaba tiles. :P Cuando el "tile" tenia una animacion,por ejemplo el agua,era simplemente un grafico y no lo pegaba al fondo como es logico.

[Drumpi]

No, como digo no es cosa del motor de scroll tileado. Ya lo he comentado otras veces pero te hago un resúmen: el motor que he hecho usa un proceso por tile, pero siempre que el tile esté dentro de la región de pantalla y no sea cero; uso una lista enlazada para crear y eliminar tiles, y los reutilizo siempre que puedo para reducir los costes de creación/eliminación. En ese aspecto está muy optimizado.
También creé uno similar a lo que dices, pintando sobre un mapa que hago cíclico con ayuda del scroll de Bennu, y solo repinta las nuevas filas y columnas... y a veces ni eso, porque uso una matriz para saber qué tile está pintado en cada posición del mapa, y si el nuevo tile coincide con el antiguo, es una operación que me ahorro.
Ambos motores los he subido con el código fuente, precisamente L1nk3rn3l preguntó por el hace un par de días ;)

No, el problema es detectar las durezas. Un tile sólido me proporciona información de 16x16 tiles con una sola consulta. Una rampa lo mismo, pero en lugar de devolver un solo valor uso la ecuación de la recta para devolver 1 o 0. El problema es que tengo más de 50 tiles de durezas diferentes, y son demasiadas comprobaciones (si se acerca por la derecha, por encima, si el tile de al lado no me deja avanzar, si estoy sobre la esquina del tile anterior...). Eso es lo que ralentiza, y lo usan todos los sprites del juego, son 2000 lineas por frame.

De todas formas, gracias por tu información :)

[oskarg]

Si me indicas donde has subido el ejemplo,se agradece ...simplemente por verlo....
Si lo que ralentiza son las comprobaciones de colisiones ......2000 lineas?¿?¿?...seria de agradecer que el motor tiles se aislara del resto de codigo,pues sino nadie creo yo que saque algo claro en el.

Has intentado hacerlo por tablas las colisiones?¿?ejemplo simple tipo rebotes....en vez de detectar si la pelota rebota con el grafico,haces una tabla que guarda 0 o 1,pintado o no pintado bloque... si hay un bloque o no en esa coordenada y de esta manera solo utilizas dos procesos la pelota y la barra que mueve el jugador,por mas bloques que visualmente aparezcan.Mega optimo....
..los enemigos es lo mismo,si estoy en la posicion tal pongo 2 ..es decir es una tabla de coordenadas,donde te indica si esta ocupado por algo.si hay suelo y enemigo,pues pongo 3...si mato al enemigo pongo 2.asi sucesivamente....es lo que hacia yo en mi motor multidireccional con las colisiones no se si te resultara util y sobre mi motor lo saque de las revistas div,lo explicaba ,espere que sacaran la revista numero 10...pues supuestamente iban a publicar el codigo xd.

[Yawin]

No sé hasta qué punto tienes interés por continuar el proyecto. Muchas veces, para avanzar es bueno cerrar los proyectos que tiene uno y empezar cosas nuevas. Yo haría una de estas dos:

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

Y una vez terminado el Echo, me pondría con otro proyecto donde, si vas a usar durezas, hagas el nuevo sistema. Y, tras terminar ese proyecto, podrías volver a Echo e implementarle el nuevo sistema de durezas.

[Drumpi]

Oskarg, que copio/pego lo que le dije a L1nk3rn3l:

El motor de scroll no es Echo 1.4, ese es un juego que lo usa, pero modificado :D
El motor está aquí (incuyendo el isométrico, pero el scroll isométrico está en pañales ^^U):
http://forum.bennugd.org/index.php?topic=819.0
Aparte, la última versión está aquí:
http://forum.bennugd.org/index.php?topic=4294.msg68260;topicseen#msg68260
Es más o menos la misma, pero incluye zoom al scroll tileado (lo que hace que pierda algo de rendimiento), y un nuevo motor que pinta sobre mapas y que usa el scroll de Bennu para ahorrar memoria y cálculos.

Está un poco desordenado, pero si abres los PRG de la carpeta raiz, verás que son los distintos ejemplos de uso, y que realmente "includen" dos o tres ficheros del motor que están usando.
Si yo tuviera que implementar alguno de ellos en C, usaría el último, el que pinta a mapa, como referencia. Pero yo, para ahorrar cálculos, uso las propiedades cíclicas del scroll de Bennu para ir pintando sólo una fila o una columna en el mapa; en SDL esas operaciones serían innecesarias porque son 10 veces más rápidas que map_xput :P

Pero ojo, una cosa es el motor de scroll tileado, y otra muy distinta el motor de detección de colisiones, que son esas 2000 lineas. El motor de scroll tileado es MUY eficiente, tanto que funciona en una GP2X a 200MHz sin problemas con tiles de 16x16 a 320x240 incluso a 16bits de color.
Y sí, eso que dices es lo que hago para detectar durezas: la detección de tiles de dureazs no es más que comprobar un array más grande, pero no me vale con comprobar los valores 1 y 2, como te dije tengo más de 50 posibles valores en cada posición, y no es tan sencillo como "puedo/no puedo pasar": hay unos que me dejan pasar y otros que no en según qué circunstancias, y eso es lo que he excrito en 2000 lineas.

Yawin: sí, es más o menos lo que había pensado. De hecho, mi idea era lo de seguir, intentando mantener la compatibilidad dentro de lo posible (lo dicho, creando mapas modificados, reduciendo efectos gráficos...), pero quiero saber si hay gente interesada en la versión de Wiz, que han sido la mayoría de la gente que se ha descargado el juego hasta ahora. Si no la hay, pues sigo para adelante.
De hecho, tengo que modificar la detección de durezas para el nivel 2, pero no es un cambio tan radical como el que necesita para funcionar en Wiz.

[Futu-block]

yo he votado que cortes y te pongas con lo mio :D

Pero lo mas importante es las ganas que le tengas al echo, si quieres terminarlo de una vez por todas, adelante
Si hace falta te tomas un descanso y prosigues, pero es lo que tu quieras ;)

[Drumpi]

No, ya he dicho que el desarrollo va a continuar. Además, no puedo dejar en pausa lo que lleva en pausa ya varios meses, lo que voy a hacer es retomarlo (aunque eso no quita para que lleve otros proyectos paralelos, tranqui que Bitstrips v2 es uno de ellos ;) ).
Que conste que has votado que se corte de raiz el desarrollo SOLO PARA WIZ. El de PC sigue adelante.

[panreyes]

No he leído nada del hilo, pero la respuesta es: ¿Quieres que la gente pueda jugar a tu juego o no?
Wiz es una consola que tienen 10 personas y que ninguna la sigue utilizando.

No malgastes tu tiempo.

[Futu-block]

yo la sigo usando...

[JaViS]

No se si el port a Wiz sea tan determinante para el juego, pero yo creo que trabajar en la optimizacion de las durezas vale la pena.


Yo lo hice con anarkade, y hoy puedo correr mi juego en Raspberry, optimizarlo fue divertido, y el rendimiento mejoro en todas las plataformas.

[Drumpi]

Si Panreyes, que ha portado PixPang a todo lo portable dice que no merece la pena, es algo a tener en cuenta  :P
De todas formas, sigo leyendo opiniones, quiero saber si de verdad hay tan poca gente o no, porque el juego tuvo un número significativo en su día de descargas (unas 2000 entre Wiz y Caanoo en su versión 1.1). Es cierto que a día de hoy la v1.3 tiene unas 40, que no es tanto, pero no lleva ni la décima parte de tiempo publicada.

También es verdad lo que dice Javis, a veces esto de optimizar es divertido, aunque lleve tiempo, y lo mismo no es tanto como pienso, pero más de una vez me habeis dicho que soy demasiado cabezota y que no sé cuándo dejarlo ^^U
Por eso me seduce tanto lo que propone Yawin: seguir, y si en algún momento mejoro la detección de durezas, implementarlo (serán 2000 lineas, pero están localizadas en 4 ficheros que se añaden a los enemigos mediante "include"). Aun tengo que mirar lo que me pasó Javis de las durezas suyas, a ver si me aclara las ideas (es que las rampas me tienen la cabeza echa un lío, especialmente si está al borde de una rampa sin tile debajo, que podría traspasar la esquina de la misma si sólo compruebo los pixels de la parte inferior del sprite).