Hasta hace poco la única forma que teníamos de ejecutar nuestro game loop era a través del setInterval. Por suerte ahora disponemos de una nueva función más adecuada para la ocasión: requestAnimationFrame.
¿Por qué cambiarlo si iba bien?
Pues porqué realmente no iba “tan bien”.
El mayor problema del setInterval es que va a mandar peticiones para ejecutar nuestro game loop cada X milisegundos indiferentemente de si el sistema está ocupado o no. Por lo tanto, si pasados los X milisegundos el game loop no ha terminado, setInterval igualmente va a mandar una nueva petición. Como el sistema estará aún ocupado con el game loop anterior, éste pondrá dicha petición en “cola de espera”.
Imaginad que el game loop necesita 60ms para ejecutarse, pero setInterval está llamando al game loop cada 30ms… ¡por cada ejecución real del game loop estaríamos añadiendo 2 peticiones en la “cola de espera”! Y cómo podéis imaginar eso supone un gasto innecesario de memoria.
El segundo problema con setInterval, es que seguirá emitiendo peticiones aunque no tengamos el foco en el juego: Si minimizamos la ventana o cambiamos de tab, setInterval seguirá mandando peticiones. Una vez más, un gasto innecesario de memoria… ¡y de batería en dispositivos móviles!.
¿Cómo va el requestAnimationFrame?
requestAnimationFrame espera recibir un sólo parámetro: La función que se quiere ejecutar. A diferencia de setInterval, una vez finalizado el game loop tenemos que volver a llamar a la función requestAnimationFrame pasándole nuevamente la función a ejecutar. Veamos un ejemplo simple:
Apr 28 12
Vídeo de la presentación en we <3 JS
Os dejo el vídeo de la presentación que he dado esta mañana en la segunda edición del We Love JS.
Las diapositivas no se ven demasiado bien (o nada bien) en el streaming, así que he colgado los PNG con los textos de las diapositivas para que podáis seguir mejor la explicación. Podéis descargarlas desde aquí.
Sin más, os dejo con el vídeo:
Video streaming by Ustream
Apr 20 12
“We <3 JS” el próximo sábado 28 de abril
Aprovechando que el viernes 27 se celebra en barcelona el DevUp (HTML5 Developers Conference), al día siguiente el grupo “We <3 JS” ha montado un evento para los amantes del Javascript.
Dicho evento va a estar compuesto por dos charlas y dos workshops. Podéis ver toda la información del evento (ubicación, charlas y workshops) y sacar los tickets (gratu-gratu-ito-ito) en http://we-love-js-2.eventbrite.com/.
Como ponente de “Game Development” os dejo el extracto de la charla:
El objetivo de la charla es hacer una introducción a Canvas centrándonos en el desarrollo de juegos: ¿qué ofrece? ¿Cuáles son sus virtudes? ¿Y sus limitaciones?. En otras palabras: dar una visión general de la API de Javascript destinada a la manipulación de gráficos. Hecha la introducción hablaré sobre las técnicas más utilizadas para el desarrollo de juegos en Javascript y, para finalizar, veremos de forma teórica (aunque no va a faltar código) cual es la estructura básica que debe tener un Framework destinado al desarrollo de videojuegos.
Intentaremos retransmitir en streaming las charlas para los que estéis interesados pero no podáis asistir.
Mozilla ha publicado un juego hecho íntegramente en HTML5, Canvas y Javascript que de bien seguro va a dar mucho que hablar. El juego en sí se llama “BrowserQuest” y utiliza WebSockets y NodeJS para gestionar la parte de servidor.
Y lo mejor de todo es que es Open Source y han publicado el código en: https://github.com/mozilla/BrowserQuest
¡A despedazar el código se ha dicho!
Muchos juegos utilizan un sistema de tiles (“azulejos”) para crear los backgrounds o los niveles. Para este tutorial utilizaremos un programa Open Source llamado “Tiled” para realizar los mapas. Una vez realizados exportaremos la información del mapa y crearemos una función en Javascript encargada de pintar el mapa recién creado a nuestro canvas de HTML5.
Requisitos para el tutorial
- Lógicamente tener Tiled instalado.
- Descargar éste Tile set para el tutorial (extraído de google images).
Parte 1: Crear mapa con Tiled
Lo primero es crear un mapa nuevo desde el menú “Archivo > Nuevo…” de Tiled. En la ventana que nos aparecerá:
- Mapa: “ortogonal”
- Tamaño de mapa: 8 patrones x8 patrones
- Tamaño del patrón: 32 x 32 pixeles
Una vez creado el nuevo mapa, desde el menú “Mapa > Nuevo conjunto de patrones…” seleccionaremos la imagen utilizada para éste ejemplo.
Veremos como nos aparece en la ventana “Conjunto de Patrones” del panel derecho nuestra imagen partida en porciones de 32×32:
Últimamente ando leyendo un libro sobre HTML5 y Canvas. Uno de los aspectos que me llamó la atención es que en todos los ejemplos expuestos utilizaba el método fillRect para limpiar el área del canvas. Así que me puse a investigar sobre las distintas técnicas utilizadas para limpiar el área de dibujo del Canvas:
De la misma forma que el otro día publicaba una mini clase para las operaciones básicas de trigonometría, hoy os dejo una clase que he tenido que montarme para poder trabajar con Vectores en dos dimensiones (imprescindible para detectar colisiones entre elementos móviles).
Aquí va:
Feb 24 12
Físicas en cyanJS: Círculos
Feb 20 12
Trigonometría básica para juegos
Cuando han pasado años desde la última vez que calculaste un ángulo o una hipotenusa (como ha sido mi caso), por estúpido que parezca tienes que ayudarte de Google para poder resolver dichos cálculos (/shy).
Hoy os dejo un mini-script que he hecho (en Javascript, claro) para que los más perezosos no tengáis que hacer uso de Google y podáis obtener ángulos, lados y hipotenusas.
Aunque sea un script muy simple, en el desarrollo de juegos es muy común la necesidad de realizar este tipo de cálculos, así que cualquier script que facilite y permita reutilización de código, es más que bienvenido.
Primero el código, y luego el uso:
Seguro que alguna vez habéis descubierto algo y después os habéis preguntado cómo lo habíais hecho hasta el momento para vivir sin ello. Pues eso es lo que me ha pasado a mí 
Después de aproximadamente 8 meses investigando y jugando con la creación de videojuegos con Canvas de HTML5, ayer tuve la sensacional idea de crear un módulo para debuguear todo lo que quisiera del juego. ¿Por qué no usar la consola de los exploradores? Básicamente porqué el juego se ejecuta 24 veces por segundo…. eso quiere decir que si en todo el juego tenemos dos console.log(), cada segundo nos aparecen 48 mensajes en la consola… ¡una locura y difícil de seguir!
El debugger lo que hace es recoger la información de lo que le pidamos y mostrar por pantalla todos los datos en el momento exacto de hacer la petición. Un ejemplo:
Soy consciente de que el post es algo irrelevante pero… ¡me hacía ilusión explicarlo!