mentalthink escribió:Una cosilla sobre los programas estos, o sea tu cuando haces eso, tú ves el código en C++, no?¿, o al menos en ASM
Se ve en ensamblador.
mentalthink escribió:y de ahí vas sacando la historia, lo que me ha gustao que has comentao la manera o sea fijandote en la barra
Tú sabes... todo está codificado con un número dentro del programa. Lo habitual es que si en un juego tienes 3 vidas, pues este codificado con ese valor. La barra de vitalidad del Gaurodan no es un gráfico de bloque que se consuma pixel a pixel como en otros juegos, sino que tiene 10 divisiones perfectamente diferenciadas, así que era lógico suponer que tenía que buscar el valor 10. Hay veces que la cosa no es tan simple... una barra de energía que se decrementa por píxeles... o un gráfico que va convirtiéndose de persona humana a esqueleto cada vez que te van quitando energía... Ahí tienes que pensar en qué es lo que tenía en mente el programador... ¿un valor que se decrementa de 255 a 0? ¿de 100 a 0? (lo de decrementarse es porque computacionalmente hablando es más eficiente comparar con 0 que comparar con cualquier otro valor) Otras veces lo que haces es mirar qué más pasa cuando te toca un enemigo o un proyectil, además de quitarte energía (suena un efecto de sonido concreto, o la pantalla parpadea un instante para indicar la colisión, etc) y lo que hago es buscar qué parte del código hace algo como eso. Esa parte del código habrá sido llamada desde la rutina que detectó la colisión y restó energía. Voy deshaciendo la pila de llamadas hasta ver algo que se parece a una secuencia de instrucciones que toma un valor, lo decrementa, lo vuelve a guardad, y compara el valor actualizado con 0.
La gracia del asunto es que en este programa, parece ser que todas las variables son double (real de 64 bits). Hasta una información tan simple como es un contador de 10 a 0 para la vitalidad se guarda con 64 bits en formato de doble precisión. Creo que Locomalito aún no le ha cogido el truco al Game Studio y puede que en algún sitio necesitara una variable real, y no supiera como hacer que esa variable en concreto fuera real, y las hizo todas reales

En otros programas de Locomalito, él ha usado variables enteras. Es la primera vez que veo algo así.
De esto me di cuenta al mirar lo que se guardaba en AppData, en settings.ini creo que es, que vi que todos los valores se guardaban con números con decimales. Eso me "mosqueó" un poco, y entonces a la hora de buscar el valor de "energía" probé a buscar un float o un double, en lugar de un entero.
Luego al comprobar el desensamblado, vi que no solamente eran doubles, sino que además el código hacía bastante uso de las instrucciones SSE para cargar, actualizar y guardar los datos. El código es en realidad bastante "feo" (el que genera el compilador, quiero decir). Todas las actualizaciones de ESA variable en concreto, la de la energía, se realizan en una única función cuyo cometido parece ser ese. Esa función es llamada desde otra, pero no directamente, sino que esa otra función "llamante" por así decirlo, tiene como uno de sus parámetros un valor que es un índice a una tabla de direcciones de funciones. Se calcula la dirección de la función a llamar según el contenido de la entrada de dicha tabla, y se llama. En concreto, esta función que actualiza la barra de vitalidad es la función de número 69h
El POKE no es elegante, por lo que he comentado antes que pasa cuando acabas el juego, pero sí es el más rápido que pude sacar. Un POKE elegante de verdad es aquel que neutraliza la llamada a la rutina que realiza la detección de colisiones, ya que permitiría por ejemplo recolectar energía cogiendo corazones (con mi POKE los corazones no te dan energía ni nada), y haría que Gaurodan se paseara por la pantalla como si fuera transparente a las balas, en lugar de chillar cada vez que le dan (aunque su energía no decremente). Llegué a ver trazas de esa rutina pero francamente, ya casi me daba igual
