Hola a todos, estaba haciendo un ejemplo de como seria subir y bajar de plataformas en un beat em up pero no se me ocurre como implementar la caída de una plataforma. Actualmente entro y salgo de estas saltando, pero andando no veo como hacerlo.
Adjunto el ejemplo por si alguien sabe como hacerlo.
De camino si se le ocurre como simplificar el código para que sea más facil de entender que me lo diga también.
el código en cuestión es el siguiente
graph = load_png("resources/player.png");
control_point[0]=0;
control_point[1]=graphic_info(0,graph,G_HEIGHT)/2;
point (control_point[0],control_point[1]);
color_blocking = map_get_pixel(0,id_hmap,2,2); // Negro
color_elevation[0] = map_get_pixel(0,id_hmap,25,120); // blanco
elevations[0]=0;
color_elevation[1] = map_get_pixel(0,id_hmap,200,165); // rosa
elevations[1]=20;
color_falling[0]= map_get_pixel(0,id_hmap,142,168); // verde ;
color_falling[1]= map_get_pixel(0,id_hmap,150,152); // azul ;
While (!key(_esc))
current_color = map_get_pixel(0,id_hmap, x + control_point[0], y + control_point[1]);
if (state == 0)
if (current_color == color_falling[0])
y++;
end
if (current_color == color_falling[1])
y--;
end
If (key(_UP))
If (map_get_pixel(0,id_hmap, x + control_point[0], y + control_point[1] - 1) == current_color)
y--;
End
End
If (key(_DOWN))
If (map_get_pixel(0,id_hmap, x + control_point[0], y + control_point[1] + 1) == current_color)
y++;
End
End
If (key(_LEFT))
flags =1;
If (map_get_pixel(0,id_hmap, x + control_point[0] - 1, y + control_point[1]) == current_color)
x--;
End
End
If (key(_RIGHT))
flags =0;
If (map_get_pixel(0,id_hmap, x + control_point[0] + 1 , y + control_point[1]) == current_color)
x++;
End
End
If (key(_A))
if (current_color == color_elevation[0])
src_y_elevation = elevations[0];
elsif(current_color == color_elevation[1])
src_y_elevation = elevations[1];
end
x_direction = 0;
If (key(_LEFT))
x_direction = -1;
elsif (key(_RIGHT))
x_direction = 1;
end
state = 1;
y_jump = top_jump;
End
elsif (state == 1)
if (y_jump > 0)
y--;
y_jump--;
else
state = 2;
y_jump = top_jump;
end
x+=x_direction;
elsif (state == 2)
if (current_color == color_elevation[0])
dst_y_elevation = elevations[0];
elsif(current_color == color_elevation[1])
dst_y_elevation = elevations[1];
end
y_elevation = dst_y_elevation - src_y_elevation;
if (y_jump - y_elevation> 0)
y++;
y_jump--;
else
state = 0;
end
x+=x_direction;
end
Frame;
End
cual es la duda en concreto?
Quote from: DCelso
pero andando no veo como hacerlo.
Fácil.
Si pruebas el ejemplo adjunto, Mars puede subirse al coche y bajar de este saltando pero no puede bajarse de éste andando, esta es la pregunta.
¿Como puedo modificar el código para que Mars pueda bajarse del coche andando( esto quiere decir, sin tener que dar al botón de salto simplemente guiándola hacia el borde con las teclas de dirección)?
El mapa de durezas ya tiene los colores adecuados(o debería de tenerlos) para realizar la solución.
La verdad DCelso,para ese tipo de vista,yo haria el coche como un proceso que se puduiera subir y bajar de el,asi a priori, ademas lo suyo seria tener un mapa de durezas que comprobara si esta en el aire o no,por eso pienso que lo deverias tener en coche como un proceso,seria facil seria comprobar en el salto si cae encima de algun proceso,y mientras huviera collision estaria encima y cuando se acabara la colision caeria al suelo...Mucho vicio tuve yo en ese juego siendo un crio xD,si alguien quiere la version de dos la tengo por ahi 8)
Es un ejemplo facil que he visto de un cambio de plataforma pero imagínate que no es un coche es un simple cambio de altura en el terreno, un escalón.
Yo intento ver como programar el motor para que al ir andando se cambie de estado el personaje y vaya hacia abajo hasta llegar a la nueva altura.
Si ver la imagen hmap.png verás el mapa de durezas que uso ahora para el sistema.
Ahh,bueno eso no tiene mucho problema,lo puedes hacer de al menos estas dos formas...
1 : En cada ejecución del proceso Player compruebe que tiene debajo los pies,si en el mapa de durezas por ejemplo cojo el color rojo eso quiere decir que mantien la Y, y si no hay nada entoces cae,puedes tener una variable por ejemplo Inc_Y,que este a 0 cuando el valor sea rojo, y +2 cuando este transparente,por ejemplo.Para subir un escalon deveria comprobar en el mapa de durezas si choca con el color amarillo,por ejemplo,y si es asi comprobar unos pixel mas arriba si hay rojo y si es asi creas una la animación subir escalon y cambias el valor de Inc_Y,y claro esta teniendo otra en Inc_X,para bajar no haria falta comprobar lo de amarillo,basta con lo primero que te explique en este texto.
La 2: igual pero la comprobación solo si haria si pulsaras una tecla,lo malo de esto es por ejemplo si pulsas el boton de salto y lo sueltas y caes fuera de una platarforma,escalon,que seguramente te quedarias en el aire...
Yo pienso que por una sentencia de comprobación y tres If o un Swicth tampoco es muy importante tenerlo solo al pulsar una tecla,pues no consume casi nada de velocidad...
umn, creo que no es eso exactamente lo que busco, si juegas a los simpsons en mame mira lo que pasa cuando bajas del coche sin saltar ya sea por la izquerda o por la derecha o por arriba o por abajo. Tampoco ahora mismo se saltar hacia abajo y hacia arriba pero eso creo que no será dificil. ahora estaba concentrándome en bajar de un escalon alto (del que puedes bajar pero no puedes subir sin saltar)
Intento recrear el motor de juego de los simpsons.
Si lo que deseas es con esa perpectiva,es decir tipo Final Fight,Street or Rage,Los simpons,ect... te recomiendo que en las cosas que se puedan subir ,agarrar,destrozar ,ect lo hagas como procesos,ya que si lo haces con durezas,cuando pases por arriba de ellos,no tapara los pies al personaje y parecera que estas encima del coche,aparte que te limita el movimiento,pues deves tener una dureza ,en el caso del ejemplo,que no te dejara "bajar" o lo que es lo mismo subirte en el coche,desde la parte de arriba sin saltar claro esta,ademas que te vas a volver loco ,hasta depurarlo,eso del ejemplo vendria bien si en vez de un coche por ejemplo foso...en el que te podrias caer,pero para lo contrario lo veo un poco "extraño"....De todas formas a ver que se cuentan por aqui igual te dan otra solución... ;)
no entiendo tu duda real... porque si dices que tienes resuelto el salto, bajar es lo contrario... y tambien lo tendrias resuleto...
:), si fuese tan facil no lo preguntaría.
A ver, por lo que dices creo que no viste el ejemplo porque se ve fácil el problema, pero yo te lo explico más aún si es lo que quieres:
Es algo como esto:
_________ plataforma A
______ __________plataforma B
saltando consigo subir desde la plataforma B a la plataforma A
cuando estoy en esta nueva plataforma puedo volver a saltar para salir hacia la plataforma B (esto funciona) pero:
si ando hacia adelante debería de caerme otra vez a la plataforma B, pues esto es lo que no consigo.
Tienes que llevar este problema a un sistema beatem up, en el que el mapa de durezas del suelo no es una línea sino un área. Actualmente si ves lo que tengo diseñado el estado 0, es andando, hay un getcurrencolor que no te permite moverte a un color distinto a el de la plataforma en la que te encuentras y es aquí donde creo que debería actuarse. En el estado de salto estado = 1 (ascendente) y estado = 2 (descendente) el color que pisas ya no se comprueba por lo que permite saltar a otra plataforma/ zonas de otro color en el mapa de durezas.
¿Queda más claro?
Quiza el problema es que ves evidente la solución y te extraña que yo no, pero estoy ultra "blocked" ahora mismo, fijo que es una chorrada,algo como if noseque cambia a estado 2. Pero no lo veo, no.
a ver... cuando caes andando tienen que bajar de plataforma? y cuando saltas hacia abajo bajas de plataforma?
y entonces, por que no haces que cuando caes andando se setee el flag como si hubieses saltado hacia abajo?
en verdad me estoy perdiendo de algo...
No he probado aún tu ejemplo, pero no puedes usar la variable x,y para ello ? O variables auxiliares, o que el mapa de durezas de las plataformas utilizen otras variables distintas al suelo para posicionamiento del prota ??.
En Castle of dr. malvado me recuerdo que pasaba de nivel cuando estaba en una determinada posicion (x,y), incluso en mi remake Geca adventure, ponia el prota hablando si estaba en determinado punto del mapa, y algunos de estos puntos creo que incluso estaban encima de plataformas mobiles, si puedes filtrar por esto por ejemplo sabrias en que posición el prota esta al caer del coche y desplazar el gráfico al coincidir con esas coordenadas. De todos modos si hasta el finde no lo resuelves, ya te lo miro.
Estaba leyendo lo de los estados, y si te encuentras en el estado de la plataforma superior y pones un contador que por ejemplo moviendo el prota hacia la izquierda sume la deslocacion x caminada, como sabes la largura de la plataforma, pues cuando el prota llege a ese valor le cambias de estado al de la plataforma inferior o se lo quitas para que caiga, y le pones gravedad en ese instante para que el prota caiga. Creo que esto seria una solución aprovechando las coordenadas x.
Oh, hace nada estaba hablando con unos alumnos de lo mismo :o
Hemos concluído en hacer un mapa de durezas basado en "carriles", diferentes colores para cada altura, y nos ha quedado claro el caso de diferente altura de plataformas horizontalmente... Para el caso vertical no hemos llegado a un algoritmo válido.
Ahora no tengo mucho tiempo pero estaré al corriente de este hilo, gran idea DCelso.
DCelso :
1. Tienes mas la zona verde esta muy arriba por eso se te atasca el personaje al querer salir del coche.
2. Es lo que te llevo diciendo en todos los post,deves comprobar que no este en el aire para hacer que caiga ,el alogaritmo del salto te vale,pero lo tienes que tener fuera del salto.
3. Para plataformas de simple verticalidad,eso te vale,pero para el ejemplo que tienes tu ,que es "3D",puesto que puedes subir y bajar verticalmente,si lo quieres para algo generico aun asi no te serviria...al menos desde mi punto de vista,pues el tener esa clase de durezas a mi lo que me viene a la cabeza es una trampa en el suelo,foso,agua,ect y no un obtaculo como pretendes...
Creo que entre todos me habeis dado una idea, voy a ver si la pongo en marcha.
;)
Y digo yo ¿No es más fácil hacer una representación del terreno desde una vista aerea en lugar de caballera? es decir, el mapa de durezas representa el escenario, pero en vez de usar esa vista en picado haces el mapa de durezas como si estuvieras mirando desde arriba del todo, así cada pixel representa la altura de esa posición y puedes trabajar como si fuera un juego de plataformas.
Si no te queda claro, puedes hacerlo como hasta ahora, pero en lugar de dibujar el coche (paredes, y techo), dibuja la "sombra": cuando el personaje esté en la posición (x,y) no podrá pisar el color morado a menos que esté a una altura z de ¿10 pixels?, si está a esa altura y detecta que la sombra pasa de morado a blanco sabrá que está en el aire y debe bajar hasta el suelo.
Obviamente tu personaje deberá tener unas coordenadas X2, Y2 y Z2 en el mundo "caballera" y otras en la pantalla (básicamente:
X=X2;
Y=Y2+Z2;)
No se si me explico.
me gusta la idea.
Por mi parte también había llegado a la conclusión de la sombra xD
Pues lo intenté pero no me salió. Me hace cada cosa rara.
dejo aqui el ejemplo que estoy siguiendo, he cambiado todas las variables con respecto a la versión anterior para que se compendan más facilmente su utilidad, además he cambiado la fase para que se vea mejor el cambio de plataforma, ahora no es un coche, pero ahora me pasa que por más que leo el código no entiendo porqué al caerse de la plataforma baja más de la cuenta. Para ver el problema subid saltando al coche, bajad saltando del coche, subid saltando al coche y bajad andando del coche. resulta que en este ultimo caso la posición es diferente.
A ver si te referias a esto Drumpi.
perdon, no habia visto el attach... solo habia visto la porcion de codigo... luego le hecho un ojo...
Creo que el problema esta aqui...
estado = ESTADO_DESCENDIENDO;
z_jump = tope_en_salto; // le das el mismo valor que si estuviera saltando y el salto es mas alto que la caida....
creo por que lo he mirado por encima y parece que todo lo demas esta bien,vamos eso es lo que me llamo la atención.
He probado varios valores pero ninguno me funcionó,0 , el mismo pero negativo, la mitad, etc, creo que falla algo en la lógica pero no logro verlo.
Descargo a ver qué has hecho, estuve pensando que la dureza de suelo debería indicar la "altura" a la que se encuentra la plataforma... Así es posible determinar en el aterrizaje (De la sombra) cuánto debe subir o bajar.
Es una sugerencia de otras tantas, aunque cualquier idea supongo que te liará más todavía con la monstruosidad que llevarás ya en mente :o
Estoy por empezar yo también desde 0 con este problema, pero 2 personas haciendo la misma cosa es 50% de rendimiento :P
EDIT: Ciertamente, lo he visto y la altura de caída no funciona muy bien :S
No lo había comentado, pero tenía la idea (Y la mantengo) de tener una dureza así: En los bits R la altura relativa del plano, en los bits G la información del "rail" horizontal en el que se está y en los bits de B la información del "rail" vertical en el que se está.
Así se podría gestionar con exactitud tanto las bajadas de plataforma horizontal como verticalmente.
No sé si me explico... Debería funcionar bien, pero dibujar el mapa de durezas sería trabajo de orientales.
vas a tener que reescribir todo tu codigo, no me gusta para nada eso...
sugerencias...
1) plataformas asociadas a un color de dureza
2) plataformas asociadas a una altura base
3) las coordenadas Y del personaje deben ser relativas a la altura base de la plataforma actual
4) cuando saltas o cuando caes, tenes que ir comprobando colision con otras durezas (de piso y de paredes/bordes)
5) cuando caes sobre una dureza, tenes que obtener su base, y en relacion a este valor y la Y inicial en relacion a la plataforma origen, ubicar el personaje en la Y en relacion a la base nueva. Cuando tu "Y" alcanza el valor calculado, entonces ahi debe dejar de caer o saltar.
fijate que cuando saltas sobre la plataforma mas alta, no se estas teniendo en cuenta la altura de la nueva plataforma, sino que se posiciona en la misma "Y" de origen, lo cual no esta bien.
6) usar puntos de control en vez de un objeto "centro_punto" (o algo asi).
7) tendrias que agregar 2 puntos de control mas, uno izquierda y otro derecha... para calcular cuando se mueve en esas posiciones... o incluso usar un colision contra el mapa de durezas.
8) fijate que cuando saltas tambien tenes que colisionar contra los bordes, para evitar moverte en diagonal sobre un plano que en teoria no se puede.
en este caso, en la diagonal formadas entre el area blanca y el area rosa, deberia haber otra dureza mas que indique la pared, y mientras la dureza de que estas chocando contra esta, no mover la coordenada "X".
9) creo que queda claro que la funcion obtener_siguiente_elevacion o algo asi, no deberia ir...
creo que con estos tips tenes algo para empezar.
Gracias, voy a ver si reescribo el código.
Readaptado el código, añadido nuevo color en la dureza, ahora sí va bien la caída andando. He añadido 4 puntos de control. He añadido unos writes para mostrar datos en pantalla.
Ahora el problema siguiente que me encuentro es que desde la plataforma de abajo puedo ir andando hasta la pared de la plataforma de arriba, ¿como controlo eso?.
Buen trabajo DCeslo,el remate final...
Pues tienes que tener un punto de referencia,digas el de abajo ,sumarle desde ese punto hasta donde quiereas que sea el final de Marge ,digamos la punta del zapato,y ahi ya controlas que a ese punto llegue al color que tienes verde que no la deje pasar al no ser que este saltando,si aun te quedara Marge lejos de la pared seria perfilar el verde hasta que tengas el grosor de la pared deseada....Animo,te hecharia una mano ,pero me has vuelto loco con el codigo de antes.... xD
Resolver lo que propone DCelso es uno de los típicos problemas para volverse loco... Dan ganas de pedir que hagas un motor o algo que abstraiga al usuario de las complejidades, pero realmente tengo ganas de enfrentarme "a pelo" al problema. Estoy deseando ver tu ejemplo, pero a la vez siento ganas de intentar programarlo desde 0 :P
Todo un reto DCelso, sos groso, sabelo.
te sirvieron las sugerencias? pudiste usar alguna?
SplinterGU, pues creo que todas, no se, mira a ver si me dejé alguna, porque verdaderamente he renombrado variables para ajustarlas a lo que proponías, he reajustado la función de comprobación de altura como proponías, he eliminado el obtener_elevación como proponías, pero los dos primeros puntos no sabía exactamente a qué te referías porque más o menos eso hacía un color por plano y una altura por plano.
De todas formas queda mucho trabajo por hacer porque no está puesto lo que comentaste de chocar contra la pared y no avanzar en x, ahí volvería a necesitar de tu magnífica ayuda para saber por donde encajar los tiros, que supongo que van en relación a lo que comenta DJSonyc de bajar los puntos de control de izquierda y derecha hasta los pies de Mars. Si puedes ver el ejemplo y juzgar tu mismo sería de gran utilidad.
En cuanto WindGate, lo que decías de crear una librería (o modulo o lo que sea) para abstraer el código pues lo tenía en mente pero creo que es bastante más complejo y no quisiera entrar en un proyecto de larga envergadura que me llevase todos unos años :D.
En principio lo insertaré en un remake facilote para el apagame.
Recuerdo a todos la primera finalidad que quería darle al proyecto apagame era la reunión de muchos motores de juegos clásicos 2D y conocidos para que cualquier iniciado pudiera coger uno y empezar un proyecto de cero basado en su juego preferido, por ejemplo un cadilac & dinosaurs, un supersprint, un gaunlet, un starforce, un manic miner, un galaxian, un pacman, etc. Incluso poder mezclar técnicas de un motor y otro para crearte un híbrido o cosas así como yo hice en su tiempo con el anarkanoid. De ahí que muchas veces insista en crear una sola fase e ir directamente al grano de lo que enseñar para no adornarlo mucho y tal ya que por lo general los adornos cada uno los pone a gusto y lo que importa es saber mover al personaje y los eneminos en el mundo ficticio creado :D.
Así de camino evitar que todo el mundo haga el mismo juego inicial de shot'emup :D
(Toooma offtopicada)
Lo que sería de gran ayuda y (un bombazo :D) sería que Bomberlink participara en apagame creando un mini motorcillo de su magnífico SOR remake, o que almenos compartiera el código fuente de una de sus primeras versiones :D.
si, vi el ejemplo, en principio deberias bajar los puntos a los pies...
Pues te digo DCelso,si lo que quieres es para apagame motores de plataformas ,se deverian crear al menos 2 distintos,uno en 2D tipo Ghost&Goblins,Sonic,ect y otro tipo Cadillac&Dinosaurs,Final Fight,pues uno es simple solo deve comprobar que este en el suelo,que no choque con paredes ni techos,y el otro tiene que tener una profundidad relativa,(mas cerca o mas lejos de jugador), para el estilo Gauntlet te puede servir el primer tipo digamos 2D,lo unico que se eliminaria si no estas pisando el suelo descenderias,ya que es de tipo cenital y simplemente con controlar si chocas con paredes valdria,ademas por lo que he visto preferis mapas de tiles en vez de Scroll,o eso me ha perecido,aun seria mas facil ,pues solo se tendria que comprobar si se choca con un proceso "Pared",o un proceso "Puerta" y no tienes llaves.
Yo estoy de acuerdo con Win te has embarcado en lo que posiblemente sea lo mas dificil de resolver sastisfactoriamente,las plataformas,si encima añadimos que has hido directamente a las digamos 3D,pues aun mas dificil,aun asi lo tienes resuelto,lo unico es que deves comprobar en que lugar del sprite tiene que chocar con la pared para que no avance,si choca con la cabeza logicamente pillara los pixel mas altos que con los pies,de ahi que te dijera lo de los pies,y quedara la cabeza cerca de la pared pero el resto del cuerpo mas lejo,aun asi creo que es un buen esfuerzo el que estas haciendo...
Yo si quereis me quedo con el proyecto de Gauntlet .. ;D
DJSonyc tienes razón en todo, pero no pretendo hacer un motor único para todos los tipo de juegos, sino que son motores independientes en juegos independientes cada uno con su motor donde se pueden ver distintas técnicas de programación de juegos, fíjate que apageme actualmente tiene motores para juegos de habilidad o puzle (tetris,columns, drmario, tictactoe, conecta4), para rebotes de pelota (pong y arkanoid, podríamos englobar también el pang ), un recoge objetos (pacman), un matamarcianos (galaxian), un plataformas a dos niveles (wiz), están en proyecto un plataformas sin scroll (manic miner) y otro recoge objetos (jecpac), y puede que insertermos de una forma u otra el de naves tuyo, y si te apuntas a crear un motor para un gaunlet también será bienvenido. La intención es recoger métodos de programación fáciles de juegos para poder iniciar con ellos grandes proyectos usándolos como base por eso lo suyo es centrarse en el motor interno del juego e interacción entre objetos que en otros aspectos menos importantes como menues complicados, guardar estructuras de datos de partidas, crear muchas fases sin aportar nada significativamente nuevo, etc. Vamos ir al grano del asunto de la forma más clara y entendible posible que no siempre tiene que ser ni la más eficaz ni la más eficiente sino la más cómoda/lógica de entender.
Aqui tengo una nueva versión, ahora va casi todo, he bajado los puntos de control a los pies, simulando lo que sería la planta de los pies. He insertado un nuevo color en el mapa de durezas. Ahora cada uno controla un margen distinto, pero aún así hay problemas todavía.
Necesito solucionar el movimiento en diagonal, por más que estudio el código no entiendo cómo es que yendo en diagonal (digamos arriba y derecha a la vez) Mars traspasa la rampa.¿Ideas?
También tendría que ver por qué si saltas de forma que caigas en la rampa tampoco va.
Veo que una tarea tan sencilla como es saltar para cambiar de plataforma se complica de forma considerable en un beatemup, me parece que lo voy a dejar parado, por lo menos hasta que sepa cuales son todas las variables a controlar. Creo que voy a empezar por intentar hacer un mod (megacutre) para openbor y así ir descubriendo todos los parámetros controlables por éste. :)
Chiquillo,aqui te dejo una version temprana del motor para tipo cenital y con tiles ya me diras si es lo que buscas,aun falta depurarla pero el peque no me deja,que lleva toda la semana malo y estoy cuidandole y no me deja ni un segundo XD
http://www.mediafire.com/file/0nv0luoze4z/Garlec.rar
:), me recordaste a Carmen Sevilla. Voy a probarlo.
Los de las diagonales es facil,si te fijas en el mapa de durezas al hacer una diagonal el punto de control sale de la zona azul dejandole pasar,aun asi te sobraba el color azul....
¿Por?, en teoría el azul es para comprobar que no puedes continuar y el verde para comprobar que puedes caerte.
Lo podias haber hecho con un color,pero vamos si te fijas diagonal abajo funciona bien,el problema esta que hacer la diagonal hacia arriba se va colando en lo azul ,hasta que llega un punto que lee el color verde o incluso el rosa y por eso sube...
P.D.:Con los 2 colores tambien esta bien...
Tendrias que hacer que al tocar el azul y pulsaras arriba,se fuera Marge alejando a la izquierda y lo tendrias resuelto...
Fijate bien,que la culpa no la tiene la diagonal,lo tiene el pulsar arriba que permite que subas y se va comiendo la zona azul,hasta el punto que sale de ella,fijate tambien el recorrido que hace al hacer diagonal abajo,y tienes que hacer lo mismo para arriba y ya esta.
Sipo, esa chapu la pensé pero quería encontrar primero el problema por si fuera un fallo de implementación o de ordenación de algo.
En cuanto a tu jueguecito, está muy verde aún, me recuerda taco a mi crappac (http://forum.bennugd.org/index.php?action=dlattach;topic=437.0;attach=291) (pruébalo si te deja tu niño :D) con el mismo fallo de retroceso visual en caso de impacto :D. En mi caso fue a posta buscando la facilidad y torpeza para una competición en la que ganaba la peor técnica de programación :D. De primeras te aviso que el sonido es horroroso (también a posta) saturado y a bajo bitrate, los gráficos no son tan malos como pretendía me digeron algunos, pero son malotes, gané "el premo a odio a mi juego", creo que Pixel lo hizo especialmente para mí por el mamoneo que me traía insertando y eliminando juegos de la competición :D.
sabes que puedes ver el mapa de durezas en vez de la fase tocando la tecla "d" ¿No?
Si se lo de la tecla,por eso he visto el fallo... XD y lo de la A y lo de la F,aunque se me queda la pantalla en negro,el juego-ejemplo ese es para tus tutoriales de juegos que quieres decir como ves apenas son 4 lineas .... xD
Si el problema de eso esque primero tiene que chocar el jugador con la pared,para comprobar si puede ir en esa dirección o no,y si choca regresarle a un estado anterior,sino se quedaria atascado,tenia pensado un proceso "fastasma"que comprobara el choque pero ya que no se puede usar un grafico trasparente para las colisiones no me sirve ya mirare tranquilamente...
Sí que se puede, esa es la gran ventaja de Bennu en 32 bits.
Todos los colores con transparencia igual a 0 son transparentes para la vista pero devuelven colisión, son como cristales :D, no se ven pero están :D.
El único transparente cien por cien que no devuelve colisión es el 0 absoluto, este se consigue en gimp, poniendo el color negro rgb 0 0 0 y añadiéndolo al canal alfa. En bennu se puede conseguir con RGBA(0,0,0,0) o directamente insertando un 0.
En otros programas (como inkspace) es una técnica parecida a gimp, añades negro osucro y pones su componente alfa a 0.
Lo que pasa es que lo de las sombras lo veo un poco chapuza porque llevas 5 o 9 procesos por jugador y enemigo incrementando bastante el nivel de procesamiento necesario de collision que ya de por sí no es muy rápido debido a implementar colisión exacta por pixel.
¿5 o 9 procesos?yo pretendo un clon del personaje trasparente que haga el movimiento antes que el personaje real y si choca no le deje,aun asi como has dicho es en 32bit pero si alguien lo quiere en 16 bit no le valdria....en fins...
DCelso en el programa que te acabo de pasar cambialo a esto.
X+=avance_X;
Y+=avance_Y;
IF (Collision(TYPE pared))
X=guarda_X;
Y=guarda_Y;
ELSE
guarda_X=X;
guarda_Y=Y;
END
y dime que te parece como queda ahora..xD
Ya probé, si que mejora, pero pasa algo extraño con las diagonales cuando chocas no se mueve en la dirección en la que puede.
Hombre el queque esta en cruz por algo,"testeo",y las diagonales que dices si las hiciera atravesaria el brazo,las piernas o la cabeza la pared,si el grafico es un cuadrado vez que efectivamente lo hace correctamente...
DjSonyk a ver que te parece esta adaptación basada en tu código y tus últimas modificaciones
PROGRAM Garlec;
// Carga de Librerias
import "mod_text";
import "mod_grproc";
import "mod_video";
import "mod_map";
import "mod_screen";
import "mod_rand";
import "mod_say";
import "mod_mem";
import "mod_scroll";
import "mod_math";
import "mod_proc";
import "mod_key";
import "mod_draw";
import "mod_timers";
import "mod_sound";
import "mod_joy";
import "mod_time";
GLOBAL
INT ficheros[2];
INT contadorfilas;
INT contadorcomulnas;
INT contador;
STRUCT nivel[14]
INT paredfila[19];
// INT paredcolumna[14];
END=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,0,6,0,0,6,0,0,6,0,0,0,6,0,0,0,0,0,1,
1,0,0,6,0,0,3,0,0,6,0,0,0,3,0,0,0,2,0,1,
1,0,0,3,0,0,0,0,0,3,0,0,0,0,0,0,0,3,0,1,
1,0,0,0,0,9,10,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,11,12,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,1,1,0,1,0,1,0,0,1,1,0,1,1,0,1,1,0,1,1,
1,1,0,0,0,1,0,1,1,0,0,0,1,0,0,0,1,0,1,1,
1,0,0,1,0,0,0,0,0,1,0,0,1,0,0,0,1,1,1,1,
1,0,1,1,1,1,1,1,0,1,0,1,1,0,1,0,1,0,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,1,1,1,1,1,1,0,1,0,1,0,1,1,0,1,1,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1;
BEGIN
ficheros[0]=Load_Fpg("suelos.fpg");
ficheros[1]=Load_Fpg("paredes.fpg");
ficheros[2]=Load_Fpg("pjs.fpg");
// Inicialización
Set_Mode(640,480,16);
Set_Fps(48,0);
put(ficheros[0],1,320,240);
FROM contadorcomulnas=14 TO 0;
// Variable que nos va sumando a la Z para que tenga mayor profundidad,+ 20 por columna
contador+=20;
FROM contadorfilas=0 TO 19;
// Variable que nos va sumando a la Z para que tenga mayor profundidad,+ 5 por fila
contador-=5;
pared((contadorfilas*32)+16,(contadorcomulnas*32)+16,nivel[contadorcomulnas].paredfila[contadorfilas]);
// FRAME(1000);
END
END
elfo();
LOOP
IF (Key(_ESC))
Exit(0);
END
FRAME;
END
END
// Procesos paredes
PROCESS pared(X,Y,Graph);
Begin
File=ficheros[1];
LOOP
FRAME;
END
END
PROCESS elfo();
PRIVATE
avance_X;
avance_Y;
direccion;
BEGIN
File=ficheros[2];
Graph=1;
X=80;
Y=80;
avance_X=1;
avance_Y=1;
LOOP
// Para la coordenada X
direccion=0;
IF (Key(_left))
direccion=-1;
END
IF (Key(_Right))
direccion=1;
END
X += direccion * avance_X;
While (Collision(TYPE pared))
X -= direccion * avance_X;
END
// Para la coordenada Y
direccion=0;
IF (Key(_up))
direccion=-1;
END
IF (Key(_down))
direccion=1;
END
Y+=direccion*avance_Y;
while (Collision(TYPE pared))
Y-=direccion*avance_Y;
END
FRAME;
END
END
Ahora no se bloquea al ir en diagonal (por ejemplo abajo y derecha a la vez) sigue en la dirección que puede hasta que no pueda en las dos, antes si no podia en una aunque por la otra pudiera no se movía.
He eliminado los guarda X e Y que no servían de mucha utilidad y he añadido dirección y amplitud de avance para poder configurarlo más facilmente, también puse un while en vez de un if (para curarme en salud, el resultado es el mismo o muy parecido, la diferencia es que con el while si derrepente el player aparece en mitad de un muro se movería hasta no colisionar con él) también he hecho que en vez de avanzar de dos en dos avance de uno en uno y para que vaya bien de velocidad he ajustado el FPS. Asi se consigue máxima precisión de pixel.
Jajaja ,yo pense que querias algo simple para como dices tu ,que uno que este empezando tenga donde partir,le voy ha hechar un vistacillo ;)
Si esta muy bien logrado ^^,mejor que lo que tenia pensado ...Todo la referencia y la variable contador deveria desaparecer pues esque copie parte del codigo de otro programa que tenia por aqui para hacer laberintos 3D y el contador guardaba la Z.
Hombre, una cosa es un juego simple y otra es algo a medias.
Yo me refiero a un juego "jugable" con un propósito, mover a un tio por la pantalla sin ningún fin es soso, no llama la atención de los noobs.
No hombre si me referia a la forma de hacerlo,si ya te digo que tenia pensado como arreglar lo que dices,por cierto con tu ejemplo ¿has visto que pasa si pillas justo una esquina? ^^
Jajaja es porque el zapato tiene un pico por eso pasa xD
No pasa nada no controlado ¿No? osea si te pilla la esquina de un muro entre el brazo y el pie pues se queda bloqueado ya que choca por ambos lados.
Por otra parte, si queremos un gaunlet y meterlo en el apagame, habría que ponerle unos generadores de monstruos un arma arrojadiza, unas pócimas unas llaves, unas barreras y un exit y ya tendriamos un buen motor gaunlet. Te encargas tu cuando tengas tiempo ¿no?, (sin prisa pero sin pausa :D)
Espera, te adapto el código al sistema apagame y sigues tu. ¿Ok? (o eso espero ::))
Si pasa,pon la esquina del zapato justo en la esquina xD,se queda pillado,si abres el grafico en el GIMP por ejemplo veras que hay un pixel moleston xD,tambien si te fijas en el fpg de pjs,veras una pocima,una llave ,un generador y una especie de fantasma,por cierto el error no es del codigo,sino que si pilla ese pixel,no anda ni si quiera normal XD,si me encargo ya te dije que me encargaba,toy mirando el motor que teneis de los tiles haber si le pudo introducir ,para que los niveles sean mas largos,y a ver si tambien hago un editor,que meter los codigos a mano es una leche,ademas si utilizo 2 o 3 distintos pos ya me contaras XD..
¿tenemos motor de tiles?, ostras pues yo ni lo sabía,no conozco el código de los demás, solo he tocado cosas para adaptarlo pero aún no me puse a entenderlo :D.
Por cierto ya adapté el código al proyecto, parte ya tu de este e intenta seguir el estilo que puse en la medida de lo posible.(mayusculas, minusculas nombrado de variables, etc) En realidad solo hay dos cosas importantes para la integración en apagame, que inicialices el sistema con una función llamada initialize_game. y que uses is_key_pressed en vez de key.
Ya lo tengo,me pongo a ello,lo del motor ,lo digo por el motor scroll de tiles de Drumpi,¿o no?,esque no he liedo todo el hilo pero si que me baje una version donde funciona bmuy bien,y es lo que te comentaba para que no sea el juego solo lo que se ve en la pantalla ^^
En principio intenta no usarlo para el apagame ya que es para iniciados y que aprendan a programar y a ver técnicas de programación, y eso de darle una librería que lo hace ya todo pues no ayuda mucho en la labor :D.