Hoy es 22 de diciembre de 2012…

… y aquí no ha pasado nada.

Ganadores del 2º concurso oficial teknoPLOF!

teknoPLOF! consurso II

teknoPLOF! consurso II

Realizado el sorteo de los regalos prometidos, los ganadores del 2º concurso oficial teknoPLOF! han resultado ser los que siguen:

  1. Primer premio: Unamahou en los Bancos (número 128).
  2. Segundo premio: Alika Ge Ene (número 109).
  3. Tercer premio: Jennifer del RC (número 65).
  4. Cuarto premio: José Borrazás (número 157).
El número de megustas recibido dentro del plazo ha sido de 171; lo sentimos por los que han llegado después. El primero de los megustas era el del editor de este blog, que participaba pero no optaba a premio, y el último llegó notificado, curiosamente, a las 23:59 del día 15 de diciembre, hora límite de recepción.

Los ganadores indicados se corresponden con las siguientes imágenes de perfil:

Perfiles ganadores

Perfiles ganadores

La manera de notificar el premio a los afortunados HA CAMBIADO RADICALMENTE debido a las restricciones de seguridad de Facebook para ponerse en contacto con los usuarios. Por lo tanto, el método es el siguiente: Cada ganador deberá ponerse en contacto con teknoPLOF! para solicitar su premio mediante el correo electrónico teknoplof@teknoplof.com. En el mensaje deberá identificarse con el nombre que posee en su perfil de Facebook y especificar todos sus datos de correo postal para que el envío pueda ser realizado (nombre y apellidos, dirección, código postal, provincia, país, etcétera).

Una vez hecho esto, desde teknoPLOF! se le darán las instrucciones necesarias para asegurarnos de que el remitente es propietario de la cuenta de Facebook correspondiente. En cuanto los requerimientos sean atendidos, se procederá a enviar el premio a su domicilio. Así de fácil y sencillo.

A continuación podéis visionar el proceso completo de selección aleatoria que se produjo el día 20 de diciembre. Al final del vídeo se puede comprobar la lista completa de los primeros 171 megustas recibidos, por si alguien quisiera comprobar los números agraciados.

Muchas gracias a todos y todas por participar, felicitaciones a los ganadores y un fuerte abrazo a los que no lo han conseguido esta vez. La próxima será, seguro.

Por qué no debemos girar las fotos

Rotando ando

Rotando ando

La mayoría de nosotros, cuando pasamos nuestras fotografías de la cámara al ordenador, tendemos a girar aquellas que, por la manera en la que fueron sacadas, aparecen tumbadas. Nuestros archivos fotográficos ya no se guardan en sobres de papel dentro de un cajón como ocurría hace treinta o cuarenta años, sino que se almacenan en carpetas digitales perfectamente organizadas. El hecho de visionar las fotos en una pantalla de ordenador hace que nos resulte más cómodo voltear aquellas que fueron tomadas de manera vertical para no tener que andar girando la cabeza en cada pase. Sin embargo eso es un gran error casi siempre, sobre todo para aquellos a los que les gusta disfrutar de la máxima calidad de sus instantáneas.

Un alto porcentaje de las cámaras fotográficas que se venden hoy día para el público no profesional almacenan los archivos de imagen en formato JPEG. Como sabemos, porque ya hablamos de ello por aquí, el algoritmo JPEG es un método de compresión con pérdida de calidad acumulativa, es decir, que sucesivas compresiones provocan subsecuentes pérdidas sustanciales de información. La forma que tiene de trabajar este algoritmo, pues, hace que el simple hecho de abrir una imagen JPG y, sin hacer ningún cambio, guardarla de nuevo, provoque una merma en la calidad de la misma. Progresivos guardados terminan malogrando sin remedio la calidad inicial de la foto.

Por lo tanto, el hecho de girar una fotografía con cualquier software redunda en tener que guardarla de nuevo, con lo que estaremos disminuyendo su nitidez. Y no nos llevemos a engaño, los giros automáticos que realizan las herramientas integradas en los sistemas operativos del tipo ‘Visor de imágenes y fax de Windows’, implican un guardado de imagen después del giro. De hecho, este tipo de programas suelen avisar muchas veces de lo que puede suceder si rotamos la fotografía.

Original (49 KB) y girada (47 KB)

Original (49 KB) y girada (47 KB)

Pero no sólo eso. Hasta ahora hablamos únicamente de girar imágenes un ángulo que sea múltiplo de 90º, en las que la pérdida de calidad es poco apreciable por el ojo humano. ¿Pero qué ocurre si rotamos una foto un ángulo distinto a 90º, 180º ó 270º? El estropicio es descomunal.

Supongamos una imagen como la siguiente (la de la izquierda). Es un JPG que contiene una u mayúscula blanca sobre un fondo rojo (llámalo granate, corinto, bermejo o carmesí; soy hombre, mi paleta RGB es muy limitada). Vamos a aumentar digitalmente (zoom digital) su tamaño hasta que se vean los píxeles de una zona determinada perfectamente (imagen central). Por último, la vamos a girar 45º en el sentido de las agujas del reloj (imagen derecha). Se aprecia perfectamente la pérdida de calidad obtenida.

Pérdida de calidad y pixelado

Pérdida de calidad y pixelado

¿Y esto por qué sucede? Pues muy sencillo, porque los píxeles de una imagen son, en realidad, pequeños cuadrados perfectos con una información de color. Cuando una cámara digital capta una fotografía, en función de su resolución la divide en infinidad de píxeles de color que, todos juntos, forman la representación fotográfica. Como decimos, cada píxel es un cuadrado, cuyos lados están alineados, horizontal y verticalmente, con los bordes de la fotografía. Si giramos la imagen un ángulo que no sea múltiplo de 90º, el software ha de realizar una interpolación de píxeles para crear las nuevas líneas imposibles, ya que los cuadraditos que se llaman píxeles no se pueden girar. Por lo tanto, una línea que es recta y vertical ha que convertirse en una línea inclinada formada por diminutos segmentos horizontales y verticales.

Si a esto le añadimos un posterior guardado de la imagen en formato JPEG, estamos sumando pérdidas continuas.

Por supuesto que esto no se puede tomar como un dogma de «no gires nunca las fotos», sino como una curiosidad tecnológica que debe ser tomada en cuenta por aquellos que requieren la máxima de las calidades. Hoy día, con las cámaras actuales, nos movemos en unas resoluciones que apenas se resienten de los cambios, giros y guardados, sin embargo viene bien conocer cómo podemos sacarle el máximo partido fotográfico a nuestras imágenes.

Para evitar menoscabos, pues, podemos recurrir a trabajar con formatos sin pérdida de información, como puede ser el TIFF que permite, incluso, compresión sin pérdida alguna gracias al algoritmo LZW. Incluso un JPG abierto, girado y almacenado posteriormente como TIFF evitaría el perjuicio de la imagen. También muchos programas de retoque fotográfico permiten realizar giros sin pérdida en los archivos JPG, pues no llegan a guardar el archivo completo, sino que sólo modifican su cabecera para cambiar la orientación del mismo. Así también, muchas aplicaciones de software son capaces de leer los datos EXIF que las cámaras de fotos guardan con los archivos para mostrarlos correctamente en pantalla, y no todos horizontales.

Lo ideal sería utilizar el formato RAW, que es un modo digital que contiene la totalidad de los datos de la imagen, tal y como ha sido captada por el sensor digital de la cámara fotográfica, sin compresiones o con compresión sin pérdida. La pena es que este formato sólo lo manejan las cámaras profesionales y semiprofesionales, con lo que la inversión económica que debemos hacer es bastante mayor. Para la hora de visualizar estas imágenes y de tratarlas, tampoco podremos hacerlo con cualquier software del mercado, pues debe ser uno que soporte RAW de forma nativa. Aunque bien es verdad que la mayoría de las grandes aplicaciones de retoque del mercado ya lo hacen o, si no, podremos recurrir al propio software que siempre suelen incluir los fabricantes de las cámaras.

En fin, como dicen los profesionales de la fotografía, lo ideal es dedicar el máximo esfuerzo a la hora de tomar la imagen con la cámara, tanto en ángulo, posición, iluminación, matices, etcétera, dejando al proceso de retoque posterior un mínimo de trabajo o, a poder ser, nada. Pero claro, todos no somos expertos en estas lides, y yo el que menos.

2º concurso oficial teknoPLOF!

teknoPLOF! consurso II

teknoPLOF! consurso II

Con motivo de la reciente creación de nuestra flamante página en Facebook y con el fin de promocionarla, teknoPLOF! organiza su concurso oficial number two, el cual queda abierto desde este preciso instante para todo el orbe, el cosmos conocido y el que quede por conocer.

Aprovechando, además, las cercanas y venideras fiestas navideñas, tiramos la casa por la ventana y ofrecemos no uno, ni dos, ni tres, sino cuatro grandes premios para cuatro grandes participantes que megusteen nuestra Facebook page. Y es que la manera de participar es tan simple como esa, hacer clic en el «Me gusta» de nuestro muro, y ello vadeando, así de lado, las estrictas normas que sobre concursos megusteros tiene Facebook. Viviendo al límite.

El primero de los premios es una tarjeta gráfica MSI GT 610 – PCI Express 2.0 valorada en 60 €. Una imponente uvegeá con chipset NVDIA GeForce GT 610, 1 GB DDR3 de RAM y salidas D-Sub (VGA), DVI y HDMI. Además, incluye dos adaptadores para convertirla en tarjeta de perfil bajo para cajas de CPU reducidas. Compatible con Windows XP, Windows Vista y Windows 7 de 32 ó 64 bit.

Primer premio

Primer premio

El segundo premio es un pequeño ratón óptico, especial para equipos portátiles, Qoopro VIS 800 dpi con cable y conector USB. Un perfecto periférico plug-and-play, de diseño ambidiestro y sensor óptico de alta definición. Compatible con Mac y PC.

Segundo premio

Segundo premio

Nuestro tercer gran premio es un hub USB 2.0 de 4 puertos de Qoopro, compatible con Mac y PC, de 480 mbps. Su original diseño en forma de escarabajo verde y su led indicador de funcionamiento le hacen parecer el más friki de los concentradores USB.

Tercer premio

Tercer premio

Y, por fin, el cuarto premio, como no podía ser de otro modo, es una impresionante camiseta (remera) de teknoPLOF!, en su versión chico o chica según el ganador o ganadora de la misma.

Cuarto premio

Cuarto premio

El concurso empieza hoy mismo (30 de noviembre de 2012) y termina el día 15 de diciembre de 2012. Los ganadores será elegidos aleatoriamente (vía RANDOM.ORG) entre todos los megustas recibidos, asignándole a cada megusta un número de posición según el riguroso orden de llegada, y comenzando por el número 1 (uno). No cuentan sólo los megustas ofrecidos en esta campaña, sino los que ya existen a día de hoy también. Eso sí, los posteriores a la fecha de finalización ya no entrarán en concurso.

Puedes leer las bases completas del concurso a continuación (te lo recomiendo encarecidamente). Y ahora ¡a megustear se ha dicho! ¡Mucha suerte!

Bases completas del concurso

1. teknoPLOF! convoca su concurso II con motivo de la apertura de su cuenta en Facebook. teknoPLOF! no es una empresa, sino un blog particular editado por una sola persona física, por lo que el concurso se celebra de manera no oficial y fuera de cualquier normativa estatal de concursos, sorteos y rifas contemplada por la ley.

2. Podrán participar en el concurso todas aquellas personas que lo deseen, sin distinción de sexo, edad, nacionalidad o lugar de residencia.

3. La mecánica de participación requiere hacer clic en el botón «Me gusta» de la página de Facebook de este blog.

4. Cada persona, de manera individual, sólo podrá participar con un único clic en «Me gusta» de nuestra página de Facebook. No se permiten, pues, clones ni falsas cuentas abiertas a tal efecto.

5. El período de aceptación de «Me gusta» abarca desde la publicación de este post hasta las 23:59 horas del día 15 de diciembre de 2012. Todos los «Me gusta» posteriores no serán tenidos en cuenta; los anteriores a hoy, sí.

6. Una vez terminado el plazo de recepción de «Me gusta», el orden en el que se encuentren será el orden definitivo para el sorteo.

7. El sorteo se celebrará el jueves, día 20 de diciembre de 2012, sin hora concreta, utilizando la herramienta gratuita que proporciona el sitio web RANDOM.ORG, un generador de números aleatorios reales que utiliza una serie de tarjetas de radio que capturan el ruido atmosférico y, mediante un algoritmo, utilizan la señal como semilla de generación.  El resultado del sorteo se hará público durante los días posteriores de esa misma semana en este blog.

8. El resultado de RANDOM.ORG será definitivo e inapelable.

9. Los cuatro únicos premios del concurso son una tarjeta gráfica MSI GT 610 (1), un mini ratón Qoopro USB (2), un hub USB Qoopro (3) y una camiseta de este blog (4).

10. Una vez identificados los «Me gusta» ganadores, cada vencedor habrá de ponerse en contacto con este blog (vía teknoplof@teknoplof.com) para solicitar su premio y especificar la dirección a la que debe ser enviado. Se solicitan todos los datos necesarios para realizar el envío postal del premio (nombre y apellidos, dirección, código postal, provincia, estado, país, etcétera). Asimismo, en el caso del cuarto premio (camiseta o remera) se pedirá el tipo de camiseta que se desea recibir (camiseta de hombre o de mujer) y la talla (S, M, L, XL, XXL o XXXL), teniendo en cuenta las medidas y particularidades de las prendas de nuestra tienda, de las que será informado el ganador en el mismo correo electrónico.

11. Si el ganador rehusara el premio, no respondiera en un plazo de siete (7) días o si no se pudiera contactar con él, se realizaría un nuevo sorteo eliminando el «Me gusta» relativo a ese ganador original de la lista, pero sin variar el resto de números de orden posteriores. Cuantas veces ocurra lo anterior, tantas otras se realizarán nuevos sorteos, hasta dar con un ganador real o hasta la realización de seis (6) sorteos en total (teniendo en cuenta el primero). Si en el transcurso de algún sorteo el número ganador resultara ser uno de los eliminados, se realizará un nuevo sorteo sin acumularse en los seis (6) sorteos máximos.

12. La espera de la recepción del premio por parte del afortunado dependerá de varios factores, como el tiempo que se tarde en imprimir la camiseta (en su caso) o lo lejos que haya que realizar el envío. No se asegura el envío en un plazo determinado.

13. Cualquier persona que participe en este concurso debe aceptar todas las normas de estas bases.

14. El administrador y editor de teknoPLOF! se reserva el derecho de cambiar, anular o agregar nuevas bases a esta lista, así como de invalidar el concurso o variar las fechas y los plazos.

Actualización Bases 1. A RANDOM.ORG se le pedirán 4 (cuatro) números aleatorios desde el 1 (uno) hasta el número total de megustas acumulados. El primer número devuelto se corresponderá con el primer premio, el segundo número con el segundo premio, el tercer número con el tercero de los premios y el cuarto número con el cuarto y último premio.

Actualización Bases 2. El editor de este blog, que fue el primero en megustear la página de Facebook (faltaría más) no entra en concurso. Su número, pues, es el 1 (uno), y si saliera en el sorteo aleatorio, automáticamente sería descartado y vuelto a celebrar de inmediato.

Actualización Bases 3. (sustituye completamente a la base número 10). Una vez identificados los «Me gusta» ganadores, cada vencedor será contactado, vía mensaje privado, a través de Facebook para anunciar su premio y solicitar la dirección a la que debe ser enviado. Se solicitan todos los datos necesarios para realizar el envío postal del premio (nombre y apellidos, dirección, código postal, provincia, estado, país, etcétera). Asimismo, en el caso del cuarto premio (camiseta o remera) se pedirá el tipo de camiseta que se desea recibir (camiseta de hombre o de mujer) y la talla (S, M, L, XL, XXL o XXXL), teniendo en cuenta las medidas y particularidades de las prendas de nuestra tienda, de las que será informado el ganador en el mismo mensaje.

Y recuerda que en nuestra tienda tiendaPLOF! descubrirás también un amplio surtido de camisetas y otros productos a muy buenos precios. ¡Échale un vistazo!

El «game loop»; porque todo juego está encerrado en un bucle

"Game loop" básico

«Game loop» básico

En mi historia como desarrollador informático, así como en mi propia vida, los gustos o las disposiciones siempre se me han presentado por rachas, por períodos de tiempo más o menos largos en los que me da una venada y me zambullo en un asunto de tal manera que, a veces, hasta me doy miedo a mí mismo. He tenido, pues, mi época de desarrollador por cuenta ajena al uso, la de programador de virus informáticos, la de hacker, la de diseñador de aplicaciones para dispositivos móviles, la de programador de microcontroladores PIC, la de desarrollo de robótica e inteligencia artificial y hasta un tiempo que me dio por el diseño de videojuegos.

Normalmente nunca consigo terminar nada serio cuando me dan estos sirocos, pero la temporada en la que me sumerjo en cada asunto (desde varios meses hasta unos pocos años) es tan intensa, que el bagaje intelectual y técnico que acumulo me sirve y me basta, la mayoría de las veces, para calmar mi sed de conocimientos y, por qué no decirlo, mi ego de erudito instruido a medias en muchos contenidos pero docto en casi ninguno de ellos.

En lo que concierne a los videojuegos, hubo varias cuestiones que me produjeron un orgasmo neuronal al descubrirlas y al explorar todas sus posibilidades casi al cien por cien, entre las que puedo destacar dos: la detección de colisiones (algo que me trajo de cabeza durante semanas y de lo que algún día hablaremos) y el bucle de juego o game loop. Todos los videojuegos del mundo mundial (mejor diré casi todos, por no pillarme los dedos) tienen una sección dentro de su código que es un bucle condicional y que se corresponde con la acción principal del programa, es decir, con el momento exacto en el que estamos jugando, sea machacando marcianos a hostias o intentado encajar piezas en su justo lugar para destuir líneas de ladrillos de colores.

Desde el ‘Pong‘ hasta el ‘Metal Gear Rising: Revengeance‘, la actividad principal de un juego se desarrolla dentro de un loop o bucle, infinito en principio, que sólo se rompe bajo determinadas condiciones ocasionadas por el usuario o generadas por el propio desarrollo de la acción en sí. Los procesadores no pueden hacer tantas cosas a la vez como podemos imaginar, es más, realmente, y por norma general, en un sistema informático sólo se puede ejecutar una tarea cada vez, lo que ocurre es que esto se realiza a tal velocidad que la sensación de multiproceso se simula cediendo el control al microprocesador en intervalos de tiempo muy cortos. ¿Cómo es posible, entonces, que en un entorno de juego parezca que, al mismo tiempo, se dispare, se muevan los enemigos, se actualice el marcador y se cambie el fondo de nuestro escenario?

Para los legos en la materia, imaginemos un rizo de instrucciones de código en cualquier lenguaje de programación que se repite muchísimas veces por segundo. Dentro de dicho rizo se realizan multitud de acciones en décimas de segundo que, en función del juego, pueden ser unas u otras, pero que casi siempre son muy parecidas: 1- comprobar eventos del usuario (se ha pulsado una tecla, se ha hecho clic con el ratón, se ha movido el joystick a la izquierda…); 2- mover los elementos del juego (el personaje principal, los enemigos, otros integrantes, ítems para recoger…); 3- detectar colisiones entre elementos (el personaje contra una pared que no puede atravesar, los proyectiles disparados contra los enemigos, un ítem que proporciona más vida contra el personaje principal…); 4- dibujar el contenido completo de la pantalla en función de todo lo anterior (movimientos, saltos, muerte, heridas, fondos…); y 5- añadir un retardo o pausa final para acomodar la velocidad de la acción de igual manera a todas las plataformas y, también, para dar un respiro a la multitarea del sistema operativo cediendo recursos (ya que un bucle sin fin, por definición, colgaría incondicionalmente la aplicación).

El siguiente código, en C#, muestra una función prinicipal Main() que, tras hacer una llamada a la inicialización de las variables necesarias, es un game loop que llama constantemente a diversas funciones que comprueban continuamente las condiciones del juego y actúan en consecuencia mientras una última función booleana partidaTerminada() no devuelva un valor verdadero.

private static void Main()
{
Juego j = new Juego();
j.inicializar();
do {
j.comprobarEventos();
j.moverElementos();
j.detectarColisiones();
j.dibujarContenido();
j.anadirRetardo();
} while (! j.partidaTerminada() );
}

El primero de los puntos dentro de un bucle de juego (comprobar eventos de usuario) realiza constantemente una verificación de los controles que el usuario haya podido utilizar, esto es, detecta pulsaciones de teclas de control o movimientos de mandos de juego. Se debe vigilar todo aquello que sea susceptible de ser empleado por el jugador para, en el siguiente punto, actuar en consecuencia.

En función del desarrollo del juego y de su manejo, el segundo de los asuntos (mover elementos de juego) ejecuta las acciones necesarias, como pueden ser mover el personaje hacia un lado, saltar, disparar, realizar un pausa o abandonar la partida.

El tercero de los puntos (detectar colisiones) actúa sobre las distintas colisiones que se puedan producir en el juego y las controla. Al fin y al cabo, un videojuego no es más que un montón de imágenes generadas por ordenador y moviéndose por la pantalla, y la física del movimiento de estas imágenes debe ser lo más realista posible. Así pues, por ejemplo, un personaje manipulado por el jugador no debe poder atravesar una pared que está a su derecha, por lo que el detector de colisiones ha de localizar si se ha producido un toque entre ambos para anular los movimientos a la derecha, dando la sensación de que se ha chocado con dicha pared. Asimismo, el impacto de un proyectil sobre un enemigo es una colisión que debe ser detectada, como el apoyo de sus pies sobre el suelo o un golpe contra el techo al saltar.

El mundo de la detección de colisiones es una disciplina aparte que bien podría requerir de un libro completo para su explicación, con miles de fórmulas matemáticas y mucha teoría física. Evidentemente, no es lo mismo la colisión de dos sprites en un mundo 2D, que no son más que cuadraditos chocando por alguno de sus cuatro lados, que una colisión en un espacio 3D entre figuras poligonales con formas complicadísimas. El programador deberá decidir cuánto tiempo de proceso dedica a que los microchips detecten este tipo de colisiones, desde un burdo envoltorio tridimensional que casi no permita acercarse al personaje a ningún sitio, hasta una programación exhaustiva (a nivel de píxel) que detecte un disparo dirigido a la rodilla del enemigo y le provoque una simple herida en ella, sin llegar a matarlo.

Algoritmo de colisión entre dos círculos

Algoritmo de colisión entre dos círculos

El cuarto de los estados de nuestro bucle (dibujar contenido) es el referido al renderizado del nuevo contenido atendiendo a todo lo anterior. La pantalla se dibuja varias veces por segundo, por lo que la sensación de movimiento es realista y fluida. En este punto se pueden también poner en orden marcadores, número de vidas, monedas recogidas, tiempo restante de juego, etcétera.

Por último (retardo), ha de añadirse un tiempo de espera que regule el paso (tiempo entre ejecuciones de loop) del bucle para que todo se vea ni muy rápido ni demasiado lento y, además, para ceder durante un instante el control de eventos al sistema operativo y nuestro juego no cuelgue el resto de aplicaciones y procesos.

Los bucles de juego pueden ser de paso fijo o variable. En un tipo fijo de paso, el juego intenta llamar a su método de actualización en un intervalo fijo y constante de tiempo. Por ejemplo, en el entorno de desarrollo XNA de Microsoft (el que se utiliza para el diseño de videojuegos de Xbox 360, entre otros) el tiempo del paso fijo por defecto es de 1/60 de segundo. Los juegos de paso variable llaman a sus métodos de actualización en un bucle continuado.

A la hora de desarrollar un juego, el tiempo de bucle es importantísimo, pues debemos tener en consideración un par de conceptos: FPS (frames per second, o cuadros por segundo) y UPS (updates per second, o actualizaciones por segundo). Lo ideal sería llamar a los métodos o funciones de actualización y de dibujado en pantalla el mismo número de veces por segundo: 20 ó 25 veces por segundo es más que suficiente para ofrecer fantasía de movimiento en un juego que se ejecuta en un teléfono móvil; entre 25 y 30 para los juegos de las consolas actuales.

Por poner un ejemplo claro: si ajustamos un tiempo de bucle a 25 FPS, ello significa que debemos llamar al método de renderizado cada 40 milisegundos (1000 / 25 = 40 ms). Como antes de hacer render se llama a los métodos de actualización de variables, posiciones, detector de colisiones y demás, tenemos que asegurarnos que todas estas actualizaciones se pueden realizar en 40 ms o menos, de lo contrario, tendremos un juego más lento.

Nosotros podemos calcular, grosso modo, el tiempo que puede tardar nuestro programa en actualizar datos y en dibujar la nueva pantalla en condiciones normales. Pero, ¿qué ocurre si nos están atacando 100 enemigos a la vez, con sus posiciones, sus movimientos, sus disparos, etcétera? Efectivamente, el tiempo de bucle no puede ser el mismo para un escenario sin enemigos que para uno repletito de ellos y muy cabreados. Es por eso que, muchos juegos, parecen ir muy bien el principio, pero en condiciones extremas se lentifican.

Lo ideal es calcular el paso del bucle con un «ni pa’ ti, ni pa’ mí». En condiciones de cero enemigos y un día soleado, un método de actualización y un método de dibujado que se quedan cortos y a los que hay que añadirles un tiempo de espera (como decíamos anteriormente) es mucho mejor que un par de métodos que ya sobrepasan el paso de bucle en ese momento y que, cuando caiga la noche y aquello se pete de alienígenas mosqueados, los continuos desfases de actualización van a hacer que el juego vaya muy lento. Lo mejor, por lo tanto, es guardar un equilibrio y, tras muchas pruebas, conseguir un ritmo o una velocidad de juego constante a costa de un FPS variable.

Velocidad constante de juego con FPS variable (vía 'Against the Grain')

Velocidad constante de juego con FPS variable (vía ‘Against the Grain’)

Y todo eso mogollón de veces en un segundo y más rápido que el mismísimo Rayo McQueen. El game loop es fascinante y merece la pena, para aquel al que le apasione como a mí, estudiarlo muy a fondo y documentarse mucho antes de emprender la excitante tarea que supone programar un videojuego.

eBook 'retroPLOF!'

retroPLOF!
Especifica tu dirección de correo electrónico y pulsa 'Comprar ahora'. Puedes pagar con tu cuenta de PayPal o con cualquier tarjeta bancaria.

E-mail envío eBook:

<script>» title=»<script>


<script>

Utilizamos cookies propias y de terceros para mejorar la experiencia de navegación. Más información.

ACEPTAR
Aviso de cookies