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.
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 :(
Quote from: Windgate on November 23, 2009, 08:08:29 PM
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
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
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).
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
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
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.
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.
;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
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.
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.
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
Igual que a mi entonces...solo que yo si tengo joy, y con el consigo....que se cuelgue :-\
y por qué no vale para la rampa un simple coseno y seno?
Borrad el archivo game.cfg y seleccionad la versión PC, si poneis la GP2X sólo funcionará el joy, con la PC sólo debería funcionar el teclado. Este fichero sólo guarda info de la resolución y las teclas que habeis redefinido, por lo que no es importante.
Lo he probado con la versión r110 de PC, la última de Linux (preguntadle a josebita) y la 107 de GP2X y en todas va (bueno, al principio se me quejaba en gp2x, pero ahora me funciona).
Laghengar: si que son necesarios, para determinar la altura de los pixels de durezas, pero nada más. Aunque usemos durezas basadas en tiles, aun son durezas, pero las tenemos predefinidas. Pero tienes que tener en cuenta más cosas: si hay suficiente velocidad para subir, la alteración de la dirección del personaje al girar... se podría hacer muchas cosas usando física vectorial, pero en mi humilde opinión, hay formas más simples de hacerlo, empezando por la descomposición de dichos vectores en componentes horizontal y vertical...
Aunque me gustaría oir tu teoría.
Quote from: Drumpi on December 01, 2009, 11:56:31 PM
Borrad el archivo game.cfg y seleccionad la versión PC, si poneis la GP2X sólo funcionará el joy, con la PC sólo debería funcionar el teclado. Este fichero sólo guarda info de la resolución y las teclas que habeis redefinido, por lo que no es importante.
Hum....ese archivo....no existe! :-\ (Lo mas parecido es game3.inc)
Debería generarse en la primera ejecución, tras elegir el sistema (gp2x o PC).
No lo entiendo, a mi me funciona, tanto windows como linux, algo debe haber mal en tu bennu, porque si no no me lo explico ¿?
ninguna, solo era una cosa que tenía en la cabeza, pero aún estoy tratando de hacer que la bola colisione debidamente con un sprite que hace de tablero a lo pinball, así que hasta que no lo consiga, pues nada.
Hola a todos:
Reflote de tema (pensé que hacía más tiempo de esto ^^U).
Como comenté en el hilo de las tiras cómicas, voy a subir los bocetos del que será el futuro protagonista de FenixLand, así quedará constancia para un futuro juicio por plagio, y podreis haceros una idea de como se plasmaría mi estilo en un juego si me pusiera a ello en serio ;D
(http://forum.bennugd.org/index.php?action=dlattach;topic=950.0;attach=1109)
Está ampliado por cosas del escaner, pero el dibujo real mide lo que 1/4 de folio, así que se notarán bastantes las imperfecciones, pero os haceis una idea del diseño. Los guantes son provisionales, no están mal pero no me convencen, y los zapatos... bueno, creo que sí son definitivos, además, tienen que ser grandes y tener un diseño sencillo para que se vean en 32x64 pixels y se distingan los colores, pues van cambiando según necesite el jugador en cada momento.
Hola estan padres los bocetos, sobre todo me agrada tu Fenix Land, una idea, a lo mejor en lugar de tenis, podrias ponerle por zapatos unas botas como las k usa Yosi de Mario Bros, son graciosas y bonitas, jejeje, pero vos haceis lo ke mas creas conveniente, tu eres el artista de esto.
Karmap Up :)
Es que ya estoy cansado de ver siempre "botas al estilo Yoshi" (porque, si te fijas, son iguales que las que llevan Mario y Luigi, y cualquier personaje que siga un estereotipo o sea un clon de otro), así que me puse con ese detalle. Además coincidió con el rediseño de otro personaje mío que también cambió sus botas de dos colores por otros tenis.
Por cierto, que extraño ver otra persona que llama a este tipo de calzado "tenis" :D, todo el mundo las llama "deportivas", "zapatillas" o "bambas" :P
Quote from: Drumpi on April 24, 2010, 12:07:46 AM
Por cierto, que extraño ver otra persona que llama a este tipo de calzado "tenis" :D, todo el mundo las llama "deportivas", "zapatillas" o "bambas" :P
Por aqui tambien se llaman playeros :P
Hoy estaba ordenado algunos archivos en el PC y he encontrado tu juego y me ha dado por jugar. He descubierto que si al principio te caes a la izquierda se queda colgado XD
(http://img52.imageshack.us/img52/4454/fenixland1.png)
Juer, y encima es la versión primigenia tras el concurso :D Aun tiene los tiles viejos.
¿Pero se cuelga o símplemente ya no se puede jugar?
Creo recordar que el personaje cae de forma indefinida, porque no implementé ningún tipo de muerte. Sólo estaba el motor de tiles, el de detección de durezas, el manejo del único item del nivel, y los tiles especiales del tronco.
El proyecto, de momento, está suspendido, por otros de más interés... aunque es curioso, porque hace unos días cogí este código y lo estoy reformando para separar la detección de durezas, para poder usarlo en el gran juego Bennu, en el futuro Smash Bros Bennu, y en otros proyectos futuros... aunque no descarto realimentarlo sobre el propio FenixLand y sacar una nueva versión :P
Karma por el momento nostálgico :')
Ahora que veo ese scroll:
¿Hay algún ejemplo de zoom dinámico en scroll tileado? Algo que no sea tan marrano como el Drajon LoL, que todavía me pican los ojos.
¿Drajon Lol usaba zoom dinámico y scroll tileado?
Bueno, aparte de eso, existió una versión del primer motor de scroll tileado que permitía hacer zoom. La idea se dejó aparcada porque andaba buscando un mayor rendimiento del mismo, pero (en teoría) no es difícil añadírselo al actual (sólo hay que modificar los size de los procesos tile, recalcular cuantos de estos se verían, recalcular sus posiciones y modificar los valores de algunas variables internas, repito, en teoría).
Te lo pongo aquí, pero no sé por qué, no consigo que me funcione en ninguna versión de Fenix (lo cierto es que tengo algunos códigos, como el del TileMapEditor, que o funciona con una versión específica de Fenix o no funciona :S). Ojo, he dicho Fenix, no Bennu, aunque debería ser compatible (salvo según qué nombres de variables, creo que usé ERROR como una de ellas ^^U)
He visto un montón de veces a Windgate en muchos Post hablando sobre la necesidad de ALGO que mida la mitad de la anchura de un GRAFICO. Yo tambien lo veo interesante y necesario porque siempre sale algo, ya sea para colisiones o temas de durezas que necesita de ese dato.Así que yo también apoyo la necesidad d medirlo.
un saludo!
Bueno, esto es un poco offtopic, pero te responderé:
GRAPHIC_INFO(file, graph,G_WIDTH)/2;
Problema resuelto.
Bueno, comentaros (aunque no lo hice ayer) que finalmente he conseguido separar la detección de tiles de durezas en una función. Lo he probado en la GP2X y no he notado que haya una bajada de rendimiento (aunque no he conseguido ejecutar versiones anteriores para decirlo con seguridad). Más tarde lo subo al proyecto de Bennu.
Ahora tengo que modificarlo para que no atraviese a medias las paredes y para que no necesite usar la función de obtención de tiles (de esta forma, se podría pasar parte del mapa, modificando los tiles de dureza por si hay cambios en tiempo de juego que sólo afecta a un personaje, o por si hay necesidad de obtener los tiles con rotación, para andar por las paredes o el techo), eso me va a llevar un poquito más de tiempo.
thanks!
Quote from: Drumpi on December 19, 2010, 03:17:32 PM
Bueno, esto es un poco offtopic, pero te responderé:
GRAPHIC_INFO(file, graph,G_WIDTH)/2;
Problema resuelto.
Ahí has estado muy grande ;D
Peterpollito, me ofende que no te hayas enterado de cómo se hacía eso...
De hecho:
graphic_info ( file , graph , G_WIDTH ) * size / 200;
Tomaría en cuenta el tamaño actual del gráfico, el gravedad.prg que circula por ahí (Creo que te lo pasé) lo tiene metido para calcular bien las colisiones con las durezas.