Técnicas y consejos

En esta página vamos a hablar de consejos de programación y técnicas para conseguir velocidad en tus juegos hechos en BASIC

Una de las técnicas fundamentales a aplicar es la técnica de "lógicas masivas" , a la cual se dedica una página específica (ver lógicas masivas). En esta sección abordaremos otro tipo de cuestiones de gran importancia, relativas al uso adecuado de comandos BASIC para optimizar la velocidad.

Todos los consejos están orientados a reducir memoria (complejidad espacial) o CPU (complejidad temporal) y asi estructuraremos esta página.

muchos de los consejos y trucos los iré posteando en la pagina principal del blog. Aqui, aparte de hacer una recopilación de consejos, pondré links a cada consejo especifico.

Técnicas de reducción de tiempo de ejecución

  • Mide el consumo en tiempo que consume cada instrucción. Descubrirás cosas sorprendentes, como que un GOTO es mas rápido que un REM, o que un REM es mas rápido que su versión abreviada, la comilla simple. Usa un programa como este para medir:

10 MEMORY 26999
11 DEFINT a-z
12 c%=0: a=2
40 a!= TIME
50 FOR i=1 TO 1000
60 AQUI PONEIS LA INSTRUCCION QUE QUEREIS MEDIR
70 NEXT
80 b!=TIME
90 PRINT (b!-a!)
100 c!=1000/((b!-a!)*1/300)
110 PRINT c, "fps"
120 d!=c!/60
130 PRINT "puedes ejecutar ",d!, "comandos por barrido (1/50 seg)"

140 PRINT "el comando tarda ";((b!-a!)/300 -0.47);"milisegundos" 

  • Usa el menor número de parámetros en las invocaciones a los comandos de 8BP. cada parámetro consume tiempo y cada milisegundo es importante en un juego, sobre todo de arcade
  • Prueba versiones alternativas de una misma operación, consulta aqui 
    • A=A+1:IF A>4 then A=0 : REM esto consume 2.6ms
    • A=A MOD 3 +1 : REM esto consume 1.84 ms
  • Precalcula cualquier cosa que puedas precalcular y almacenar en un array en lugar de calcularla durante el juego
  • Simplifica: una lógica compleja es una lógica lenta.Si quieres hacer algo complicado, una trayectoria compleja, un mecanismo de inteligencia artificial...no lo hagas, trata de "simularlo" con un modelo de comportamiento mas sencillo pero que produzca el mismo efecto visual. Por ejemplo un fantasma que es inteligente y te persigue, en lugar de que tome decisiones inteligentes, haz que trate de tomar la misma dirección que tu personaje, sin ninguna lógica. Ello hará que parezca que es listo (solo es una idea)
  • No uses coordenadas negativas si necesitas actualizar la posición de tu nave o personaje de forma muy rápida. El comando POKE (el de BASIC) es muy veloz pero solo soporta números positivos , al igual que PEEK. en caso de usarlas, usa |POKE y |PEEK (comandos de 8BP). Reserva el uso de |LOCATESP para cuando vayas a modificar ambas coordenadas y puedan ser positivas y negativas.
  • Si necesitas comprobar algo, no lo hagas en todos los ciclos de juego. A lo mejor basta que compruebes ese "algo" cada 2 o 3 ciclos, sin ser necesario que lo compruebes en cada ciclo. Para poder elegir cuando ejecutar algo, haz uso de la "artitmética modular". En BASIC dispones de la instrucción MOD que es una excelente herramienta. Por ejemplo para ejecutar una de cada 5 veces puedes hacer : IF ciclo MOD 5 = 0 THEN ...
  • Al programar un disparo múltiple (una nave que puede disparar 3 proyectiles simultáneamente) usa la técnica de lógicas masivas y reduce la lógica. Si en cada fotograma solo puede morir un enemigo, reducirás mucho el número de instrucciones a ejecutar. consulta este post: como-programar-un-disparo-multiple.html y usa por favor el comando COLSPALL, eso aun te permitirá programar más eficientemente
  • Haz uso de las "secuencias de muerte". Ello te permitirá ahorrar instrucciones para comprobar si un sprite que está explotando ha llegado a su último fotograma de animación para desactivarlo. consulta este post:  secuencias de muerte


Técnicas de reducción del uso de memoria

  • Reutiliza las lineas de código que gobiernan la lógica de un enemigo, mediante los comandos GOSUB/RETURN, y el uso de parámetros asi no tendrás que escribir la misma rutina para el enemigo1, para el enemigo2, etc. solo una rutina compartida para todos
  • en caso de usar layouts, no los almacenes completos sino una versión simplificada que luego proceses y generes el layout final. Por ejemplo si en una pantalla solo hay dos plataformas, no es necesario gastar memoria para decir que en todos los espacios vacíos restantes hay "nada". mejor simplemente guardas únicamente la ubicación de esas dos plataformas 



No hay comentarios:

Publicar un comentario