Quien Soy (Parte II)

Continuando con lo anterior....

Una de las cosas que me venía llamando la atención desde hace un tiempo era DirectX. Cada vez que instalaba un juego nuevo, debía ceremonialmente instalar el componente, aunque no sabía ni qué era, ni para qué servía. Otra cosa que me sorprendió en ese tiempo fue el comienzo de los juegos en 3 dimensiones. Hasta entonces yo comprendía bien que en 2D bastaba con poner algunos sprites contra el fondo y hacerlos moverse. Las animaciones eran claramente una sucesión de frames, similares a las que yo hacía en las orillas de los cuadernos; pero en 3D era todo distinto e incomprensible. Varias veces hice animaciones pseudo3D, en realidad era solo cosa de perspectiva, pero en el 3D real, podía rotar por todo el espacio, ver cada imagen desde infinitos ángulos y nunca parecía una figura plana en perspectiva. Mi primer acercamiento a este tipo de aplicaciones fue un programa para diseñar ambientes de hogares. En mi rudimentario 286 de 10 Mhz (creo que con turbo subía a 20, era un notebook acer, cuya pantalla estaba mala y proyectaba sobre un monitor externo) tenía un software similar, permitía hacer planos de habitaciones, ingresando comandos en un consola, los que se graficaban en monocromático en una especie de plano. Del programa que hablo ahora (Win95), tenía funcionalidad parecida, salvo que todos los comandos eran del tipo Drag & Drop y finalmente uno podía convertir ese mundo en 3D y recorrerlo a su antojo. Recuerdo que el programa andaba lento y el PC se solía pegar siempre, pero estaba mostrando algo en 3D, lo que realmente me motivaba.

Los primeros juegos en 3D que usé, solían tener elaboradas iluminaciones y "materiales" interesantes en sus polígonos, pero pocos incorporaban texturas. Debido a esto, la sensación de realismo era bastante inferior a la lograda con los 2D y sus sprites elaborados e incluso fotorrealistas (fue increíble cuando en Mortal Kombat lograron meter personas reales al juego!!!), por lo que a pesar de la tridimensionalidad, parecían figuras plásticas y requería imaginación pensarlos como personajes.
Hubo un juego de carreras de autos que me emocionó. Era un demo de Rally, en 3D y con buena geometría. Cada auto estaba bien construído y se veían bastante naturales las curvas, respecto a lo poligonal que acostumbraba a ver. Pero lejos lo que más me sorprendió fue el uso masivo de texturas en los modelos. Comparados con juegos de ahora era realmente primitivo, pero el hecho de tener un mundo 3D, totalmente texturizado era sumamente atractivo, y lo más cercano a la realidad.

Mi pasión simpere han sido los aviones, por lo que un título infaltable en mi colección fue el MS Flight Simulator 98. Aprendí mucho de aviones con él (Creo que es el FSim con la mejor ayuda de la serie). Más de alguna vez estuve a punto de decidime por estudiar para ser piloto (aunque ahora estudio medicina) y creo que mucho influyó el simulador de Microsoft. En algún momento conseguí un editor de texturas para el Fsim, y pinté los aviones a mi gusto. Podría haber sido el primer paso en mi idea de diseñar mi propio simulador de vuelo.

El gran salto cualitativo ocurrió en esos tiempos, digamos año 1997. Un buen día llegó a mis manos un CD y un libro cuyo título prometía mucho: Aprenda Visual Basic, ¡Ya!. Con Juan estuvimos harto tiempo investigando el programa, siguiendo los ejemplos del libro y aprendiendo porfina a programar en Windows. Él sabía bastatne más que yo, pero a pesar de las farimañas y adornos, controles, eventos y cosas nuevas, el resto seguía intacto. En el corazón del lenguaje estaba el mismo Basic que yo había aprendido años atrás.
Ese libro se convirtió en mi biblia dirante mucho tiempo. Dejé de lado los módulos de clase y los enlaces con bases de datos de Access, centrándome sólo en la programación básica y en la parte gráfica, aunque a pesar de ser un lenguaje basado en Windows, las funciones gráficas del VB eran bastante limitadas.

El editor de VB que tenía en ese tiempo era una demo de la versión 4.0. Se llamaba modelo de evaluación, y sólo permitía crear un único formulario, y no posibilitaba crear archivos EXE. De todas formas, todo ese año y el que le siguió, permanecí programando en ese VB.

Con el tiempo aprendí varias cosas e hice algunos buenos programas para cosas del colegio. Cuando pasaba por genética, decidí hacer un simulador de evolución, que según el ambiente seleccionaba los fenotipos apropiados y eliminaba al resto. Funcionaba bastante bien, aunque la parte gráfica seguía muy deficiente. VB como tal solo ofrecía controles Picture e Image para cargar Bitmaps. Podía poner algunos controles de este tipo y moverlos por la pantalla, a la vez que reemplazaba cada imagen con una copia similar muy rapidamente, para lograr el efecto de animación.
Con esta técnica logré esbozar algunos "juegos", pero realmente estaba lejos de conocer una estructura correcta para elaborar un motor de juegos. En ese entonces, mis programas eran poco modulares y bien procedurales, con un nivel de abstracción muy bajo y difíciles de entender. Por otra parte, la gráfica siempre me complicaba, pues no conocía técnicas para lograr Color Key, razón por la cual, todos mis sprites estaban rodeados por un cuadrado de color. Para solucionarlo, pintaba este "fondo" del mismo color que el del fondo real sobre el que pondría el sprite. Así, el helicoptero siempre tenía un fondo color cielo, el cual no podría variar. El problema ocurria cuando se me cruzaban dos sprites, entonces se notaba claramente su naturaleza cuadrada.

Recuerdo una vez, por ahí en el año 2000 o 2001, cuando volví a programar después de bastante tiempo. Estuve enfermo y alejado del colegio casi una semana, por lo que debía hacer algo con mi tiempo libre. Recordé haber leído en una revista sobre un programa que generaba un mundo a partir de datos al azar. Tenía algoritmos para hacer árboles, casas.. Una cosa como un mundo procedural. Cuando estuve enfermo, decidí aplicar la idea para hacer un juego sobre avión que navegara por un mundo que se autogenerara azarozamente. Dado el eterno problema de los sprites cuadrados, decidí enfrentar el problema con lo que tenía: Shapes. Resulta que VB tiene un control Shape que permite crear cuadrados y óvalos y modificarles algunos parámetros. A pesar de su poca flexibilidad, no estaban inmersos en un cuadrado, por lo que me resultaban ideales para crear imágenes que se superpusieran sin interferirse fuera de sus límites reales.
El problema de la superposición se solucionó en parte. El asunto se volvió que un avión hecho de óvalos y cuadrados no sería visualmente muy elegante. Como solución decidí usar un Dirigible como personaje.
Recuerdo que todo funcionó parcialmente bien. Las nubes, árboles y demases se ubicaban en posiciones al azar, con colores aleatorios en paisajes autogenerados. No recuerdo si tuve suerte en volverlo un juego, ya que siempre me complicaron las colisiones y el scroll. Después de eso dejé VB por largo tiempo.

Creo que fue al final de mi último año de colegio (2003) cuando comencé a buscar ayuda en internet. Descubrí cientos de páginas con cursos de todo, todo gratis, todo bien explicado. Encontré por ahí una página que hablaba de juegos con VB. Comentaban que no era un lenguaje ideal para esos propósitos, pero que si de todas maneras se quería hacer algo, entonces BitBlt era indispensable.

Yo no tenía idea a qué se referían con BitBlt. Entre todas las funciones del Visual que conocía, niguna se le llegaba a parecer. Dado que convertí a internet en el maestro que busqué por años, lo utilicé para investigar más sobre esta función que parecía ser alabada por los verdaderos desarrolladores en VB. Recuerdo la primera descripción que leí: "BitBlt es probablemente la función más feliz de la API de Windows". Eso me mostró dos cosas: Estaba ante algo potente, y ese algo requería estudiarse para poderse entender.
Cuando aprendí a usar BitBlt, gané el poder para transferir bloques de bits (de ahí el nombre simpático: BitBlt = Bit Block Transfer) a cualquier device context (DC) de Windows. Cuando creaba controles en VB, automáticamente se creaba un nuevo DC, por lo que tenía el poder de poner imágenes donde nunca antes pude. Gracias a las varias ROPS (raster operations) que conocí, logre al final crear sprites a partir de dibujos de Paint, con un fondo transparente que dejaba ver lo que había más atrás. Desde ese momento dejé de usar controles Picture para mostrar imágenes. Bliteaba todo al DC del Form, con lo que logré componer escenas bastante atractivas. Entre tanta página que visitaba, terminé incluyéndome en un proyecto para crear un juego en comunidad, aportando ideas y código a través de un foro. Ahí aprendí a usar otros trucos de la API de Windows, pero además conocí y por fin entendí una API mucho más poderosa que venía intrigándome desde años atrás: DirectX.

DirectX7 simepre me costó bastante. Recuerdo que la referenciaba sólo para obtener la única función que manejaba bien: TickCount. En mis primeros juegos en BASIC, los intervalos de tiempo los calculaba mediante "For...Next", sumamente impredecible. Con VB hasta ese momento manejaba los tiempos con el Timer, el que lamentablemente perdía precisión manejando intervalos cortos. Una vez, estudiando el código de una animación del proyecto en que estaba trabajando (Se llamaba proyecto Alpha, programaba gente de todo el mundo) encontré que el manejo de los tiempos se realizaba mediante el TickCount, y que nadie usaba el Timer. Me di cuenta que el TickCount era sumamente preciso y confiable, y menos engorroso de implementar que un control Timer (Recuerdo mis formularios con 20 o 30 de estos controles, cada uno con su propio código autónomo interrumpiéndose mutuamente. Era un desastre, pero era lo único que tenía.) Cuando aprendí a usar el TickCount, mi primer programa fue un simulador de helicóptero. Ahora que tenía un control del tiempo con precisión de un milisegundo, no costaría demasiado crear una simulación semirrealista del vuelo idealizado de un helicoptero. todavía recordaba bastante bien varias fórmulas de cinemática y dinámica que servirían, por lo que un día desperté feliz y me dediqué a programar el motor de física.
Otra novedad importante en este juego fue la manera de estructurarlo. El haber colaborado en un proyecto mundial (aunque se canceló y ninguna línea de código fue mia) me permitió aprender a trabajar de modo modular. Con proyecto Alpha un tipo en USA creaba la física, otro en Europa el sonido, mientras yo estudiaba en Chile la manera de crear un Render decente para el proyecto. Con la estructura de mis programas era imposible que alguien colaborara conmigo. Cada función se mezclaba con otra en procedimientos enredadísimos, que a veces me impedían continuar cuando ni yo mismo me entendía. En cambio en proyecto Alpha todo iba en su módulo bien organizado. Cada programador debía sólo conocer la documentación de las funciones que realizaban los demás, sin entender su funcionamiento. A veces el tipo de Inteligencia Artificial le pedía al de física que creara una función de tal forma, a los pocos días el de física devolvía un ZIP en el foro con la función, el de AI la agregaba y trabajaba sobre ella sin involucrarse en su construcción. Este tipo de trabajo yo nunca lo había visto, y si bien, mi proyecto de Helicópteros era a nivel personal, también se beneficiaría del trabajo modular. Por primera vez cree subprocedimientos para cada acción, evitando esos listados interminables de código en una sola función. Si algo no gustaba, se cambiaba sin modificar al resto. Realmente fue un aporte el haber aprendido a trabajar así.

Lo del Helicóptero me tomó un par de días antes que me aburriera. La física funcionaba bien. leía perfecto las entradas del teclado y el Render, aunque sencillo, funcionaba perfectamente hasta entonces. Por primera vez incorporé la lógica de mi juego en un Loop, volviéndose muy similar a los motores de juegos "reales". Hasta entonces el programa corría bien como simulador, pero le bastaba bastante para ser jugable. Decidí mejorar los escenarios. Agregué edificios que hacían scrolling por la pantalla. Todos colisionables y wur permitían posarse en ellos (con el cuidado necesario para no destruir el helicoptero en el intento). Lo agradable era que todo estaba hecho en Paint, por lo que bastaba con modificar el bmp de origen para darle un look nuevo al juego, sin cambiar nada de código. Todo además era bastante paramétrico. Si quería agrandar un edificio, cambiaba sólo un número y el motor de juego se encargaba automáticamente de detectar las colisiones en otro nivel, etc. Cambié el Render varias veces sin tener que tocar una sola línea de código en el resto del programa. El problema apareció cuando la complejidad se hizo tal, que era incapaz de blitear un frame tras otro sin que se notara el corte.
BitBlt se estaba quedando corto para mis propósitos. Debía buscar una solución o mi juego se estancaría. Cuando estuve leyendo sobre DirectX, había aprendido bastante teoría, y sabía que los BackBuffers eran precisamente lo que necesitaba. El problema es que ni Visual, ni la API de Windows, ni nada que conociera soportaba backbuffers, excepto DirectX. Durante un buen tiempo traté de hacerle el quite a esta API. Me parecía poco práctico aprender de cero en la mitad de un proyecto. Además, no se veía fácil por lo que había investigado, por lo que decidí hacer un híbrido entre lo que sabía de VB, BitBlt y lo que pudiera aprender de DX7 en esos días. Recuerdo haber inicializado DirectDraw (La parte de dibujo de DirectX7) como había visto hacerlo a los tipos de proyecto Alpha. Luego creé unas cuantas Surfaces, y un set de BackBuffer y FrontBuffer. Hasta ahí con DirectX. Conservé la lógica de juego y la física original del juego en VB, y sólo pretendí modificar el Render. Como de cargar imágenes en surfaces no sabía mucho, decidí usar el BitBlt de Windows en vez del equivalente de DirectDraw. Al final nada resultó. BitBlt no era capaz de copiar en las surfaces de DirectDraw, a pesar de todos mis esfuerzos. Traté de crearles un DC compatible con funciones de la API, estuve mucho tiempo en eso y no funcionó. Me frustré y abandoné la idea de aprender DirectDraw. Terminaría mi juego como pudiera.
Hubo un momento en que comprendí que BitBlt había tenido su momento, pero que ahora necesitaba cosas mejores. No tenía sentido aferrarse a una función que me siguiera limitando. Después de todo, estaba haciendo todo eso por aprender. Hay un post por ahí en un foro (que todavía aparece si se busca en google) donde pido ayuda con mi problema con BitBlt y su poca velocidad. La respuesta fue categórica: "Aprende DirectX".

A partir de entonces, me dediqué a leer lo que encontrara de DirectX7 para aprenderlo cuanto antes, después de todo, por no saber Dx no había podido colaborar más con Proyect Alpha. en una de esas tantas búsquedas, encontré algo que me interesó aún más. Era un tutorial muy bien hecho donde enseñaban DirectX8. Ya no existía DirectDraw, desde Dx8 todo era 3D. Obviamente lo bajé y ese mismo día terminé de leerlo y hacer todos los ejemplos.

No ha pasado tanto tiempo desde que hice mi primer cubo coloreado que giraba y giraba infinitamente. La lógica de programar en 3D me fascinó, y abandoné el helicóptero. En vez de eso, hice un juego de Pong en 2D usando los Shapes de VB, con la salvedad que todo corría en un Loop que finalizaba en dos Render alternativos. El primero simplemente organizaba los shapes para que simularan la situación actual de la escena. El segundo hacía exactametne lo mismo, pero en un entorno 3D. La pelota era un cubo rojo que corría en una cancha azul, sólo delimitada por 4 líneas en el espacio. La cámara se podía mover libremente y hacía un efecto de "Super Switch", alternando repetitivametne entre la perspectiva del jugador y su oponente. Agregué un efecto Stealth, donde la pelota desaparecía en la mitad de la cancha, para luego aparecer sorpresivametne en los últimos segundos. Todo esto lo volvió un juego bastante interesante, del que compilé una demo que envié a un amigo para probar. Le intenté agregar soporte para juego en línea, pero nunca resultó, en parte porque no tenía dos PCs para ir probando. El juego se llamó Super Bong y aún lo conservo. Ha sido mi único juego en 3D, hasta ahora......

Terminó ese verano, y con él las posibilidades de seguir programando. Cuando volví a Santiago, tomé un curso de programación en la escuela de Ingeniería de mi universidad. Era el ramo terror de los ingenieros novatos, quienes debían aprobarlo en su primer año. Esto me hizo creer que ofrecía mucho y decidí tomarlo como electivo. Son 10 créditos de los que no me arrepiento, a pesar de las advertencias de mis amigos acerca de no tomarlo.
En ese curso aprendí bastante, de hecho, aprendí un lenguaje distinto y una filosofía totalmente nueva. Me enseñaron C# (C sharp), un lenguaje de Microsoft para su Framework.Net. Hace tiempo que venía leyendo sobre esta "cosa nueva" .Net; ya sabía de un Visual Basic.Net al que nunca me atreví a conocer más a fondo. Ahora, aprendiendo C#, conocí la filosofía .Net y la verdadera orientación a objetos. De principio me chocó un poco el cambiar toda mi forma de pensar un programa. Al comienzo intentaba aprender creando analogías con lo que ya sabía, pero al poco timepo comprendí que era necesario desprenderse del legado del BASIC y comenzar de cero con mentalidad nueva. El C# era un lenguaje basado en el C, esa cosa que tanto anduve buscando en mi niñez, potenciado para Windows y el FrameWork.Net. El hecho de vincular todo con internet me motivó bastante, puesto que había comenzado a esbozarse un proyecto de empresa de diseño Web con un amigo. Al final aprendí bastante en ese semestre y la orientación a objetos me gustó tanto que me costó imaginar cómo hubiese hecho las mismas cosas con Visual Basic años atrás. En mi proyecto final, junto a tres compañeros creamos un juego de futbol en tablero, cuya Clase de gráficos estuvo a mi cargo, y donde debí aprender bastante de aquello. Para lograr trabajar con algo más familiar, encapsulé las funciones graficas del C# en algo a lo que estaba más acostumbrado: Le agregué un BitBlt. En resumen, aprobé el curso y me quedé con el conocimiento de algo nuevo. No soy muy persistente, así que no seguí practicando. Al final dejé la programación un poco de lado para dedicarme a la música y la literatura, y obviamente a la medicina que se volvió muy demandante.

Después de todo esto, pasó un buen tiempo y ahora estoy en 4to año, con las esperanzas de ser un gran Doctor (Soy medio Médico, en la mitad de la carrera). Este semestre he tenido un poco más de timepo libre, lo que provocó que comenzara a retomar mis pasatiempos pasados. Me decidí a comenzar un nuevo proyecto en programación, para seguir con el aprendizaje y lograr plasmar en algo concreto todos los años de trabajo. Después de tanta presentación (y un poco de nostalgia mientras escribía) aquí comienza el texto sobre lo medular de este Blog: El proyecto Avioncitos 3D.