Problemas con programacion de juegos

[(_=*ZaXeR*=_)]

HOla:
Hace ya casi una semana que no me conecto, y la verdad es que se ve que hay mucho movimiento y me gustaria enterarme de todo, asi que si me informais de algo molaria. De todos modos mis post es para que me saqueis de un apurillo si es posible.
Resulta que toy programando un jueguecillo cutre, y no se muy bien como estructurar el bucle en el que se controla al personaje, puesto que el que tengo diseñado actualmente funciona bien y hace todo lo que quiero que haga, pero el problema es que cuando le doy al boton para que salte pues salta pero si a la vez que salto no puedo disparar, osea que el programa espera a que salte para despues efectuar el disparo, tambien me pasa cuando el personaje dispara no puede correr detras de la bala hasta que esta n o ha cruzado la pantalla y desaparece,se que esto es debido a que no lo tengo bien estructutrado, pero lo que pasa es que no se me ocurre como ponerlo para que haga todas las cosa a la vez. Espero que me hayais entendido y me deis una idea de como estructurarlo.
Mas o menos como lo tengo puesto es mas o menos asi:

while(1){
if (GpKeyGet()==GP_VK_UP)y--;
if (GpKeyGet()==GP_VK_LEFT)x--;
if (GpKeyGet()==GP_VK_FA)
{
for (i=0;i<=320;i++)
{
GpBitBlt(NULL,&gpDraw,x+i,y,gpDraw,(unsigned char *)imagen,0,0,120,80);

}
}
GpBitBlt(NULL,&gpDraw,x,y,gpDraw,(unsigned char *)imagen,0,0,120,80);

}
Se que esta mal escrita la funcion pero vamos es para que os hagais una idea. Bueno que dadme una solucion que se que esta no es la estructura del programa que necesito

[enkonsierto]

Yo no se mucho del tema, pero creo que debes definir "estados" del personaje. Por ejemplo, estado "corriendo", "parado", "saltando" y que cada estado tenga sus posibilidades de manejo. No se si se me entiende.

[Wave]

lo de soltados y eso ni caso, pon lo que quieras que haga. (sacado del gpgames)

teclas_p1=GpKeyGet();
if((teclas_p1 & GPC_VK_FL))pulsados[2]=1,soltados[2]=0;
if((teclas_p1 & GPC_VK_FA)) pulsados[0]=1,soltados[0]=0,soltados[1]=0;
if((teclas_p1 & GPC_VK_FB)) pulsados[1]=1,soltados[1]=0;

if((teclas_p1 & GPC_VK_RIGHT))pulsados[4]=1;
if((teclas_p1 & GPC_VK_LEFT))pulsados[5]=1;
if((teclas_p1 & GPC_VK_UP))pulsados[6]=1;
if((teclas_p1 & GPC_VK_DOWN))pulsados[7]=1;
if((teclas_p1 & GPC_VK_SELECT)) pulsados[8]=1;
if((teclas_p1 & GPC_VK_START)) pulsados[9]=1;

[Zheo]

Creo que no deberías dibujar la bala cuando pulsas el boton. Tendrías que hacer una función que dibuje la bala y hacerla en el paso de renderizado. Simplemente le dices que existe una bala, y ya la dibujarás luego. Algo así (no estoy familirizado con el SDK así que lo pongo a mi modo )

//Entrada del jugador
if (GpKeyGet()==GP_VK_UP)salto = true;
if (GpKeyGet()==GP_VK_LEFT)mov_der = true;
if (GpKeyGet()==GP_VK_FA) jugador_dispara = true;

//resto de la entrada

//Renderizado
if (mov_derecha)
DibujaMovimiento(x+1);
if(salto)
DibujaSalto();
if (jugador_dispara)
Dibuja_Bala();

Podría ser algo así (se me acaba de ocurrir, así que no se lo bueno que puede ser)
Hay que tener en cuenta lo que quieres que se mueva un personaje por frame, así como el salto y el disparo, que duran varios frames (para luego poner las variables de nuevo a false). También hay que tener en cuenta si quiere tener varias balas en pantalla.

Como ya digo se me acaba de ocurrir, espero que te sirva.

Un saludo

[BlueSkull]

Gran pregunta (_=*ZaXeR*=_).

La programacion en tiempo real, y por tanto la de videojuegos tiene algunas peculiaridades, y esa es una de ellas.

En realidad la estructura es simple, tienes el bucle principal del juego, ese bucle no sale hasta que la partida no termina, o se entra en el interface de usuario, lo que ahi se hace basicamente es, captura de entrada, actualizar la logica, actualizar graficos, sonido, y vuelta a empezar.

Ahora por partes, en la captura de entrada actualizas los estados de teclas.

En la logica, usando los estados de la entrada, tomas decisiones, miras colisiones, actualizas marcadores, haces la busqueda de caminos, etc, etc...

En la actualizacion de graficos, unicamente te dedicas a pintar..., JAMAS, REPITO JAAAAMAS la zona logica se alimenta de la zona grafica, sino al reves, osea, en la zona grafica lees los datos de logica, y haces la representacion en pantalla, pero jamas se calculan cosas de logica basandose en los graficos, dicho de otra forma, la zona grafica es una representacion grafica de la logica, y nunca al reves.

En el sonido rellenas los buffers (aunque tambien va por eventos, depende del sistema).

Esto es desde el punto de vista basico, pero generalmente tiene variaciones..., por ejemplo, el bucle de logica no es recomendable que vaya a la misma velocidad que el bucle de graficos, por el simple motivo que la velocidad del juego se veria afectada por la velocidad de la maquina que lo ejecuta, y por otro lado, la logica no debe ejecutarse tantas veces como la zona grafica, asi evitas un peso importante de proceso.

Luego lo normal es garantizar unas ejecuciones por segundo fijas a la logica del juego (con el relog del sistema, comprobando ticks, con interrupciones, con contador de retrazos, en fin, como sea), y el resto de maquina, dejarlo a la parte grafica, asi por un lado, garantizas en maquinas mas grandes una mejora grafica, y por otro lado, consigues manejar todas las variables de logica con un t constante, y por lo tanto eliminar la t de la ecuacion, parece una chorrada, pero el no tener que comprobar el tick de reloj 10.000 veces en cada calculo alegra a cualquiera, por ejemplo, si la pelota esta en X, para el siguiente bucle estara en X+10, ese 10 es la velocidad, y la t esta especificada implicitamente por las veces que se ejecuta el bucle de logica en un segundo.

Espero haberte solucionado el tema, si quieres mas info, pues me preguntas y yo te explico hasta donde pueda.

[Zheo]

Aquí lo tienes como un autómata (sólo para que sea más gráfico)

Es que antes no me acordé de la imagen esta que hice para otro foro :P

Un saludo.

[Zheo]

Bueno no se qué pasó que no la incluyó (creo que fue por darle al previsualizar antes de enviarlo, con lo que me quitó la "afoto" )

Un saludo

[BlueSkull]

Gran pregunta (_=*ZaXeR*=_).

La programacion en tiempo real, y por tanto la de videojuegos tiene algunas peculiaridades, y esa es una de ellas.

En realidad la estructura es simple, tienes el bucle principal del juego, ese bucle no sale hasta que la partida no termina, o se entra en el interface de usuario, lo que ahi se hace basicamente es, captura de entrada, actualizar la logica, actualizar graficos, sonido, y vuelta a empezar.

Ahora por partes, en la captura de entrada actualizas los estados de teclas.

En la logica, usando los estados de la entrada, tomas decisiones, miras colisiones, actualizas marcadores, haces la busqueda de caminos, etc, etc...

En la actualizacion de graficos, unicamente te dedicas a pintar..., JAMAS, REPITO JAAAAMAS la zona logica se alimenta de la zona grafica, sino al reves, osea, en la zona grafica lees los datos de logica, y haces la representacion en pantalla, pero jamas se calculan cosas de logica basandose en los graficos, dicho de otra forma, la zona grafica es una representacion grafica de la logica, y nunca al reves.

En el sonido rellenas los buffers (aunque tambien va por eventos, depende del sistema).

Esto es desde el punto de vista basico, pero generalmente tiene variaciones..., por ejemplo, el bucle de logica no es recomendable que vaya a la misma velocidad que el bucle de graficos, por el simple motivo que la velocidad del juego se veria afectada por la velocidad de la maquina que lo ejecuta, y por otro lado, la logica no debe ejecutarse tantas veces como la zona grafica, asi evitas un peso importante de proceso.

Luego lo normal es garantizar unas ejecuciones por segundo fijas a la logica del juego (con el relog del sistema, comprobando ticks, con interrupciones, con contador de retrazos, en fin, como sea), y el resto de maquina, dejarlo a la parte grafica, asi por un lado, garantizas en maquinas mas grandes una mejora grafica, y por otro lado, consigues manejar todas las variables de logica con un t constante, y por lo tanto eliminar la t de la ecuacion, parece una chorrada, pero el no tener que comprobar el tick de reloj 10.000 veces en cada calculo alegra a cualquiera, por ejemplo, si la pelota esta en X, para el siguiente bucle estara en X+10, ese 10 es la velocidad, y la t esta especificada implicitamente por las veces que se ejecuta el bucle de logica en un segundo.

Espero haberte solucionado el tema, si quieres mas info, pues me preguntas y yo te explico hasta donde pueda.

[(_=*ZaXeR*=_)]

Gracias a todos por intentar ayudarme, pero ninguna de las cosas que decis me soluciona
el problema porque lo que me indicais es como debo estruccturar mi programa cosa que ya se
y no el como solucionar el problema, cuando disparo no puedo hacer otra cosa hasta que se
termina de realizar el disparo, y esto es debido a que se redibuja frame a frame la bala
sin tener en cuenta otra cosa, por lo que lo he solucionado evaluando las variables logicas
deteccion de boton pulsado dentro del bucle del dibujo del disparo, y la verdad aunque en
este trozo de codigo si que he mezclado graficos con logica y decision, cosa que dice BlueSkull
que nunca debe hacerse, me da muy buen resultado,pero si me dice como lo haria el en el mismo
caso que yo tengo pues lo adaptare, aunque repito que va de put a madre ( lo que si
se es que no esta depurado pero de momento no me hace falta mas velocidad, aunque si se relentiza
cuando se hace una convinacion de movimiento y disparo).

Sobretodo gracias a Wave que me ha tratado de ayudar con parte de su codigo del gpgame y creo que es
el que mas se a acercado a lo que yo trataba de pedir para solucionar el tema.Y Blueskull la verdad es que tu info es util.

[mortimor]

Tengo que hacer mas documentacion, pero en cuanto tenga un poco avanzado mi "secret proyect" vendra una especificacion formal de la maquina de estados y demas de un programa multimedia. Seguro que a alguien le viene bien .

[(_=*ZaXeR*=_)]

Mortimor yo que tu no incluiria una maquina de estado, porque la gente puede liarse, ademas tambien depende de si la haces de moore o de mealy sera mas sencilla o complica, a mi entender es mas sencillo que hagas una carta ASM, con sus bloques asm que corren en cada ciclo de reloj, con eso a la gente le resultara sencillisimo y estara muy muy claro, ademas pasar de una carta ASM a una maquina de estados se hace en un plis, bueno depende de cual tipo de maquina de estados, porque como tenga que hacer las tablas... Pero vamos me parece mejor una carta ASM

[Zheo]

Pues yo creo que un simple diagrama de secuencia basta (como el que adjunto).
No se lo que es una carta ASM, pero por lo que acabo de leer parece estar destinada al diseño de sistemas digitales, no al diseño de un programa.

(_=*ZaXeR*=_) el problema con la solución que tienes (por lo de la ralentización) es que mientras la bala se está dibujando, vuelves a comprobar la entrada de teclado, lo que además es repetir código. Es más, si pones algún enemigo, no podrás moverlo mientras estás dibujando la bala, a no ser que también metas el código para manejar al enemigo dentro del código de dibujado y ... vamos, que es un lío.

A ver este bucle principal de un videojuego está sacado del "tricks of the windows game programming gurus" (buena lectura, aunque orientado a windows y directX, pero la teoría es válida en cualquier plataforma)
Lo he traducido y quitado las referencias a windows y el SO (es decir, que está prácticamente igual que el original

Espero que sea útil, (es mucho más completo que el de antes)

[(_=*ZaXeR*=_)]

Las cartas ASM efectivamente son de diseño de sistemas digitales, pero tambien lo son los automatas de mealy y moore como el que poneis, lo que pasa es que estos sistemas son equivalentes para el diseño de programas puesto que todos estan basados en tener en cuenta un flujo de datos, y su proceso, realmente al hacer un programa hacemos una traduccion de la carta ASM de lo como tiene que funcionar un procesador para hacer lo que queremos, es el puente de enlace entre software y circuitos, lo que quiere decir que tienen traduccion en los dos sentidos, pese a que se usen indistintamente en diseño de sistemas o en programacion, de hecho resulta que las cartas ASM son un uso de los diagramas de flujo de toda la vida que se hacian previos al pseudocodigo, y tienen una traduccion al ensamblador del procesador que usemos. Es mas yo diria que los automatas tienen mucho mas aprovechamiento en diseño de sistemas digitales que para programacion.

[mortimor]

Pues yo creo que lo mejor es utilizar un DTE en regla. Yo personalmente procuro seguir una metodologia a la hora de realizar una documentacion, vamos, en plan serio.

[(_=*ZaXeR*=_)]

Pues solucione el problema del disparo y movimiento, el problema estaba en que el programa esperaba a que terminara de pintar la bala, o a que saltara para seguir con los movimientos, en un principio lo solucione, volviendo a testear los botones dentro del bucle que pintaba la bala o que hacia el salto (que estaban hechos con el for), pero si realizaba dos cosas a la vez se me relentivaba. La solucion ha sido que el el disparo y el salto se genere progresivamente en cada reiteracion del bucle principal del juego. La ayuda que me disteis no me ha servido de mucho
pero os lo agradezco, es que eso de poner en el buffer los sprites, y luego cuando se han leido los botones y pasamos de la fase de logica... y finalmente renderizamos lo que hay en el buffer... mola mucho pero no lo he utilizado, mas que nada porque os pedi que me dijerais como se hacia eso y nadie me lo decia, solo que habia que poner los sprites en buffer...... osea que al no saber como y al no tener ni idea de como hacerlo pues le he dado una solucion practica a mi modo inventada (que era lo que realmente pedia desde el principio y solo wave se atrevio a tratar de darme, gracias nuevamente)

Un saludo