🚀 go-pugleaf

El 25 Apr 2000 19:42:15 GMT, bluemark@surnet.es escribi�:
>
>Os explico mi duda:

>  Estoy programando  un jueguecito sencillo  en C, y tan  sencillo es
>que todo se mueve  (al menos en mi Celeron 300) tan  rapido que no se
>ve nada.  Esto lo vengo arreglando  con un bucle for  vacio metido en
>medio del  bucle principal del juego  (aunque supongo que no  sera la
>solucion mas adecuada).  Sin embargo, al cambiar  de ordenador habria
>que cambiar la longitud del bucle en el codigo fuente, cosa que no me
>parece muy apropiada.

no, no. En programaci�n de juegos las cosas no funcionan as�. Ver�s,
hay 2 opciones para determinar la velocidad de funcionamiento de un
juego y cada cual se decanta por una o por otra aunque como ver�s la
segunda de ellas tiene ciertas ventajas.

- Utilizando funciones como gettimeofday() (que devuelve el numero
  de segundas pasados desde 1970) puedes obtener tiempos, y basarte
  en esos tiempos para decidir el numero de fotogramas por segundo
  de tu juego.

  Ejemplo: supongamos que quieres rular tu juego a 50 fps (50
  fotogramas por segundo). Eso quiere decir que tienes que dibujar
  cada fotograma en 1/50 = 20ms. Cada "frame" de tu juego tiene que
  durar exactamente eso, asi que haces:

  while(!fin_de_juego)
  {
	  HazAquiUnFotograma();
	  usleep( 20000 );

  }

 (Suponemos que HazAquiUnFotograma() es la funci�n tuya que dibuja
 un fotograma/frame de juego en memoria o videomemoria y luego lo
 vuelca a la ventana o a la pantalla de un plumazo, para que no se
 note como se construye la pantalla sprite a sprite). usleep() es
 una funcion que hace esperar a tu programa un numero determinado
 de microsegundos (20000 us = 20ms).

 Pero claro, lo de arriba tiene un fallo, si esperamos 20ms y no
 tenemos en cuenta cuanto tarda HazAquiUnFotograma() en ejecutarse,
 sigue dependiendo del ordenador en que se ejecute... para eso
 hacemos:

  while(!fin_de_juego)
  {
     start = gettimeofday();
	  HazAquiUnFotograma();
	  end = gettimeofday();
	  
	  tiempo_pasado = end-start;
	  usleep( 20000 - tiempo_pasado );

  }

 Con lo cual esperaremos 20ms pero restandole el tiempo que ha
 tardado en ejecutarse lo anterior. Si tard� 1 ms, y queremos
 tardar 20ms por fotograma, habremos de esperar 20-1 = 19 ms...

 Ok? Con esto ejecutes donde ejecutes tu programa, ir� siempre a
 la misma velocidad (siempre que el micro sea suficiente para el
 juego, debes comprobar que 20000 - tiempo_pasado no sea un valor
 negativo, en cuyo caso el ordenador es insuficiente para tu juego,
 ya que tarda mas de 20ms en ejecutar un fotograma, y eso es maaaalo :).
 Esa es la desventaja de este metodo... (tambien es verdad que 50
 fps es algo bruto, prueba con 20 :).
 
- M�todo 2. Consiste en tomar tiempos relativos y basar el movimiento
  de los sprites en el tiempo transcurrido, y no en framerate... es decir,
  supongamos un juego de naves. Tu le das una velocidad a cada sprite:
  las balas se mueven a 10 pixels por segundo, la nave a 5 pixels por
  segundo, etc. Entonces lo que haces es tomar el tiempo que ha pasado
  desde el anterior frame y mover N pixels haciendo una "regla de 3" :)
  Algo asi como:

  end = gettimeofday();
  while( !fin_de_juego )
  {
     start = end;
	  end = gettimeofday();
	  MueveObjectos( end-start );
  }

 de este modo, el juego ira tambien en los ordenadores mas lentos,
 aunque el objeto se mover� mas pixels de golpe en cada fotograma.
 Esta tecnica es mas complicada porque no es tan facil detectar
 colisiones, etc, pero es el mas "pofesional".

>  Muchas gracias por anticipado.

-- 
Windows 2000 no se cuelg�$%&/# NO CARRIER

 _-----------------------------------------------------_
|  NoP / Compiler          --       nop @ todolinux.org |
|-------------------------------------------------------|
|  POWERED BY - Linux RedHat 6.0  -  Reg. User #74.821  |
|             http://www.ctv.es/USERS/sromero           |
 ~-----------------------------------------------------~