Fenix Land (portado y actualizado)

[Drumpi]

Hola a todos:

Bueno, pues aquí os traigo algo interesante para el bichillo ese que se pasea por la pantalla (está aquí -->
He cogido el código de Fenix Land y le he metido el motor de tiles v3.2, ahora la CPU se resiente mucho menos que con la 1.1. Y ya de paso lo he metido a ver qué tal va en Bennu.
Finalmente no he tenido que hacer grandes cambios, pero parece que el juego va mucho más fluido y corrige errores que no había notado que existían (por alguna razón la cabeza no chocaba contra los techos inclinados).
De paso he querido probarlo en la negrita, así que le he metido la mod_joy y he tenido que retocar el funcionamientod e las teclas para todo el código (ahora más o menos es independiente, pero como es para pruebas, el joy sólo funciona en gp2x).
Pero tengo el mismo resultado que en Fenix: no funciona por un fallo en el intérprete. En Fenix parece ser que el problema venía al reservar memoria para almacenar el mapa de tiles, aquí no, aquí es al cargar el XM de introducción, que dice que el HW de sonido no existe. Podeis probarlo en WIZ si quereis a ver si pasa lo mismo.

Y es más, lo he probado en Linux y funciona, y aun mejor: he instalado timidity (tambien xmms pero no se cómo hacerlo funcionar) y he podido añadirle las librerías de sonido que guardaba de mis viejos drivers de soundblaster para w98 ¡PURA DELICIA! juer lo que los echaba de menos... aunque no se si eran exactamente esos sonidos, pero vuelve a sonar de lujo.

Podeis probarlo de aqui: http://drumpi.se32.com/cosas/FenixLand.rar

Y ya aprovecho para preguntar:
Si os fijais, el personaje anda y se choca contra la pared cuando el centro del gráfico llega a la misma ¿eso lo veis bien o un buen juego que se precie debería hacer que se detuviera antes? lo pregunto para futuros proyectos.

[Windgate]

1600 líneas de código en el mismo prg :o

Drumpi, lo veo perfecto, me gusta mucho el motor de tiles, pero lo que dices de la colisión en el centro del gráfico es un problema.

Estaría bien poder tener "algo" donde almacenar la mitad de la anchura del gráfico, en un sentido u otro, se obtiene con graphic_info... Intenté usar tu motor hace poco, pero iba con prisas y al final desistí...

Lo volveré a retomar un día de estos prometido :(

[FreeYourMind]

1600 líneas de código en el mismo prg :o

Como si fuera un problema :) mi pequeña media ronda las 10000 en un mismo prg, a mi me lia más separarlo todo en ficheros sueltos  :D

[Windgate]

Curioso xD

Me faltan testículos para enfrentarme a más de 1000 lineas de código en el mismo .prg, muy pero que muy compleja y específica tiene que ser la cosa para dejarla ahí toda junta. En sus días hice módulos más largos, pero los odio, los denomino "espaghettis" xD

[Drumpi]

Si, 1600, aunque es verdad, debería haber separado más en ficheros (lo haré), pero vamos, tampoco tiene mucha miga: son los procesos de presentación, menu y configuración (vamos, todo lo que sale hasta que le das a jugar).
Y como mireis game3.inc con 2200... 1900 son sólo del protagonista, de las cuales el 95% son el tema de la detección e interacción con las durezas. Ya dije en su día que me llevó un mes de duro trabajo reescribirlo para que fuese más sencillo añadir nuevas durezas.

El tema de no moverse hasta chocar el centro con la pared tiene muy mala solución, lo he estado intentando, pero tengo un problema gordo con las rampas al bajarlas, y es que por métodos "normales" las baja a trompicones (la gravedad no tira lo suficiente del prota hacia abajo), y el método que uso para que las reconozca es medio incompatible, pero veré lo que se puede hacer.

Por cierto, el motor no tiene nada que ver con las durezas. Insisto: el motor es un simple start_scroll como el de Bennu, pero con alguna función extra para obtener los tiles de una posición y para poner al personaje dentro del scroll (eso que Bennu hace de forma automática con c_type=c_scroll).

[Windgate]

El tema de las rampas es peludo, nunca me he puesto a programarlo en plan Sonic de verdad... Tengo alguna idea al respecto, pero serían ya demasiados proyectos a medias :S

[Drumpi]

Pues al final no parece que sea para tanto, no se cómo quedará al final, pero al menos desplazandome lateralmente de tile sólo tengo que mover al prota a una posición que no choque, pero aun desconozco si al final se va a "teletransportar" o no, depende de cómo quede el deplazamiento en el propio tile, que es lo último que tengo que reescribir.

Al final el código es casi un copia/pega del FL, pero simplificado y corrigiendo algunos fallos que he visto (raro, en el juego va de fábula): llevo 586 lineas sólo del proceso prota. A este ritmo, en un par de días tengo al chaval dando vueltas por mapas de durezas.

Para los Sonics, a lo mejor se puede reutilizar el código, añadiendo grupos de 4 tiles para los cuartos de circunferencia... aunque aun quedaría el tema del cambio de dirección de la gravedad :S

[Windgate]

Yo me refería más bien al tema de la inercia vertical conseguida cuando termina una rampa que va hacia arriba, de alguna manera habría que memorizar el "incremento de altura" debido a la pendiente, para que cuando ésta termina, el proceso siga subiendo lo que indique el último incremento, y cada vez un poquito menos.

Mira por donde con la tontería acabo de encontrar una solución factible.... ;D

Para el tema de los loopings ya sería cuestión de rebuscarlo más.

[Drumpi]

Para los loopings basta con mirar la velocidad del movimiento (incrementa pulsando derecha, decrementa hacia la izquierda, y no tiene nad aque ver con la velocidad vertical). Si esta es superior a cierto valor (cálculo a ojo de cuando se iguala a una supuesta "fuerza normal") va recorriendo el looping, y cuando acaba el cuarto correspondiente, la gravedad tira de él hacia la derecha, o sea, que hay que estar pendientes de los tiles de la derecha como si fueran suelo, y de los de arriba como si fueran paredes, hasta que salte o se acabe la pared, que la gravedad vuelve a su estado normal...
Aunque pensándolo mejor, podría entrar en un estado extra, en el que la velocidad vertical permanece cte mientras mantenga la velocidad (se le puede añadir friccion o gravedad normal para frenarlo al rato), y comprobase la pared y "pulsado-derecha" buscando que acelera hacia arriba, hasta que se acabe la pared o encuentre un techo (que haría lo mismo que si estuviese saltando)... a menos que encontrase otro cuarto de looping que lo pusiera en estado "corriendo por el techo" o de vuelta a "corriendo por el suelo".
Interesante...

Ah, para salir del looping creo que habría que trabajar con dos planos de durezas, y tener una que haga que el personaje pase a un plano o a otro.
O mantener un array de estados anteriores y detectar la combinación "corriendo"+"subiendo paredes"+"corriendo por el techo"+"bajando paredes", aunque ya no sería tan fiel a los Sonics.

[Windgate]

 ;D Sí, esa es una solución de muchas, probablemente de las que sirven para todos los casos, pero viendo que el radio de las curvaturas de los loopings de los Sonic no tienen mucha diversidad me da por pensar que buscaron una solución mucho más sencilla... En la Master System de 8 bits creo recordar que ya se hacía, y en esos tiempos se programaba en un plan muy "ensamblador", seguramente contaban con 2 posibles radios distintos de curvatura y poco más...

Hasta que alguno de nosotros programe el asunto nos queda la duda razonable, es como eso de "bajar de plataforma en un Beat em Up" xDDD

O el tema peliagudo de los tiles isométricos que pueden tapar al personaje xD

[Drumpi]

Según recuerdo, todos los radios de curvatura eran iguales, de 4 tiles de altura.. bueno, esto hay que explicarlo mucho:

He visto editores de Sonics, y he comprobado que se usan tiles de 16x16, pero con estos se componen los auténticos tiles de 32x32, Sonic tiene un tamaño de 32x64 pixels aproximadamente, lo que equivale a 1x2 tiles, como en mi FenixLand.
Pero es que encima rizan el rizo y crean bloques de tiles de 64x64 y se diseñan los niveles realmente con estos, y se hacen todos los cálculos y demás con estos, increible. Pero esto les da una gran ventaja: los loopings se forman con 4 bloques de estos, lo que les simplifica mucho la programación... aunque les da a los niveles cierto aspecto repetitivo (seguro que habeis notado que en los niveles hay muchas partes que se parecen a otras).

Por cierto, debo revisar el código del FL otra vez, ya me habeis avisado de un par de free que no deberían existir. Ya me ha funcionado en GP2X casi a full-speed, subiendo la velocidad a 240MHz o activando los RAM-TIMINGS va de miedo. Aun debo probar con los dump y restore type por defecto, a ver si sube algo más.

[La momia que fuma]

Pues a mi no me va el invento  :-[

Se me queda en la pantalla de seleccion de sistema y no me hace ni caso...a veces aporreando el pad, se mueve a camara lenta desde pc a gp2x XD, y al final se me sale con un error...

Estoy desde hace unos días con Windows 7, por si vale de algo la información (Por lo demás, mis proyectos siguen funcionando como siempre)

En que versión Bennu lo has hecho? igual es por eso.

[DjSonyk]

 A mi si me va ,al menos arranca me imagino que necesito un joy pues se me queda en la pantalla de selecion y no consigo nada con las teclas XD

[La momia que fuma]

Igual que a mi entonces...solo que yo si tengo joy, y con el consigo....que se cuelgue  :-\

[laghengar]

y por qué no vale para la rampa un simple coseno y seno?