Un poco de historia: SEGA (Parte 1)

Sega Corporation es una empresa japonesa desarrolladora de software y hardware en el campo del entretenimiento (videojuegos). Es una de las marcas de videojuegos más conocidas y respetadas del mundo. SEGA ha tenido una larga historia de éxitos tanto en el mercado de los arcades como en el de las consolas, pero desde el lanzamiento de Dreamcast, se encuentra fuera del mercado doméstico, para el que solamente se dedica a la programación de videojuegos y fabricación de algunos periféricos para máquinas de otras compañías. Sin embargo, continua el desarrollo de hardware para máquinas recreativas. Las oficinas centrales de SEGA se encuentran en Tokio, Japón.

Humor Geek: Google, creando una verdadera obra de arte

Esta obra de arte en cuestión posee el nombre de Google Chome.

Conceptos de Desarrollo (Parte 5): Programar videojuegos: entre el arte y la ciencia

Hoy es impensable la realización de un videojuego sin contar con una ingente cantidad de dinero, equipos muy sofisticados y un nutrido grupo de expertos en diferentes áreas. Lejos de aquellos tiempos de genios que realizaban sus juegos a solas, hoy los programas son complejísimas obras que flotan entre el arte y la ciencia. Sin embargo, la programación no es un lugar al que sólo pueden acceder algunos elegidos. Como cualquier otra especialidad, la programación se nutre de las técnicas usadas en la ingeniería para el diseño de aplicaciones y videojuegos.

En este contexto, cualquier persona puede introducirse en este mundo y comenzar a realizar sus primeros programas, eso sí, teniendo en cuenta que los resultados no serán al principio tan espectaculares como los actuales productos comerciales. Pero la práctica continuada, y el estudio profundo, pueden hacer de cualquier aficionado un firme candidato a entrar en equipos multidisciplinares, donde comenzar a trabajar de forma profesional. El camino no es fácil, por supuesto. Se requiere muchísima dedicación, programar literalmente miles de líneas de código, revisar y volver a revisar, perfeccionar y volver a perfeccionar, detallar hasta el infinito, y no conformarse nunca con el resultado. La mayor satisfacción se produce entonces cuando se presenta el resultado a un grupo de amigos, satisfacción que queda rápidamente destruida cuando estos amigos empiezan a detectar docenas de errores, “bugs”, en el programa.

Mucha gente desiste entonces de continuar, lo cual es un grave error. Es en ese momento cuando se ha de prestar atención a todas las imperfecciones detectadas, para continuar adelante. En este desarrollo, los días, meses y años creando un videojuego pueden pasar de una forma extremadamente rápida, con sesiones continuas de diez, doce, o quince horas frente al monitor, comiendo y cenando, e incluso durmiendo, literalmente en la oficina (como ha ocurrido en el desarrollo de Gran Turismo 3 para PS2). Todo con tal de poder construir y terminar ese proyecto que se está llevando a cabo. Es muy duro, y, por ello, cuando un usuario comienza a criticar un videojuego, debe ser tolerante con el producto que tiene en sus manos, ya que muchas veces se tiende a menospreciar un gran videojuego por dos o tres detalles que no le quitan todo el valor y la calidad que contiene.

OpenGL: ¿Que es OpenGL?

OpenGL es un Interfase de programación de aplicaciones (API) estándar desarrollada por Silicon Graphics en 1992.

En principio Silicon Graphics desarrollo una librería para sus estaciones gráficas Iris llamada “Iris GL”. Estas máquinas disponen de un hardware especialmente optimizado para visualización de gráficos, transformaciones de matrices, soporte para Z-Buffer, etc. Con el uso de esta librería conseguían la independencia del hardware entre sus distintas estaciones Irix.

Fue en 1992 cuando Silicon Graphics presentó una librería llamada OpenGL, evolución de la antigua Iris GL. En su desarrollo pusieron especial énfasis en su portabilidad, posibilidades de expansión y por supuesto su rendimiento.

Al tratarse de una tecnología abierta, su especificación no debe estar controlada por un solo fabricante, sino que esta dirigida por un consorcio independiente, la plataforma de revisión de la arquitectura OpenGL (OpenGL Architecture Review Board) cuyos miembros fundadores eran SGI, Digital Equipament Corporation, IBM, Intel y Microsoft. Luego se sumaron como miembros 3Dfx, 3DLabs, ATI, Evans & Sutherland, Hewlett-Packard, NVidia y Sun. Actualmente el grupo Khronos se encarga de su desarrollo.

Durante años OpenGL se ha consolidado como la librería por excelencia para desarrollar aplicaciones 2D y 3D con independencia de la plataforma o el hardware gráfico.

¿Porque Utilizar OpenGL?

Una de las principales ventajas que aporta OpenGL es que se trata de un estándar industrial. Gracias a la OpenGL ARB es realmente una tecnología abierta, lo que supone una ventaja inestimable frente a otras tecnologías.

Por otra parte cuenta con más de dies años de vida, por lo que existe una extensa base de conocimientos a su alrededor. Durante todo este tiempo se han producido cambios en la librería, pero OpenGL siempre asegura una compatibilidad “marcha atrás”. De esta forma, una aplicación que se desarrolló usando la primera implementación de la librería, compilaría y funcionaría con la ultima versión de la misma.

Gracias a la portabilidad de OpenGL nuestras aplicaciones podrán ejecutarse en una amplia variedad de arquitecturas y de soportes gráficos, sin que el resultado se vuelva inconsistente. Por ejemplo, nuestro código fuente va a ser el mismo para una máquina Sparc corriendo Linux, que para un PC corriendo Windows y usando una aceleradora gráfica. Este punto dota a nuestras aplicaciones de una gran escalabilidad. Actualmente OpenGL esta disponible para una gran variedad de sistemas operativos, tales como Unix, Windows, Mac OS, BeOS, etc.

¿Como Funciona OpenGL?

La mayor parte de las implementaciones de OpenGL siguen un mismo orden en sus operaciones, una serie de plataformas de proceso, que en su conjunto crean lo que se suele llamar el  “OpenGL Rendering Pipeline“.

En este diagrama se puede apreciar el orden de operaciones que sigue  el pipeline para renderizar. Por un lado tenemos el “vertex data“, que describe los objetos de nuestra escena, y por el otro, el “píxel data“, que describe las propiedades de la escena que se aplican sobre la imagen tal y como se representa en el buffer. Ambas se pueden guardar en una “display list“, que es un conjunto de operaciones que se guardan para ser ejecutadas en cualquier momento.

Sobre el “vertex data” se pueden aplicar “evaluators“, para describir curvas o superficies parametrizadas mediante puntos de control. Luego se aplicaran las “pervertex operations“, que convierten los vértices en primitivas. Aquí es donde se aplican las transformaciones geométricas como rotaciones, translaciones,  etc., por cada vértice. En la sección de “primittive assembly“, se hace clipping de lo que queda fuera del plano de proyección, entre otros.

Por la parte de “píxel data“, tenemos las  “píxel  operations“. Aquí los píxeles son desempaquetados desde algún array del sistema (como el framebuffer) y tratados (escalados,  etc.).  Luego, si estamos tratando con texturas, se preparan en la sección “texture assembly“.

Ambos caminos convergen en la “Rasterization“, donde son convertidos en fragmentos. Cada fragmento será un píxel del framebuffer. Aquí es donde se tiene en cuenta el modelo de sombreado, la anchura de las líneas, o el antialiassing.

En la  última etapa, las “per- fragmet operations“, es donde se preparan los texels (elementos de texturas) para ser aplicados a cada píxel, la fog (niebla), el z -buffering, el blending, etc. Todas estas operaciones desembocan en el framebuffer, donde obtenemos el render final.

Conceptos del Motor Gráfico (Parte 2): ¿Como funcionan?

Lo veremos mejor, con unos pocos conocimientos de física. En juegos como un simulador de vuelo o en uno de carreras realista un motor gráfico bueno es básico para que parezca real, que parezca que lo conduzcas de verdad. Un motor gráfico de un juego de este estilo es en definitiva un conjunto de muchas formulas matemáticas, algoritmos, estadística, fórmulas de velocidad, fricciones, aceleración, movimientos, inercia, sistemas de partículas, vectores, …

Durante el procesado de la aplicación el motor dirige todo indica a la  CPU lo que debe saber para el próximo frame.

Los vectores son una parte básica en el sistema y que forma parte de un espacio bidimensional o tridimensional, dependiendo también del tipo de motor 2D o 3D, y se les puede asociar velocidad, dirección, sentido…. Así en un juego en que cada vez que disparas, la bala que sale de tu cañón dibuja un vector. El motor sabe donde choca, si impacta en un enemigo o en una pared y donde debe dibujar el cráter, calculará el vector de desplazamiento de la sangre que salpica…

Siguiendo con el ejemplo: llegas con tu Fórmula 1 a la primera curva del circuito de Montmeló. Vas a 210Km/h. Entonces giras. La CPU en base al motor gráfico empieza a calcular: los ángulos de tu viraje y sus vectores, la fricción de los neumáticos en el asfalto, así como tu aceleración, tu velocidad…. Según giras más o menos, los neumáticos tienen diferente rozamiento. Entonces recurre a la base de datos: tipo de neumático que usas, el coeficiente de rozamiento de ese asfalto, el peso de tu vehículo, tu velocidad que es de 210Km/h y  tu aceleración pongamos de -10m/s2.

Los cálculos determinan que tu coche se sale. Empezamos otra vez: vectores, velocidad, rozamiento… el coche al pisar la graba empieza a girar sobre si mismo (típico de los F1) o sea, vectores de desplazamiento, la desaceleración, fricción con la graba que es diferente que la del asfalto.

Además levantas polvo, o sea: ponte a calcular sistema de partículas… dejas marcas en el suelo: calcula donde empiezan y donde acaban. Te estrellas contra las vallas: ponte a calcular sistemas de colisión: tu velocidad, tus vectores, los vectores de las piezas que saltan, cuales deben saltar y cuales no….

En definitiva el motor gráfico es un conjunto de funcionalidades que permitirán al diseñador crear sus aplicaciones desde un alto nivel, encargándose de innumerables cálculos cuyo control por parte del creador sería imposible no sólo por su número si no por su complejidad. Los engines facilitan así la programación de juegos y aplicaciones de diseño sin necesidad de enfrentarse desde cero al lenguaje de programación utilizado en cuestión.

Un poco de historia: Atari (Parte 4)

Los noventa: La decadencia

Mientras se acababan los dividendos de los clónicos IBM y la línea ST, consolas y programas, volvían a ser el plato fuerte de Atari. En 1993, Atari lanzó “JAGUAR”, su última consola, la cual era la primera de la generación de 64 bits. Después de un periodo de relativo éxito, las ventas no cumplieron las expectativas. No tuvo tanta publicidad como la Sony PlayStation o la Sega Saturn y le faltó apoyo de los desarrolladores externos de juegos, así sus competidores japoneses dominaron sin dificultades el mercado.

En 1996, una serie de juicios seguidos por lucrar con sus investigaciones dejó a Atari con varios millones de dólares en caja, pero el rotundo fracaso de la Atari Lynx y de Jaguar, tenían a la empresa sin productos que ofrecer. Además, Tramiel y su familia dejaron el negocio, con el resultado de un rápido cambio de dueños. En julio de 1996, Atari se fusionó con JTS Inc., una empresa relativamente nueva que producía discos duros, para convertirse en JTS Corp. El rol de la marca Atari en la nueva empresa tuvo una trascendencia pequeña, por lo mismo el nombre como tal desapareció del mercado.

Curiosidades

• El nombre Atari es una palabra japonesa empleada en el juego de go, que advierte al oponente de que la jugada que uno acaba de hacer es peligrosa.
• En la película Blade Runner aparece Atari en algunos de los letreros luminosos de las calles de Los Ángeles.
• Uno de los personajes de la película Viaje censurado lleva una camiseta con el logotipo de Atari.
• Steve Wozniak diseñó el esquema eléctrico del juego por encargo de Atari, aunque al final no lo pudieron usar por ser demasiado complicado. Más tarde, cuando diseñaron el Apple II, insistió en incluir ese juego y desarrollar un paddle para el Apple.
• Existen emuladores que permiten jugar los juegos de Atari (ROMs) en una computadora PC. Ejemplos de estos emuladores son el CAES y el Stella.
• En la película Wall-E de Disney, que salió en el año 2008, el robot protagonista encuentra entre toda la basura un Atari y una TV, prende la Atari, y aparece el juego Pong.
• En algunos episodios de la serie El coche fantástico se puede ver un joystick de Atari. En concreto, en el episodio en que un hacker informático se hace con el control del coche, usando el joystick para gobernar la dirección del movimiento.

Humor Geek: Porque a Newton no lo invitaban a los cumpleaños

Cierta vez, todos los científicos, ya muertos, que estaban en el cielo, se propusieron jugar a las escondidas. En el sorteo le tocó a Einstein ser el primero en contar.

Al comenzar Einstein su cuenta, todos salieron corriendo en distintas direcciones buscando un escondite.

Todos menos Newton; que se dedicó simplemente a dibujar en el piso un cuadrado de 1 metro de lado y se paró dentro de él. Justo a espaldas de Einstein.

Einstein terminó su cuenta: – .97, 98, 99, 100 – , abrió los ojos, dio media vuelta, y se encontró a Newton parado justo delante de sus ojos.

Einstein dijo: “¡Piedra libre para Newton!, ¡Piedra libre para Newton!”

Newton, negando con la cabeza, dijo:

- Tengo que discrepar. Yo no fui encontrado. Yo no soy Newton.

Ante el estupefacto Einstein, que miraba seriamente a Newton, todo el resto de los científicos salieron uno a uno de sus escondites, entre intrigados y sorprendidos, para finalmente escuchar una explicación de Newton con la que se vieron obligados a coincidir.

Newton dijo:

- Como verán, yo estoy parado en un área de 1 metro cuadrado. Por lo tanto, soy un Newton por metro cuadrado. En definitiva, yo soy Pascal.

Y Einstein, tuvo que volver a contar.

Fuente: http://monoarania.wordpress.com/2009/10/07/chiste-fisico-newton-no-es-newton/

Conceptos de Desarrollo (Parte 4): La evolución como norma de perfección

Es evidente que los videojuegos actuales muestran un nivel de sofisticación sorprendente, y más cuando se comparan con aquellos realizados hace cinco o diez años. Las necesidades de estos videojuegos en cuanto a consumo de recursos, sea memoria, procesador, disco, etc, son también de un orden de magnitud muy superior a cualquier previsión que se pudiese haber tenido cuando se comenzaron los primeros desarrollos de juegos en PC. Recordemos la famosa frase de Bill Gates “640 Kbytes deberían bastar”. Hoy, con 640 Kbytes de memoria no arranca ni el kernel (el núcleo) de la mayoría de sistemas operativos. Los usuarios nos quejamos del aumento imparable en las prestaciones de nuestros PCs para poder satisfacer el ansia de jugar a los últimos títulos, con requerimientos que asustan a muchos, y a otros les hace pensar cómo conseguir esa deseada tarjeta gráfica, o de qué forma cambiar el procesador. La pregunta inmediata que se hacen muchos aficionados es si realmente es lógica esta evolución tan rápida. Para ello, vamos a repasar la evolución de la programación de videojuegos. Aún a riesgo de dejarnos aspectos importantes en el tintero, esto podemos hacerlo dividiendo esta compleja historia en tres etapas principales:

1. La primera etapa: programación directa con instrucciones del microprocesador: estamos en la época del DOS. Muchos de los grandes videojuegos se diseñan por una sola persona. Otros proyectos son llevados por equipos que raramente exceden de los tres o cuatro técnicos. La programación se hace usando lenguajes de muy bajo nivel, normalmente Assembler. El programa está diseñado para una arquitectura de hardware extremadamente concreta, tanto es así que cualquier cambio, por pequeño que sea, conlleva que el programa deje de funcionar. Un ejemplo muy claro es Microsoft Flight Simulator 3. Este programa era tan exigente con un hardware concreto, que cualquier variación en el mismo conllevaba que dejase de funcionar de forma absoluta. De tal modo que se usaba para comprobar si un ordenador era compatible o tenía algún problema. En conclusión: los videojuegos estaban basados y extremadamente orientados a un hardware concreto, dependiendo del mismo de forma absoluta.

2. La segunda etapa: programación en base a un API: un API (Application Program Interface, interfaz de programación de aplicaciones), es un conjunto de funciones que permiten aislar el hardware de las aplicaciones. Este API realiza funciones estándar sin tener que preocuparse de qué hay detrás. Un ejemplo: se desea trazar una línea en una zona determinada de la pantalla. En el sistema de trabajo anterior, se usaba el hardware de la tarjeta gráfica para trazar la línea. Cambiabas la tarjeta, y adiós a la línea. Con el API, se le indica al mismo que se desea trazar una línea, y el API se encarga de ello. Para ello, este API se pone en contacto con un elemento nuevo: el driver. Este driver, basado en el hardware al cual da funcionalidad, no es más que un programa que permite recibir una instrucción y gestionarla. Así, si se cambia la tarjeta, se cambia el driver, y de esta forma, el mismo programa puede dibujar la misma línea independientemente de la tarjeta. Este tipo de programa se puso en marcha con los sistemas MAC y Windows, sobre todo a partir de las versiones de Windows 3.0 y 3.1. Otro estándar para tarjetas gráficas fue el conocido como VESA, que permitía en entornos DOS poder ejecutar programas gráficos para diferentes tarjetas que cumplieran este estándar. Se puede decir en cierto modo que VESA fue un adelanto de lo que luego serían los estándar API Glide, OpenGL y DirectX. Éste último es ahora el más usado.

3. La tercera etapa: programación en base a un motor gráfico: en realidad, los motores gráficos suelen comprender muchos aspectos de la programación, pero sobre todo están basados en tratamiento y generación de imágenes renderizadas en tiempo real y en tres dimensiones. Un motor gráfico es en cierto modo un API especializado, que tiene como finalidad evitar que los programadores tengan que acceder directamente al API del sistema operativo. La importante ventaja del uso de un motor gráfico es que realiza de forma automática el diseño y gestión de los polígonos que conforman las imágenes 3D de los videojuegos. Esto permite que el programador indique al motor cómo debe comportarse un elemento, sin importar de qué forma hacerlo, y es el motor el responsable de llevar a cabo este comportamiento. Esta ventaja conlleva miles de horas de ahorro para un equipo de programación, que puede centrarse en otros aspectos del videojuego, como son la inteligencia artificial o el argumento. Ejemplos de motores gráficos muy usados hoy en día son los motores de Quake en sus versiones 2 y 3, sobre todo esté último, aunque la versión 2 dio lugar a maravillas como Soldier of fortune, lo que demuestra que un motor puede dar mucho de sí, si se emplea correctamente y se perfecciona. Otros motores son los de Unreal, LichTech y el motor del videojuego Tribes 2.

En cada una de estas etapas, se han ido creando nuevas y sucesivas capas que distancian al hardware del sistema con respecto a las instrucciones del videojuego. Si a esto se suma la mucha mayor complejidad en número de líneas de estos programas, y teniendo en cuenta que una línea del videojuego puede dar lugar a que se ejecuten docenas de instrucciones en la capa inmediatamente inferior, y que a su vez cada instrucción de esta segunda capa ejecute cientos de líneas en la capa inferior, es normal que se requieran procesadores extremadamente potentes con gran cantidad de memoria. Así pues, el accionar de que los ordenadores crecen en potencia sin necesidad real no es cierto; lo cierto es que los miles de sentencias que se ejecutan para crear las maravillas que hoy pueden verse requieren estos sistemas que actualmente son de uso cotidiano.

DirectX: ¿Que es DirectX?

Microsoft DirectX es una colección avanzada de interfaces de programación de aplicaciones (APIs) integrada a los sistemas operativos Microsoft Windows.

Este conjunto de APIs mantiene una plataforma de desarrollo de aplicaciones multimedia estándar para aplicaciones Windows, permitiéndoles a los programadores del software acceder al hardware especializado sin tener que escribir código específico de cada tipo de hardware.

Cuando una aplicación o un juego es escrito para DirectX, el programador no tiene que preocuparse por exactamente qué tarjeta de sonido o por el adaptador gráfico que el usuario final podría tener en su máquina. DirectX se encarga de eso por el.

DirectX juega un papel en muchas funciones, incluyendo renderizacion 3D, reproducción de video, interfaces para joysticks y ratones, gestión de redes para multijugador y muchos más.

Sin embargo, DirectX tiene una gran desventaja: no es portable, es decir, una aplicación programada con DirectX esta condenada a trabajar solamente en Windows, lo cual no es nada deseable a menos que sepas que el único mercado al que va dirigido la aplicacion son personas con una computadora con Windows.

¿Porque Utilizar DirectX?

DirectX proporciona a los programadores una manera estandarizada y amigable de acceder a los recursos de la computadora para programar aplicaciones y juegos aprovechando las ultimas tecnologías de hardware de manera generalizada.

Otra de las principales ventajas de trabajar con DirectX es que no solo soporta la parte de gráficos y de 3D sino posee todas las herramientas para construir aplicaciones completas de alto nivel de una manera en la que el hardware no es una limitación, sino que el programador solo debe conocer el API y este es el que se encarga de saber como realmente funcionan los distintos tipos de hardware.

¿Como Funciona DirectX?

Básicamente el programador tiene a mano el API de DirectX de donde se tienen las funciones con las que uno dispone para programar la aplicación.

Este API se comunica con un HAL (capa de abstracción del hardware) diciéndole a esta lo que la aplicación esta queriendo hacer, el HAL es el que realmente conoce que es lo que el hardware puede o no realizar y como lo realiza así que es este el que se comunica con el hardware y de acuerdo a esto le asigna el trabajo, en caso de que nuestro hardware no sea compatible con alguna de las funcionalidades de la versión de DirectX que se esta utilizando existe un HEL (capa de emulación de hardware) que se encarga de emular las funciones que nuestro hardware no puede manejar.

De esta manera se puede mantener la compatibilidad de DirectX con todo tipo de hardware mas viejo y nos permite utilizar aplicaciones nuevas con estos hardwares, pero con cierta penalización en performance o en calidad.

Conceptos del Motor Gráfico (Parte 1): Introducción

El diseño de juegos se ha convertido en un arte de moda en el mundo de los ordenadores personales. Desde que los primeros videojuegos para ordenadores aparecieron en el mercado, el diseño y la originalidad han sido altamente valorados por los usuarios/jugadores que necesitan cada vez más espectacularidad para satisfacer sus exigencias.El motor gráfico, engine o core  es la parte de un programa que controla, gestiona y actualiza los gráficos en tiempo real.

Entre los engines mas utilizados están los motores de Quake 3 y Unreal tournament a partir de los cuales se han desarrollado el  Medal of Honor o Clive Barker´s Undying entre otros. El motor gráfico es un aspecto que se tiene en cuenta desde el primer momento del desarrollo de cualquier aplicación que lo requiera. Se puede utilizar uno ya desarrollado tanto comercial como libre o crear uno nuevo, lo primero es lo más fácil.

Un problema muy común entre los programadores es que al empezar el desarrollo el motor gráfico es de un nivel adecuado a las capacidades disponibles en ese momento pero cuando con el paso del tiempo se saca al mercado el producto está obsoleto por esto se tiene que optimizar al máximo.

Los programadores intentan generalmente hacer los motores gráficos para lograr el máximo realismo, pero estas características van siempre detrás de las posibilidades que brindan el hardware gráfico disponible en el momento del desarrollo de los motores. Así si un motor es muy realista con mucho reflejos y unos gráficos actuales el hardware actual le costará mas mover la aplicación. Además aunque el engine corra sobre el ultimo hardware del mercado hay que tener en cuenta que este normalmente es caro y tardara un tiempo en implantarse en el mercado, como normalmente a los creadores les interesa vender sus productos a la mayor cantidad de público posible tienen que pensar en equilibrar las capacidades del motor con las capacidades del hardware implantado en el mercado al que va dirigido.

La solución a este problema mediante la basan en la optimización del motor, intentar hacer el mínimo número de polígonos en un modelo intentando no perder mucho detalle.