re:juego de lucha

[laghengar]

mmmmmmmmmmmm , lo de 60 fps es por la rapidez de respuesta del juego respecto al jugador, en ese tipo de juegos los gamers lo notan mucho cuando uno va a 60 o a 30. El segundo parámetro que dices de ponerle 0 es para indicar a bennu cuantos frames por segundo le permites que no muestre los gráficos. Mostrar gráficos usa bastantes recursos, y con ese segundo parámetros le liberas de la carga para que en caso de que no le de tiempo en ese frame, poder compensar llegando al siguiente. En los juegos de lucha este tipo de cosas no gustan nada, cada frame del personaje se cuenta, y si algo no sale como espera, el jugador lo nota y le deja una sensación extraña. Poner un 0 en el segundo parámetro no quiere decir que cargas más al juego, lo que pasa es que no le permites liberarse de la carga de sacar los gráficos. Si tienes un juego que va bien sin problemas, ese segundo parámetro da igual, no va a saltarse ningún frame. Pero ponle 0 porque si no le da tiempo a procesar algún frame, lo vas a notar, y eso es lo que tienes que depurar.

Lo de que el juego vaya a andar bien en cualquier compu ya depende de los recursos que emplees en el juego. Si quieres que funcione en cualquier emplea pocos sprites, con pocos pixeles, pocos efectos, pocos sonidos, pocos colores, poco de todo XD. Cuanto más pongas y más engorroso sea tu código, más máquina va a necesitar.

[Hola]

ok gracias laghengar, voy a intentarlo cualquier cosa les aviso

[Drumpi]

Bueno, sólo decir que acabas de descubrir el por qué es tan fascinante y a la vez frustrante crear videojuegos.

Sólo porque te veo algo perdido: los fps son imágenes por segundo. En cualquier lenguaje es sólo un parámetro estético, pero en Bennu es fundamental, ya que todo se basa en eso, en las imágenes por segundo: determinan cuándo los procesos se comunican, cuándo muestran cosas en pantalla, y lo más importante, CUÁNTAS OPERACIONES PUEDES REALIZAR ENTRE FRAMES.
¿Cómo se sabe eso? bien, espero que entiendas de ordenadores, porque no es lo mismo un 486, que un Pentium3 o que un AMD de doble núcleo. Un factor que determina esto es la velocidad del procesador, expresado en herzios (KHz, MHz o GHz), pero hay muchos más. Si en un momento dado tu juego se ralentiza se debe a que:
- Debe realizar demasiados frames en un segundo.
- Tu CPU no puede ejecutar todo lo que has programado entre frames.

Para que no se ralentice, ya sabes: o haces código que haga lo mismo pero más rápido, o usas una CPU más rápida, pero me extraña muchísimo que se te ralentice un juego con la potencia de los ordenadores desde hace 10 años.

Respecto a cuantos FPS son los ideales: de nuevo, bienvenido al fabuloso mundo de la programación.
Según los estudios fisiológicos, el ojo percibe movimiento con 24 imágenes por segundo, que es la velocidad de las antiguas cámaras de cine. Sin embargo, el formato de televisión PAL usa 50Hz/50FPS, por o que es lo que la gente está acostumbrada... salvo que usen el sistema NTSC o el moderno PAL, que va a 60Hz y se nota que todo va mucho más suave.
Pero a mas FPS, mejor debe ser tu código. Rara vez tengo animaciones que requieran de más de 15FPS, pero el movimiento se ve tosco. Al final uso siempre 50FPS porque me permite calcular tiempos más fácilmente (1 frame dura exactamente 0'02 segundos). Pero como te dicen por ahí arriba, en juegos de lucha se suelen usar velocidades altas, de 60FPS para arriba, porque la gente machaca los botones a toda velocidad, y en Bennu los botones sólo responden a cada frame, así que tener muchos frames por segundo evita que ambos jugadores coincidan al pulsar un botón y hace que haya menos retardo entre la pulsación y la ejecucuón del frame.

Pero claro, si quieres tener unos FPS muy altos, tiene que haber muy poco código entre frame y frame, deben ser órdenes o muy sencillas o en poca cantidad.

Una solución, poco elegante, pero muy utilizada es el segundo parámetro de SET_FPS: lo que se conoce como Frame Skip. Básicamente le dice a Bennu que no ejecute las órdenes de dibujado de las imágenes, pero sí el resto. Así consigues más tiempo para ejecutar el código, con el coste de que algunas imágenes no se van a ver, y el juego parecerá que va "a saltos".

así, que, como ya te han dicho, localiza esas partes donde se ralentiza, averigua qué es lo que hace que vaya tan lento, y mejora el código para que no lo haga más. No es lo mismo recorrer 20 posiciones de un array para obtener el 5º dato, que recorrer sólo las 5 primeras posiciones y luego salir del bucle.