Echo v1.4: road to season two

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ryo Suzuki

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

Drumpi

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

Ryo Suzuki

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

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

Drumpi

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

Drumpi

Vale, 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!!
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)

gecko

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.
Torres Baldi Studio
http://torresbaldi.com

Drumpi

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

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



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



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

Ryo Suzuki

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

Drumpi

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

gecko

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?
Torres Baldi Studio
http://torresbaldi.com

Drumpi

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

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

l1nk3rn3l

bueno , pero descargas donde ?

;D

Futu-block