Eficiencia del Software contra Eficiencia de Desarrollo

–¿Cual es más importante?–

Hace meses escribí una serie de 10 entradas que no quise publicar y tal vez nunca publique sobre como la programación degeneró en los últimos 40 años. Y una de las razones por las que no quiero publicarla además de no rantear de a gratis es porque he visto lo que les hacen en internet a programadores que expresan ciertas ideas. Por lo que olvidé el tema hasta hace poco que en un video sobre como las computadoras parecen diseñadas para fallar me topé con el comentario de la foto. Denle click para agrandarla si quieren leerlo.

Todo lo que traté de explicar en ese escrito que me tomó dos meses el programador de este comentario lo resumió en tres palabras: Bottled Web Applications. O en español aplicaciones web embotelladas. Nunca había visto que alguien definiera tan bien el software de estos dias.

En el comentario también explica el cómo llegamos a esto y por qué una computadora parece volverse más lenta con el paso de los años. Y es lo mismo que he escrito en este lugar por años y años. Así que esta vez voy a presentar las cosas desde un punto de vista por completo diferente: El de los negocios.

Desde los inicios de la computación comercial han existido dos figuras rivales que trabajan juntas: El programador y el hombre de negocios. El primero quiere divertirse con las computadoras y el segundo hacer negocios rentables. Y no son capaces de sobrevivir uno sin el otro. Por eso muchos equipos han tenido por lo menos estas dos figuras. Wozniak y Jobs de Apple para dar un ejemplo. Este par se encarga de que sea posible vivir del software. Y ahí es donde el problema comienza. pues como ya he dicho, un programador puede crear software si tiene una computadora, tiempo disponible y sus necesidades básicas cubiertas. Por contraparte, manejar un negocio de software puede ser muy pero muy caro para alguien que no es programador. Pues tiene que pagar salarios a los programadores, el software siempre se tarda más de lo esperado, los buenos programadores son muy escasos y costosos y siempre algo puede salir mal y hacer que todo el trabajo se pierda. El desarrollo de software tiene demasiadas cosas impredecibles que traducidas a dinero son costos millonarios. Y esos costos se tienen que compensar de alguna manera. Y la búsqueda de una solución a este problema es lo que nos trajo las actuales Bottled Web Apps.

Para hacer software de la máxima calidad sin ser uno mismo programador hay que conseguir primero buenos programadores, ponerlos a vivir como monjes en un templo tecnológico que cubra todas sus necesidades humanas y digitales y esperar lo mejor. Y esas serian las condiciones ideales en las que los programadores fueran buenos, se llevaran bien unos con otros, trabajaran a toda su capacidad y entendieran a fondo la tecnología con la que trabajan. Y aún así podría haber retrasos causados por la reparación de bugs o cambios inesperado en las especificaciones. En esas condiciones si que sería posible calcular presupuestos y fechas de entrega con márgenes de riesgo aceptables.

Pero como sabemos la realidad es diferente: Los programadores buenos son difíciles de encontrar, pueden llegar a ser muy conflictivos o tener costumbres que no ayudan a la producción. No viven en monasterios apartados sino en oficinas ruidosas llenas de gente muy diversa (trollface) que los desconcentra. Además la tecnología puede fallar o no estar disponible y los requisitos del proyecto pueden cambiar de modo caprichoso. Así que hacer software de la máxima calidad no es rentable en la mayoría de los casos. Pero es posible producir software con una calidad que sea lo bastante aceptable para venderlo a un precio mayor que el que costó producirlo. ¿Y cómo lo lograron?

Como vivir del software sin saber programar

Desde que se descubrió que había personas dispuestas a pagar dinero real por secuencias inmateriales de números almacenados en un soporte de datos barato los señores del monóculo, el smoking y el sombrero de copa quisieron llevar la producción de esas cadenas de bits al mismo nivel en el que tenian a la producción industrial: Es decir tener instalaciones llenas de trabajadores intercambiables felices de ganar el mínimo y que hicieran tareas sencillas que cualquiera pudiera hacer mientras entonan canciones alegres.

Pero los malvadísimos programadores no estaban dispuestos a trabajar en esas condiciones y como eran muy pocos podian amenazar con irse sabiendo que nadie podría ocupar su lugar. Pero la mano de obra tan especializada no era el único problema al que los señores del dinero se enfrentaban. El otro problema era el propio software. Desarrollar software propio desde cero era arriesgado y muy tardado. Ellos querian comprar piezas ya hechas y ponerlas en una banda transportadora de un lado y que el software saliera del otro lado ya terminado. Ensamblado por una hilera interminable de monos amaestrados tal y como se hacía en las armadoras de automóviles. Pues era más barato pagar por el derecho de usar esos componentes de software a otra empresa y darle bananas a los monos amaestrados que pagarle a sus propios y poco cooperativos programadores.

¿Pero de donde salió el término «app»?

Aquí voy a meter una de mis historias que no se si ya la había contado: Una vez un viejo programador me explicó el origen de la palabra «app» o Application para referirse a los programas de computadora. Al parecer en la antiguedad había dos tipos de desarrolladores: Los que programaban sistemas complejos y avanzados capaces de controlar fábricas y negocios enteros eran conocidos como Programadores de Sistemas o System Programmers. Mientras que muy por debajo de ellos estaban los programadores principiantes que apenas si podian escribir programas pequeños que leian datos como texto y números que le pasaban al sistema grande. Esos eran los Programadores de Aplicaciones. Pues en ese entonces una «aplicación» era una hoja de papel en la que un cliente escribia sus datos y la entregaba a alguien más para obtener un producto o servicio. Y un software de aplicación o «app» hacía exactamente eso.

Y llegan las Bottled Web Apps

Ahora que sabemos el origen del término «app» volvamos a como se hizo más barato y rápido el desarrollo de software. Primero se consiguió rebajar el nivel necesario para entrar creando métodos que permitian intercambiar a la gente. O sea que ya no hacía falta aguantar el sano nivel de autoestima de los programadores de sistemas porque los de aplicaciones eran igual de efectivos y cobraban menos. Luego llegaron las soluciones embotelladas que resolvian los puntos más complicados del sistema y lo único que había que hacer para tener nuevo software era pagar por esas botellas llenas de soluciones mágicas y desorcharlas. Pero todavía faltaba algo: El software no era lo suficientemente bonito y los clientes, al no tener idea de programación juzgaban un software por lo bonito que se veía en sus pantallas. O díganme: ¿Cuantas veces han estado dispuestos a pagar más por un software que se ve igual al anterior pero que fue modificado para que corra de manera más rápida y confiable? La mayoría de los usuarios no se dan cuenta de las mejoras si no se las explican a la hora de correr el programa por primera vez.

Pero había otro problema: Los programadores que sabian de gráficas por computadora ya habian sido expulsados de la empresa. En especial los que sabian de 3D. ¿Cómo se atrevian a pedir un mejor trato nada más porque le entendian a esas privilegiadas e incomprensibles matemáticas? Y como el único que podía hacer cosas estéticas en pantalla era el típico diseñador gráfico que pintaba los letreros del supermercado por menos del mínimo se les ocurrió algo brillante: ¡Usar la tecnología pensada para hacer sitios web para desarrollar todo tipo de software!

Y así, de la noche a la mañana hubo una explosión de color y sonido. Una imagen JPEG cuya codificación desarrollaron grandes ingenieros de la informática y la óptica ahora se podía abrir con una breve linea de texto con el nombre del archivo. El llenado de información había pasado de una serie de llamadas para leer, escribir y codificar datos alfanuméricos en una simple descripción de una caja con una etiqueta. La interactividad y el diálogo entre la máquina y el usuario ya no requería de un ciclo que actualizara la pantalla varias veces por segundo y leyera las teclas. Y lo mejor de todo: Ya no había necesidad de conocer el hardware porque ya casi cualquier sistema contaba con un navegador web. Si acaso había que preocuparse por distinguir entre la peqeña pantalla de un smartphone y un monitor de pared de 42 pulgadas. Y esa información ya la daban los propios navegadores.

¿Y se logró algo? Pues al menos para los que hacen el software a punta de talonario si. Pues ahora basta con que tengan una idea loca y prometedora (disruptora le dicen) para que un millonario que no sabe nada de programación les de dinero. Luego buscan a un grupo de autodenominados geeks que conozcan la herramienta web de moda esa semana. Ya que los tiene los mete a una oficina alquilada que llena de figuritas para «verse geek» y en un tiempo no mayor a dos años ya tiene una flamante «Bottled Web App» que puede venderle a algún cliente grande, distribuirla por medio de una tienda de apps o «regalarla» para vivir de la publicidad y las microtransacciones. Si la app es un éxito el que pagó para que se la hicieran se hará millonario y si no lo logra podrá comenzar todo el proceso de nuevo con otro inversionista, otra tecnología que se ponga de moda y otro grupo de desarrolladores más jóvenes. Porque obvio hay que dar una imagen profesional y nadie quiere programadores treintones y cuarentones con experiencia en tecnología del año pasado pudiendo elegir entre una gran diversidad (trollface) de desarrolladores jóvenes y entusiastas que se tomen selfies que cobran como becarios.

Nada es gratis.

Si todo este maravilloso ecosistema emprendedor que permite a gente que no tocó una PC antes del Facebook enriquecerse haciendo juegos en los que exhiben sus más ocultos y retorcidos traumas sexuales es gracias a una cosa: El enorme poder de las computadoras de hoy. Para que se den una idea un procesador barato de este 2017 es capaz de ejecutar decenas de miles de millones de instrucciones en un segundo. Hasta algunos millones de millones de operaciones de alta precisión matemática en caso de una PC gamer con GPU o gaming rig como le dicen ahora. Puede predecir lo que el usuario va a hacer y aceptar 3 de cada cuatro veces y adelantarse a lo que va a pasar. También puede ejecutar instrucciones en desorden y presentar los resultados como si se hubieran leido una tras otra. Ahora pienten en cualquier programa en el que tengan que escribir texto o hacer click en alguna imagen. Casi siempre hay un retraso de casi un segundo entre que ustedes presionan la tecla y el programa reacciona mostrando la letra o el menú desplegable.¿En serio se necesita una decena de miles de millones de operaciones para reaccionar a la presión de un botón y dibujar una imagen de unos cuantos miles de pixeles? Pues si. Porque las instrucciones de una Bottled Web App no equivalen a instrucciones del CPU como se hace en ensamblador. Pasan por muchos procesos para poder ejecutarse. Así que el dinero que el empresario se ahorró al contratar a un inepto y la simple linea que ese inepto copypasteó de un tutorial en un minuto al final terminó pagándolo la computadora del usuafio final y por extensión su dueño al tener que comprar una computadora más avanzada para hacer lo mismo que su padre hacía a su edad con una PC con la tecnología de hace 20 años.

¿Pero lo vale? Al menos para quienes ponen el dinero si que lo vale. Por otro lado, hacer software que aprovechara el hardware a su máxima capacidad como se hacía en el pasado aunque teóricamente sería posible representaría un verdadero reto. Por eso muchos prefieren software razonablemente bueno para que la gente pague por él. O como dicen en inglés: «You can have it right, or you can have it right now» (puedes tenerlo bien hecho o puedes tenerlo ahora mismo)

Por eso pocos se arriesgan a hacerlo. Muchos incluso dirian que es imposible. Pero todas las cosas son imposibles hasta que alguien las consigue. Y cuando eso sucede son los que pagan por ese software los que más se benefician.

Las ventajas de usar archivos de texto como salida de programa

–O por qué la instrucción para mostrar cosas en pantalla se llama PRINT–

¿Alguna vez se han preguntado por qué el comando o instrucción de salida de información en la mayoría de los lenguajes de programación se llama «PRINT»? Por ahora si digo cosas como printf o print piensen en una ventana que muestra el resultado de un cálculo o algún mensaje del tipo Hola Mundo y los más viejos de ustedes tal vez piensen en palabras que aparecen en cascada en ventanas de editores de comandos. Pero la verdad es que la historia del PRINT es mucho más antigua que los monitores de las computadoras.

Hace décadas cuando las computadoras comenzaban no había una forma facil de obtener los resultados de sus operaciones. Primero dichos resultados se representaron como luces que encendian y apagaban y pulsos eléctricos que se perdian pero no fue sino hasta que las computadoras pudieron representar información legible para humanos que se volvieron verdaderamente útiles y la primera forma en que esta información pudo ser representada fue en forma de texto. Y esos textos salian por la boca de las impresoras. Las impresoras son en si mismas un tema fascinante en computación pues muchos de los protocolos de comunicación y representación de información fueron creados específicamente para ellas. De hecho alguna vez leí en un libro muy viejo sobre computadoras que si a uno le daban a elegir entre una impresora y un monitor lo mejor era elegir la impresora pues al tener la información representada en un medio físico como el papel sería mejor a la hora de compartirla con otras personas, agregarla a documentos o simplemente guardarla en un archivero en la oficina. Cosas que por supuesto no podríamos hacer con un monitor. Otra ventaja de la impresora en esa época era que los monitores antiguos tenian muy poca resolución y resultaba complicado leer en ellos y aún a la fecha existe gente que no es capaz de leer directamente en una pantalla de computadora.

Otra referencia a la importancia de los archivos de texto la tenemos en los antiguos programadores de UNIX que daban consejos tan útiles a inicios de la computación como ahora para quienes comienzan a programar y uno de esos consejos era que siempre la salida de los programas fuera en forma de archivo de texto pues estos archivos son muy fáciles de leer sin importar el tipo de tecnología que estemos manejando y hacer programas que trabajen con textos es cosa facil. De hecho, en mi experiencia como programador pasé bastantes años sin saber lo importante que era sacar información por medio de archivos de texto porque me confiaba de otros sistemas de salida de datos como la tradicional salida de mensajes por la pantalla y ya cuando programé en ensamblador llegué a usar archivos binarios puros que leia en editores hexadecimales cuya lectura muchas veces me resultaba más tardada que la programación en si misma. Pero mejor pasemos a ver todas las ventajas de los archivos de texto como salida de programa una por una.

1.- No dependes tanto del sistema

Cuando comencé a programar en ensamblador para Windows (Win32) la peor parte para mi era sacar información básica de lo que el programa estaba haciendo. Algo tan sencillo como mostrar el valor regresado por una función o mostrar el contenido de los registros de propósito general requería hacer toda una serie de tareas que iban desde llamar a una función que pedía todos los datos de ejecución del programa hasta la forma como debian de representarse en pantalla. Incluso la función menos elaborada que era TextOut requería un proceso equivalente a pedirle permiso al sistema para escribir, decirle exactamente donde debía de hacerlo y luego avisar que ya se había terminado de escribir. Y si uno quería que el formato fuera un poco más sencillo de leer tenía que llamar funciones de formato de texto una de las cuales tenía no menos de 30 parámetros. En ese entonces usé la humilde MessageBox para sacar datos a pantalla pero aún así tenía que hacer muchas cosas con la salida porque MessageBox solo mostraba valores en ASCII sin formato y para mostrar datos numéricos había que convertirlos primero. Y lo peor fue que cuando comencé a programar en modos de pantalla completa todo lo anterior no me sirvió para nada porque las funciones de salida de texto de Windows no trabajan igual en estos modos. Al final tuve que hacer sprites a mano de números y letras para poder mostrar información en programas fullscreen.

Otra cosa que intenté fue usar más el debugger para saber lo que pasaba en el programa pero no siempre pueden correrse programas en el debugger y menos si se trata de programas con interacción en tiempo real como los videojuegos. De haber sabido en aquella época que el contenido de todas esas variables que no podía ver lo podía guardar en un archivo y luego con otro programa convertirlo en un archivo de texto que podía revisar con calma en el mismo editor de código me hubiera ahorrado muchísimas horas de trabajo y tal vez ya tendría terminados varios juegos. Sin duda esa es una de las cosas que le diría a mi yo del pasado si algún dia pudiera regresar en el tiempo.

2.- Los datos escurridizos no se pierden

Si la salida del programa la quieres para buscar algún bug no hay nada como usar archivos de texto. Pues puedes guardar el contenido de las variables que sospechas que tienen el error en forma de table de modo que cuando el programa falle el archivo de texto te muestre la situación que tenian los datos antes de fallar y durante la falla y en caso de que la falla no crashee el sistema completo también puedes tener datos de lo que pasó después.

Pongamos por ejemplo de que un arma no funciona siempre, que a veces hace el daño al objetivo y otras pasa a través de él sin afectarlo. Si guardamos el contenido de las variables en cada ciclo del gameloop mientras disparamos contra los monstuos y luego sacamos esos datos en forma de tabla tal que cada renglón sea un ciclo del gameloop y cada columna una variable veremos qué es lo que pasa cuando la bala y el monstruo deberían de hacer contacto y descubrimos que a veces no hay contacto porque en cierto ciclo del gameloop la bala apareció detrás del monstruo cuando este avanzaba hacia nosotros. Un error bastante común. Si en lugar de archivos de texto hubieramos escrito en pantalla el contenido de la variable que indica el impacto no hubiéramos podido ver como las variables interactuaban entre ellas o el valor hubiera cambiado demasiado rápido para poder percibirlo con los ojos.

3.- Buscar datos es facil si usas el propio editor de código

En un programa real los datos no son constantes sino que cambian con el tiempo. Podemos hacer un archivo de texto gigante con varios miles de lecturas de esos datos con respecto al tiempo y si queremos encontrar algún dato en específico podemos usar la función de búsqueda de texto del editor de código. También podemos usar otras opciones del propio editor como buscar todos los momentos en los que una variable tuvo un cierto valor o encontrar mensajes de error del sistema.

4.- Puedes compartir la información con otros programadores

Tener un archivo de texto con la salida del programa ayuda a encontrar errores o a entender el funcionamiento interno cuando uno no programó el sistema original

5.- Los datos pueden examinarse por otros medios

Muchos programas tienen que recibir ajustes antes de liberarse. Por ejemplo un juego puede necesitar balanceo de las armas y los items para evitar que algún objeto demasiado poderoso o muy debil vuelva el juego injugable e injusto. Muchas veces eso se hace introduciendo los datos del juego en una hoja de cálculo y viendo como reaccionan los datos a los cambios. Y si tenemos un texto con esa información hacer esto es tan sencillo como copiar y pegar

6.- Documentar se reduce a un simple copy-paste

Esto no necesita presentación. Si queremos guardar datos sobre el funcionamiento del código o explicarlo en una presentación basta con hacer copy-paste o incluso escribir en el propio documento creado por el programa y entregarlo.

7.- Podemos darle formato a los datos para hacerlos más sencillos de leer.

Si bien un editor hexadecimal sirve para leer cadenas ASCII y datos en formato de 8 bits la cosa se complica cuando tenemos datos de 32 bits en little endian, estructuras de datos compuestas por diferentes tipos y longitudes de bits o valores en punto flotante. Y aunque el editor pueda representar los datos en diferentes formatos no siempre podrá hacerlo distinguiendo de uno por uno. Si quisiéramos ver el contenido de una estructura compleja primero tendríamos que encontrar en qué parte del archivo hex comienza y convertir los datos a mano. Pero si usamos un archivo de texto podemos hacer un programa independiente para que haga todo eso por nosotros. Así podríamos captar el contenido de todos los datos de un vistazo sin necesidad de traducir nada. Un ejemplo de esto son los valores de punto flotante que podrian reescribirse tanto en notación exponencial de base dos como en formato base 10 con su punto decimal o detectar cuando aparezca un valor como un Infinito o un NaN. Por ejemplo es más sencillo reconocer el valor Uno positivo en punto flotante si leemos «1.0» en lugar de 3F800000.

8.- Hacer un programa que cree estos archivos es sencillo.

Otro de los mandamientos de los antiguos sabios del UNIX era que es mejor hacer muchos programas pequeños que hicieran una única cosa sencilla y bien hecha a un programa gigante que hiciera muchas cosas complicadas y con dudosa calidad. Y esto también aplica a la salida por archivos de texto.

En un proyecto cualquiera puede programarse una rutina que saque los valores de salida en forma de un archivo binario puro y esta rutina puede eliminarse en la versión final. Luego aparte podemos hacer un programita que tome como entrada ese archivo binario y produzca un archivo de texto que es el que vamos a usar. Hacer este programita sería cosa sencilla y lo único dificil sería programar las rutinas de conversión de datos binarios a cadenas ASCII y esas mismas rutinas podrian servirnos para otros proyectos. De hecho podríamos hacer uno de estos programas para cada proyecto importante que tengamos y lo único que cambiaríamos sería la parte donde se indica donde están los datos y qué hacer con ellos. Tampoco tendría ningún tipo de interacción y ejecutarlo se reduciría a presionar un botón o hacer un archivo de proceso por lotes que lo ejecutara luego de correr el programa principal. Y esto es posible porque los archivos de texto en realidad no tienen formato como tal. Cada byte es un símbolo ASCII y algunos de esos símbolos indican cosas como Nueva Linea, Tabulador o espacio en blanco. Por lo que producir una salida de texto se reduce a poner los datos en formato ASCII, combinar con otras cadenas de texto ASCII para darle forma y luego la cadena final que no sería otra cosa que un array de bytes guardarla como un archivo con extensión TXT y todo esto es tan rápido que ni nos enteraríamos de que tal programa está ahí. Al final bastará con cargar el archivo creado en un editor de texto cualquiera. Aunque editores capaces de recargar los mismos archivos al presionar un botón son los mejores para mantener la información actualizada.

Saben, escribiendo esta nota recordé que no importa cuantas cosas se hagan hoy con las computadoras. No importa si se usan para negocios, juegos o hacer vida social. Lo único que hacen y siempre han hecho es procesar datos en forma numérica y darnos información en un formato que podamos entender. Todo lo demás que creamos que hace la computadora en realidad es trabajo hecho por seres humanos. Por eso no debemos perder nunca de vista que la información es poder y que aquellas cosas de las que carecemos de información nunca las tendremos bajo nuestro poder. Por eso siempre tengan información actualizada de todos sus proyectos y que mejor que hacerlo recurriendo a los humildes y amistosos archivos de texto.

¿Por qué los mexicanos somos tan malos para programar videojuegos?

–El Eslabón Perdido de 8 bits–

Aunque ustedes no lo crean en México ha habido muchos esfuerzos para desarrollar videojuegos durante los últimos 20 años. Incluso en cierto momento del 2010 muchas fuerzas se pusieron en marcha para echar a andar lo que pudo haber sido la EA de latinoamérica. Hubo un publisher que invirtió mucho dinero para sacar adelante proyectos en colaboración con empresas internacionales tan importantes como Konami, SquareEnix o la mismísima Nintendo. Había tratos para distribuir los juegos en muchas partes del mundo y una enorme campaña publicitaria. ¿Pero qué pasó al final? Supongo que el que ustedes que me leen no hubieran sabido de la existencia de esta elite del desarrollo de videojuegos de México lo dice todo.

Ya en serio, se lo que pasó y puedo decirlo porque yo lo vi muy de cerca y en tiempo real. La gente que contrataron no tenía idea de como se programaba un videojuego y no pudieron terminar a tiempo algo decente. El resultado obviamente fue malo y no se vendió. Y si, ya se que si me han leido desde aquellos años creen que saben lo que voy a decir, pero esta vez tengo una nueva teoría de por que en México somos tan malos para programar videojuegos y esto lo veo porque aunque ya hay grupos independientes que nada tienen que ver con aquel fracaso multimillonario si que el problema de no poder programar un juego con rendimiento de hardware decente o cuyo costo de producción sea mínimamente redituable se repite una y otra vez.

Antes de entrar al tema voy a trollear un poquito. Verán, en ese entonces yo creía que la culpa de la ineptitud de los mexicanos para programar videojuegos tenía razones culturales o académicas más que históricas, pues veía que en ese período en el que nació lo que aquí se llama «La H.Industria» todos parecían provenir de o buscar emplear a gente del mismo origen. Pero luego me tocó ver grupos que no tenían nada que ver con esa demografía que intentaban hacer juegos y fallaban por su ineptitud en la programación y cuando lograban sacar algo jugable el nivel de ventas no era suficientemente alto para recuperar lo invertido.

Pero bien. ¿Por que los mexicanos somos tan ineptos para programar videojuegos? Mi nueva teoría es que en el pais no se vivió una época que si se vivió en paises como Estados Unidos, Japón, Inglaterra e incluso España. En esa época fue cuando se crearon muchas de las grandes empresas de videojuegos que todavía existen o afamados creadores de videojuegos aprendieron a programar. Una era en la que las computadoras no servian para tantas cosas como ahora y que cualquiera que poseyera alguna sin importar su edad, clase social o nivel de estudios podía usarla para aprender a programar, crear videojuegos y hacerse famoso. Esa era fue la de las microcomputadoras de 8 bits.

Las microcomputadoras de 8 bits eran poco más que juguetes. Por la décima parte del valor de una computadora de verdad uno podía comprarse uno de estos aparatos similares a un teclado de computadora gordo que podía conectar al televisor de casa cual si se tratase de una consola de videojuegos. Y al igual que estas sus capacidades eran bastante reducidas: Procesadores de 8 bits a 3 o 5 megaHertz (una milésima de velocidad de una PC barata del 2016), memoria RAM de 64 kilobytes o menos en la que no cabría ni el ícono de escritorio de un juego actual y almacenamiento secundario que en caso de existir se hacía en cintas de cassette iguales a las usadas para la música y que podian tomar varios minutos en leerse. Estos sistemas aunque baratos eran incompatibles entre si de modo que un programa o juego para una consola podia no funcionar en otra y si se ‘porteaba’ el resultado era por completo distinto cuando no deprimente. En el continente americano las máquinas de 8 bits dominantes eran marca Commodore basados en el chip 6502 que era el mismo del NES, en Europa las Amstrad y ZX Spectrum basadas en el Z80 y en Asia la MSX o otros sistemas también encontrados en las regiones anteriores.

Pero lo mejor de los sistemas de 8 bits era toda la comunidad que se había creado alrededor de ellos: Programadores entusiastas que se reunian a comparar y compartir software creado por ellos mismos, revistas que publicaban artículos sobre como programar estos sistemas y hasta números con códigos completos que cualquiera que entendiera su funcionamiento podía teclear en su casa, o incluso aunque no lo entendiera podía hacerlo funcionar mientras no cambiara ni una sola letra.

Ese período histórico como ya dije fue clave en paises donde ahora si que existe una verdadera industria de videojuegos. Pero ahora veamos lo que pasó en México y que aunque algo tuvo que ver el problema que había con la importación de computadoras, en el caso de sistemas de 8 bits esto no fue tan malo, pero si que pasaron otras cosas bastante raras.

El Ataque de los Niños Gigantes

Para empezar, mientras que en paises como los ya mencionados estos sistemas se popularizaron tanto que vender juegos grabados en cintas de cassette era buen negocio en México los sistemas de 8 bits no se vendieron tanto. Pero no porque fueran sistemas muy caros sino porque había un extraño estigma alredor de las microcomputadoras que hasta hoy no se si fue un error en las campañas publicitarias o habría razones genéticas hasta ahora no descubiertas. Y es que es hasta esta época con el Youtube y los podcast que me enteré que en otros paises quienes usaban estas computadoras eran programadores y aficionados a los videojuegos o «gamers». En México no recuerdo haber visto que a los gamers les interesaran estos sistemas tanto como las arcades o consolas como el NES o las todavía funcionales Atari 2600. Los usuarios mexicanos de las computadoras de 8 bits eran en su inmensa mayoría una extraña especie a la que en ese entonces clasifiqué como «Niños Gigantes». Pues se trataba de sujetos casi en su mayoría hombres que a pesar de ser mucho más altos que el promedio de la población sus cuerpos eran blandos y redondeados como los de los niños, casi carentes de barba, aunque a algunos ejemplares les crecian barbas pobladas al comenzar a trabajar para distinguirse de los otros machos de la manada. Y sin barba, su edad resultaba casi imposible de determinar sin buscar indicios en su ropa que revelaran su pertenencia a alguna empresa o escuela. En público era casi imposible encontrarlos a más de un metro de distancia de sus madres que casi siempre eran mujeres de vestir conservador y trato confiado con desconocidos y quién decidía todo por ellos como que juegos debería de comprar de acuerdo a su contenido. Mi trato con los niños gigantes era contradictorio, pues si bien siendo ya un geek en potencia y teniendo tema para hablar con ellos me daba miedo terminar convertido en uno o por lo menos si lograba llevarme bien con ellos hacía todo lo posible por llevar esa convivencia lejos de las miradas condenatorias de los normies.

En internet la única referencia remota que he encontrado sobre la relación entre los Niños Gigantes y las computadoras de 8 bits son comentarios sobre que los usuarios de esos sistemas no eran tan competitivos ni afectos a los juegos de acción rápida como los jugadores de arcades o consolas. En cambio preferian juegos más «meditativos» y pausados que resultarian incomprensibles para los jugadores de hoy. Tal vez lo más parecido sería una combinación de aspacto de Visual Novel con el gameplay de un juego de estrategia por turnos y muchos comandos de texto o menus desplegables. Es más, una vez escuché a uno de estos Niños Gigantes que trabajaba en el departamento de computación de una escuela secundaria referirse a las consolas como «Un desperdicio de tiempo y de dinero» y que era mucho mejor inversión una Commodore Amiga. Y si bien ese modelo específico de computadora (que no era ya de 8 bits) era muy bueno y tenía muchos juegos no era nada facil de conseguir en las tiendas y sus juegos en mi ciudad eran por completo inexistentes.

Ensamblador V.S. BASIC

Pero volvamos con el tema de la programación. Algo interesante de las computadoras de 8 bits es que se podian usar para programar pero los únicos dos lenguajes de programación funcionales eran Ensamblador y BASIC. Creo que no tengo que decirle al publico habitual que los verdaderos programas se hacian en ensamblador y el BASIC era meramente una cosa para los muy pero muy principiantes. Y algo que si noté es que nunca vi a un Niño Gigante programar una Commodore o un ZX Spectrum en ensamblador. Al menos no en México. Mi teoría es que la presencia de esa extraña y blanda especie en la escena de las computadoras de 8 bits tenía algo que ver con que la publicidad con que las ofrecian las presentaban como herramientas para el aprendizaje y no como computadoras o consolas de videojuego programables. Recuerdo especialmente un anuncio de la XE de Atari que la presentaban como una herramienta de aprendizaje para que la compraran los padres y como una consola de videojuegos para que atrajera a los niños normales. Otra razón por la que dudo que hubiera muchos niños gigantes programando en ensamblador es que programar en él requiere de mucho tiempo y esfuerzo y una de las características de los padres que criaban a dichos ejemplares tenian la férrea política de no permitirles estar con una computadora o consola de juegos por más de una o dos horas al dia.

Pero el daño ya estaba hecho. Mientras que en otros paises había cientos de programadores que habian hecho juegos en ensamblador para que otros miles de gamers los jugaran en sus sistemas de 8 bits en México los pocos programadores de ensamblador de 8 bits que pudieran haber existido nunca pudieron comercializar sus juegos porque los pocos que tenian una de estas máquinas eran en su mayoría los mullidos Niños Gigantes y lo más seguro es que sus madres nunca les hubieran permitido jugar videojuegos no educativos con la excusa de que eran «violentos». Personalmente yo no recuerdo haber visto una computadora de 8 bits mas que una vez en una tienda, pero casi siempre se comentaba que «el amigo de un amigo o el primo de un amigo» tenia una. Cuando el tiempo pasó hubo un pequeño movimiento de programadores para computadoras en los noventa pero la mayoría de las computadoras de 16 y 32 bits eran tan caras que no era negocio producir y vender juegos para PC en el pais. Lo peor fue cuando aparecieron las redes sociales y las computadoras pasaron a ser un accesorio más de la casa o de moda en el caso de los smartphones en lugar de algo exclusivo de programadores, gamers y geeks. Ahora vamos con más de mi teoría.

La era de las leyendas quedó atrás…

Una de las cosas que más he defendido es que los programadores tienen sus propias leyes para juzgarse entre ellos y que lo único que hace la diferencia entre un programador y otro son sus códigos. Los programadores comienzan desde niños o adolescentes a programar mientras curiosean con las máquinas. Aprenden por si mismos y prueban su código una y otra vez hasta que logran que la PC haga lo que ellos quieren. Yo mismo puedo decir que mi espíritu de programador disminuyó mucho en la era del internet «normie» y cada vez me cuesta más trabajo ver las nuevas computadoras como veia mi viejo Pentium 100mHz que programaba en ensamblador para Windows 95 luego de que el BASIC, C y C++ en ese orden me fueron quedando pequeños. Me hubiera gustado programar una Commodore o un Spectrum en ensamblador y enviar mi juego a algún pais en donde estos sistemas si que estaban en manos de gamers. Ahora si me pongo nostálgico tal vez pueda programar algo para emulador y que lo jueguen unos pocos aficionados a la retroinformática.

¿Y cual fue el efecto de que en México no hubiéramos tenido una era de desarrollo de videojuegos en 8 bits? Pues que nunca tuvimos programadores de videojuegos que valoraran la eficiencia. Se dice por ejemplo que en España el negocio de los videojuegos decayó cuando se popularizaron las computadoras de 16 bits porque no había tantas y los juegos eran mucho más fáciles de copiar gracias a los discos flexibles. Regresando a México vagamente recuerdo que cuando a las computadoras de 8 bits les quedaba poco alguien intentó hacer un concurso de programación pero no supe en qué acabó. Y en cuanto a la programación de videojuegos «profesional» esta comenzó a dar señales de vida en una época en la que el estandar era una PC de 32 bits con Windows, tecnología de aceleración gráfica y almacenamiento óptico. O sea nada que ver con sistemas de 8 bits con 64k de RAM y menos de un megabyte de almacenamiento magnético. No estuve ahí pero cuenta la leyenda de que los primeros intentos costaron demasiado y las ventas no fueron suficientes. Situación que sigue repitiendose al dia de hoy.

Todo esto puede explicar el por qué la actitud prejuiciosa y narcisista de la H.Industria al negar la posibilidad de que existieran programadores de videojuegos fuera de su selecto círculo. Y si bien tenian algo de razón porque al no haber una era de desarrollo local de 8 bits no hubo programadores también olvidaron que dentro de su propio círculo tampoco iban a encontrarlos. Lo más cercano que pudieron encontrar debió ser alguna variación (no digo descendientes porque dudo que pudieran reproducirse de manera natural) de los Niños Gigantes de los ochenta cuya experiencia personal se limitaba al BASIC y una cosita despreciable de C++ desde Visual Studio con la que copypasteaban los ejemplos del SDK de DirectX y en lo profesional a hacer cosas de bases de datos. Es por esto que la inmensa mayoría de los mexicanos que actualmente quieren programar videojuegos tienen tantos problemas: Porque no vivieron la época en la que había que programar el hardware al máximo y si son muy jóvenes nunca tuvieron a un maestro que si hubiera vivido en esa época porque en este pais esa época nunca existió.

¿Y como podríamos recrear la época en la que las grandes leyendas de la programación de videojuegos aprendieron sus habilides? La cosa sería muy dificil porque el mundo de hoy es otro. Sería como enseñarle a sobrevivir en la naturaleza a alguien que nunca ha salido de la ciudad y que cree que las fieras de la selva son como los animalitos de las películas de Disney. Un niño o joven que hoy quiera aprender a programar videojuegos se vería abrumado con todo tipo de herramientas como los engines, editores multimedia y 3D muchos de los cuales podría descargar a su computadora desde el primer dia. Pero oh sorpresa vería que no sabe usar ninguno y que tiene que pagar una fortuna en libros, cursos y certificaciones para aprender a usarlos y luego de algunos años y muchísimo dinero invertido se daría cuenta de que él solo no va a poder hacer un juego exitoso porque no cuenta con los 500 millones de dólares para desarrollar algo como el siguiente GTA ni nadie le dará la décima parte de eso para hacer su jueguito indie injugable y se retirará a manejar bases de datos si es que lo suyo era la programación o a ser ayudante de publicista si quería hacer juegos pero se asustó al ver que programar requería saber matemáticas.

De momento de lo único que estoy seguro es que si alguna vez aparece una verdadera empresa de videojuegos en el pais no va a ser gracias a inversionistas ni «gente importante» sino al esfuerzo de grupos pequeños que desarrollarán sus proyectos desde cero, con sus propios recursos y el tiempo libre que les quede luego de un pesado dia de trabajo o escuela. Gente que no esperó a que alguien abriera una universidad de programación de videojuegos para tomar un libro de programación e implementar los algoritmos explicados en él. Que tampoco va a esperar a que alguien le pague un salario para hacer juegos ni mucho menos se quejará de que es poco si tiene la inmensa fortuna de encontrar a un incauto dispuesto a pagarle. Pues en otros paises grandes leyendas de los videojuegos comenzaron de la nada y México no tiene por que ser la excepción. Y recordando algo que dijo uno muy relacionado con el género FPS: «Para hacer videojuegos lo único que necesitas es una PC, mucha dedicación y una buena provisión de comida congelada». Aunque por supuesto estas palabras fueron dichas a mediados de los noventa cuando no había redes sociales, video en streaming ni apps de mensajería que distrajeran a los programadores de su monástica labor. Por desgracia esa era de dificultades donde se forjaron los mejores no regresará a menos que ocurra alguna clase de equivalente informático de un apocalipsis zombie. ¿O será acaso que quien lo logre ya vive actualmente en su propio mundo apocalíptico encerrado, sin dinero ni tiempo libre y si muchísimos problemas para hacer juegos? ¿Estará leyendo esto ahora mismo? Eso sólo el tiempo lo dirá.

¿Necesitan ayuda para ese examen, proyecto o tarea de ensamblador de final de semestre y no sabes nada?

–¡Pues hay un maestro que puede ayudarles!–

La oferta es simple. Si ustedes viven en o cerca de Monterrey, México les propongo reunirnos para revisar esos proyectos y exámenes extraordinarios que para estas fechas ya deben de estar preparando. Las materias en las que puedo ayudarlos son las de lenguaje ensamblador, programación con Winapi, algoritmos y estructuras de datos y otras relacionadas con el gamedev. Lo que ofrezco es darles una capacitación presencial intensiva sobre estas materias. Si ustedes no tienen ningún impedimento mental serio les prometo que un curso express de una semana será suficiente para aprobar una de estas materias en extraordinario por lo menos en la materia de ensamblador. En cuanto a los proyectos si es que tienen alguno podemos hacer en ese mismo tiempo algo mínimamente aceptable para aprobar sus materias.

Pero dejemos primero dos cosas claras: La primera es que no les voy a hacer la tarea. Las tareas y los proyectos los van a hacer ustedes porque luego de que termine con ustedes serán capaces de hacerla. A lo mucho los voy a guiar paso por paso si es que mis explicaciones no fueron lo suficientemente claras.

La segunda es que no lo estoy haciendo por dinero. No les voy a cobrar un centavo ni los voy a obligar a hacer nada. Si quieren la ayuda y pasan que bueno y si no les gustó pueden irse en cualquier momento y considerar esto una simple reunión de amigos de internet.

¿Y qué ganó yo? Pues que hago esto porque necesito hacer una pequeña demostración pública. Probar que puedo tomar a un grupo de estudiantes promedio interesados en hacer videojuegos pero con poca o ninguna experiencia y capacitarlos de manera rápida y eficiente en una materia tan oscura como lo es la programación en ensamblador. Y qué mejor que hacer esto en una situación límite como lo es al final de semestre para probarlo.
Había considerado ofrecer este trato hace meses pero nada como esperar hasta el último momento para ser tomado más en serio. O tal vez este ofrecimiento sea demasiado temprano si es que tienen pensado volver a cursar la materia el próximo semestre.

A partir de aquí no hay vuelta atrás. El trato está frente a ustedes. Tomen la píldora azul si no les interesa. Despertarán mañana y será lo que quieran creer. Pasarán la materia si es que no tienen problemas o tal vez reprueben y consideren cambiarse a una carrera que no tenga tanta programación. O bien pueden tomar la píldora roja y ver hasta donde llega la madriguera del conejo. Se como se sienten. Lo se porque yo estuve en su lugar. Con mi ayuda podrán leer esas páginas llenas de códigos de ensamblador que ahora ven como superficies de símbolos sin significado y podrán manejar esas herramientas que no tienen idea de como funcionan.

¿Y como pueden contactarme? Muy simple. Al final de esta entrada voy a dejar un link a mi página de ASK. Ahí podrán hacer preguntas de forma anónima y sin registro sobre como, cuando y donde hacer las reuniones. Aunque la foto de avatar de ASK conteste casi todas estas preguntas. Por cierto. Algunos de ustedes reconocerán el lugar donde fue tomada esa foto y tal vez hasta cursen ahí la única carrera que lleva ensamblador. Pero la invitación está abierta a cualquiera que pueda estar físicamente en la ciudad. Y ahora la invitación está frente a ustedes.

Pregunten más información en este ASK. No necesitan registrarse

El Blog de Ensamblador entra en Modo de Hibernación

–Despiértenme cuando contraten a los programadores para programar–

Pues había escrito una nota de mas de 6000 characters pero después de quitarle los insultos gratuitos, los gritos, las amenazas, las cuestiones de política, autoconmisearción y cualquier cosa que se pareciera mas a un grito de dolor que a un grito de guerra decidí dejar esta pequenísima nota solo para anunciar que durante este 2013 voy a escribir muy poco en el blog de ensamblador. Voy a estar arreglando un asunto que tengo pendiente desde hace años pero que apenas se me presentó la oportunidad para llevarlo a cabo. Solo puedo decirles que se trata de algo relacionado con la programación. Así que solo subiré algunas pocas notas para principiantes y contestaré cosas que me pregunten directamente en los comentarios y tal vez ayude a unos pocos renegados del internet que intentan levantar proyectos pequeños y sin dinero. Fuera de eso no voy a poder hacer nada mas, ni hacer declaraciones públicas, ni escribir artículos de opinión ni participar en cualquiera de las interesantes actividades que mis monos alados me dicen que van a ocurrir en latinoamérica los siguientes dos años. Lo mas que puedo decirles sin que crean que estoy consumiendo cosas raras es que voy a estar programando, programando y programando y tal vez luego de mucho programar salga algo que a nadie le importará quién lo hizo mientras sea bueno. Si es que sale.

Este no es el fin sino solo una partida guardada que habrá de retomarse mas adelante. No crean que me retiro de la programación pues voy a estar al pendiente de todo lo que ocurra en los círculos que para bien o para mal ya me conocen. Los monitorearé desde mi escondite lleno de cucarachas que sobreviven a desastres nucleares y tal vez los trollee de vez en cuando en twitter. Regresaré a la vida pública cuando busquen a los programadores por su habilidad para programar (o mejor aun por sus códigos ya hechos) y si creen que este pobre diablo puede ayudarles con algún problema pueden intentar encontrarme. Para el resto, les aconsejo que también se pongan a programar antes de que sea yo quien los encuentre a ustedes. Sin mas entro en Modo de Hibernación.

Mario Salazar, Marzo 10, 2013

Como Equipar tu Centro de Operaciones parte 1

–Configuración Básica: La Trinchera–

Iba a contar una de mis viejas anécdotas pero mejor se las ahorro. Esta entrada va a ser extensa y detallada y puede que necesite mas de una entrada para cubrir el tema. En fin, de lo que les voy a hablar ahora es sobre como construir un centro de operaciones funcional para programadores independientes y demás aspirantes a científicos locos que no tengan recursos para montar grandes instalaciones.

Lo primero que hay que dejar en claro son las condiciones de trabajo. Como me imagino que ustedes son vagos cuyo único espacio disponible es el dormitorio de la casa de sus familiares (no me importa si es de sus padres o sus parejas en turno) o en el mejor de los casos un cuarto alquilado en algún lugar del que no quieran dar muchos detalles. En cuanto a servicios básicos por lo menos tendrá energía electrica y un baño lo suficientemente cercano para poder llegar caminando. Contar con acceso a internet es util pero no del todo indispensable. Y en cuanto a clima basta con tener acceso por lo menos a una ventana y en temperaturas extremas al menos un pequeño abanico (mínimo 10″ de diámetro) para enfriar las computadoras y sacar el aire respirado.

En cuanto a las dimensiones el local debe de medir por lo menos 2 metros por lado o lo suficiente para que las personas que van a trabajar ahí puedan acostarse en el suelo y estirar brazos y piernas sin sentirse incómodos. Como deduzco que la mayoría de ustedes son Forever Alone y si no lo son no se sentirán incómodos con la regla anterior pasemos al siguiente punto.

La altura.- El lugar de trabajo debe de tener un techo lo suficientemente alto para que no puedan alcanzarlo con las manos estando de pie. La altura ideal es lo bastante alto como para alcanzarlo con una miniescalera plegable de dos escalones. Ese espacio alto es muy valioso y casi siempre se desaprovecha. Ahora pasemos a las paredes.

Las paredes.- Deben de contar con contactos eléctricos polarizados y aterrizados (de 3 patas como les dicen en México) para que puedan conectar cualquier aparato eléctrico moderno. Las tomas de corriente deben de ser las suficientes y estar lo bastante cerca unas de otras como para no tener que usar extensiones que atraviesen el suelo y estorben. Las paredes deben de ser lo bastante fuertes para poder perforarse y sostener algunas estructuras pequeñas y por supuesto deben de contar con al menos una puerta para tener acceso y una ventana que permita el paso del aire y la luz natural.

Estas son las condiciones mínimas para permitirle trabajar al menos a una persona. Si cuentan con un lugar mas grande pueden aprovecharlo todo o usar solo una parte pero es importante que ese espacio lo usen solo como su centro de operaciones y nada mas. Ahora pasemos con el mobiliario básico.

Antes de entrar al mobiliario básico es importante dejar bien clara una cosa: En su centro de operaciones deben de ser capaces de trabajar de pie, sentados y acostados y en situaciones muy desesperadas también debe de ser posible dormir por una o dos noches. El estar de pie les permitirá moverse por las instalaciones y usarlas de manera eficiente y casi no ocuparán espacio. Cuando tengan que estar quietos por espacios entre 30 minutos y 3 horas pueden usar una silla con respaldo como cuando ven un video o usan algún tipo de interfaz manual pequeña como un pad de juegos o una tablet. Y si van a hacer alguna actividad que tome mas de 3 horas seguidas como por ejemplo leer, descansar o incluso dormir lo mejor es acostarse. Por lo que necesitarán 3 tipos de sillas y una mesa pequeña. Para hacer esto un poco mas manejable voy a motrar varios niveles en los que puede ser equipado un centro de operaciones (que voy a abreviar como HQ de Head Quarter para ahorrar espacio). Cada nivel incluye todo el equipo de los niveles mas bajos.

HQ nivel básico: Trinchera

Para los que no juegan suficientes FPS de guerra, una trinchera era un pozo mas o menos grande donde los soldados de la Primera Guerra Mundial podían protegerse de las balas y defenderse de cualquiera que intentara acercárse por tierra. El centro de operaciones modelo trinchera es el mas básico para poder trabajar y cuenta con el equipo mínimo suficiente para leer, investigar y hacer proyectos pequeños. Tiene todo que un estudiante de nivel universidad que no requiera herramientas exóticas puede necesitar durante su carrera. El único inconveniente de la trinchera es que es necesario contar con una computadora tipo laptop o tablet. Si cuentan con un equipo tipo Desktop van a necesitar por lo menos el modelo Bunker. Lo mejor de la trinchera es que al igual que las trincheras de verdad que pueden ser excavadas con rapidez y estar listas para la batalla en cualquier lugar y momento este modelo puede armarse y desarmarse en cualquier lugar que cuente con los requisitos básicos como el rincón de una recámara, un cuarto abandonado o una oficina improvisada. Ahora vamos con el equipo.

Equipo de la Trinchera

Piso de espuma.- Existen mosaicos de un material elástico parecido al plástico que son lo bastante suaves para sentarse o acostarse y a la vez lo bastante firmes y resistentes para caminar o pararse sobre ellos. Cubren un área muy buena y son mas baratos que una silla. Son buenos para hacer trabajos acostado o sentado y pueden plegarse para limpiar el suelo. Pueden conseguirlos en tiendas de artículos para casas, tiendas de deportes o si son padres de familia en tiendas de artículos para niños.

Garrafón de Agua.- Existe un proverbio español que no recuerdo palabra por palabra pero que dice que si no dispones de lo necesario para recuperar y desalojar los l\iquidos de tu cuerpo no puedes trabajar ni descansar. Un garrafón de agua a la mano es vital para mantener un mínimo de salud.

Pizarrón pequeño.- Esta es una de las herramientas mas básicas de un desarrollador después de las computadoras. Programar no es solo estar sentado oprimiendo teclas. Hay que pararse para revisar algoritmos, planear estructuras de datos, hacer grafos o ver como se vería un personaje que se nos acaba de ocurrir. Un pizarrón de 60 por 90 centímetros que puede ser de gis (tiza) de cal o para uso de plumones con borrado en seco es suficiente. Pueden encontrar buenos pizarrones en tiendas de artículos escolares especializados y de oficina. Si no encuentran un pizarrón pueden construir uno usando placas de policarbonato, acrílico o vidrio. Los marcadores para borrado en seco trabajan bien en este tipo de materiales. Si solo encuentran estas placas en color transparente pinten el lado opuesto (el que queda hacia la pared) de blanco y usen el lado libre de pintura para escribir. Si van a instalar el pizarrón en la pared pónganlo a una altura en la que lo puedan usar estando de pie. Así será mas facil trabajar.

Banco de dibujante.- En un centro de operaciones es necesario estar de pie la mayor parte del tiempo para no perder movilidad. Un banco alto y acojinado como los usados en dibujo les permitirá estar en una posición tal que conservarán la capacidad de movimiento de estar de pie pero descansarán casi tan bien como al estar sentados. Pueden conseguir buenos bancos en tiendas de suministros para dibujantes o incluso en equipos para restaurantes y bares. Solo asegúrense de que al usarlos sus brazos les quedan a la misma altura que si estuvieran de pie y que el cojín les permita estar sentados sin causarles daños a la salud.

Mesa para laptop.- Estas mesas son sorpendentemente útiles incluso si no cuentan con una computadora tipo laptop. Si la tienen pueden usarla como indican las instrucciones y si no de todos modos sirven para acomodar todo tipo de equipo como teclados grandes, tabletas gráficas, joysticks, gamepads y si son lo bastante marranos hasta pueden comer en ellas. Su altura e inclinación ajustables las hacen perfectas para trabajar de pie o sentado (incluso en el piso) y las ruedas les permiten moverlas o guardarlas cuando no las estan usando sin necesidad de quitarles el equipo. Pueden conseguir este tipo de mesas en lugares donde vendan mobiliario de oficina. Incluso existe una mesa muy parecida usada en los hospitales. Aunque es un poco mas grande es demasiado cara. Pero si les ofrecen una a buen precio no duden en aceptarla.

Tambo de 20 litros.- Los tambos usados para distribuir pintura y productos químicos para construcción son también muy útiles en la oficina de un desarrollador sin recursos. Ocupan poco espacio, son muy resistentes, pueden sentarse en ellos cual si fuesen bancos o pararse para alcanzar cosas altas y su interior está lo bastante bien protegido como para guardar respaldos en discos ópticos o cables de computadoras durante años. Otro uso que pueden tener es el de soportar el garrafón de agua para que tenga una mejor altura y no dejarlo directo en el piso. Estos tambos junto con sus tapas los pueden conseguir en las ferreterías y las tiendas de artículos de construcción o si son vagos como yo de seguro encontrarán uno en cualquier depósito de basura o construcción descuidada. Si lo compran asegúrense que no se rompa cuando se paren sobre él. Sobre todo tengan cuidado con las tapas porque algunos de los botes que venden como «multiusos» no son tan fuertes como los usados para envasar pintura.

Regulador de voltaje.- Si tienen un mínimo de aprecio por cualquier aparato electrónico deben siempre de conectarlo a un regulador de voltaje de buena calidad. En México y muy probablemente en el resto de latinoamérica la corriente eléctrica tiene variaciones de mas menos 10% en condiciones normales. Esto es lo bastante fuerte como para quemar el sistema eléctrico de un abanico fabricado en Estados Unidos y no les digo lo que puede hacerle a una computadora. No se crean ese mito que los adaptadores AC de las laptops protegen contra variaciones de voltaje porque es mentira. Yo llevo 5 años con la misma laptop y 12 años con el mismo abanico y ambos siguen funcionando tan bien como cuando los compré. Algunos consejos para elegir un buen regulador son buscar uno que tenga una capacidad mínima de 1000 volts-ampere (no confundir con Watts), que cuente con supresión de picos (surge supressor) y que tenga por lo menos 6 contactos polarizados y aterrizados lo bastante separados entre si para conectar muchos dispositivos con su respectivo adaptador AC. Y no se confundan, por alguna razón hay regiones en latinoamérica en las que los vendedores son incapaces de distinguir entre un verdadero sistema de supresión de picos y un insignificante multicontacto que no cuente con la mas mínima protección electrónica aparte del aislante del cable de corriente. Los reguladores pueden parecer caros pero al menos pueden estar seguros de que sus equipos van a trabajar con un m\inimo de fiabilidad y que esta ser\a seguramente el equipo electr\onico que mas tiempo le tomar\a quedar obsoleto. Algunos de mis reguladores tienen mas de 15 a\nos y siguen en funciones.

La Caja del Caos.- Este es el último de los accesorios para equipar el centro de operaciones modelo Trinchera. La Caja del Caos puede ser una simple caja de cartón grande aunque lo mejor es que sea una de esas cajas transparentes de plástico y con tapa que usan las amas de casa para guardar ropa y sábanas. La regla para usar esta caja es simple. Cualquier cosa que no estén usando en ese momento va directo a la Caja del Caos. Así como cualquier cosa fuera de lugar o que no tenga una buena razón para estar donde está. Por ejemplo cables, memorias extraibles, papeles, accesorios y casi cualquier cosa que puedan sujetar con una sola mano. En caso de cosas frágiles como adaptadores de corriente o gamepads análogos guárdenlos en cajas mas pequeñas antes de lanzarlos a la Caja del Caos. Esto les permitirá mantener su centro de operaciones limpio y ordenado a la vez que sabrán donde buscar cualquier cosa que se les pierda. Otra ventaja que tiene este sistema es que da una idea de que tan bien administramos la instalación. Si la caja se desborda o no puede cerrarse es señal de que tienen que darle mantenimiento y organizar mejor sus cosas.

Consideraciones Finales

Voy a dejar los modelos de centro de operaciones Bunker y Fortaleza para otras notas porque voy a necesitar demasiado espacio para describirlos. Pero antes de que prejuzguen. Estos 3 modelos existen porque responden a necesidades diferentes. La Trinchera es suficiente para trabajar un dia entero e incluso pasar una noche. Tiene todo lo necesario para investigar, escribir programas pequeños y hacer diseños en tabletas gráficas de gama media y si pueden captar una señal WiFi desde donde están comunicarse con quienes quieran. Pero la ventaja que este modelo tiene sobre los otros es su bajo costo y rapidez de instalación. De hecho yo actualmente estoy limpiando mi centro de operaciones y tuve que replegarme en un rincón a modo de Trinchera y es desde ahí que escribo estas lineas. Otro consejo es que si van a comer en una trinchera tengan siempre a la mano una bolsa desechable para tirar los residuos y una bandeja para mover los platos y vasos sucios y asignen una hora para sacar todas esas cosas y si pueden lávenlas. Los trastos sucios pueden dejar inoperante un centro de operaciones así como la ropa sucia y los cables tirados en el suelo. En las siguientes entradas vamos a ver como armar el bunker y la fortaleza y recuerden que todos tienen un uso y propósito. Ninguno de ello es elección mala.

¿Qué es un Buffer de Datos?

–Cuando no tienes tiempo de esperar al mensajero–

Un buffer es una memoria en la que se almacenan datos de manera temporal para ser procesados. Se utiliza cuando los datos de entrada llegan a una mayor velocidad de la que podemos procesarlos o cuando llegan de manera tan irregular y esporádica que no resulta conveniente dedicar tiempo y recursos a esperarlos. Algunos ejemplos de buffers son los sistemas de entrada del teclado que almacenan las teclas presionadas, los buffers de video en los que se prepara el siguiente cuadro de animación para presentarlo en pantalla y otros tantos mas que como usuarios no creo que sean muy conscientes de lo que son o que hacen. Otra definición de buffer es la de una región de memoria que se usa como área de intercambio asíncrono entre procesos.

Como se han de imaginar, los buffers no nacieron junto con las computadoras sino que son una abstracción del mundo humano para explicar un concepto. De hecho una traducción un tanto oscura de la palabra Buffer es «Colchón» y se relaciona con los antiguos sistemas de reparto y entregas. Desde la época de los vaqueros y los inicios de la aviación los encargados de los sistemas de reparto y entregas descubrieron que podían ahorrarse mucho tiempo si en lugar de hacer que los mensajeros se detuvieran para entregar la mercancía colocaban uno de esos grandes colchones donde podían dejar caer los paquetes sin detenerse. De ese modo no era necesario dejar a alguien en la puerta esperando al mensajero y los empleados podían ir con toda calma y a una hora predeterminada a revisar estos buffers para ver si había llegado algún paquete. Un sistema muy parecido se utilizó en algunas fábricas y bodegas de muchos pisos en los que dejaban caer los productos por una especie de pozo vertical en cuyo fondo había un cojín y una pequeña puerta por la que se podían entregar los productos. En la actualidad las máquinas expendedoras automáticas usan buffers en los que dejan caer tanto el cambio en monedas como la mercancía de modo que el cliente no tenga que poner la mano y esperar a que estos caigan. Otro ejemplo mas sencillo es el viejo buzón de correos en el que el cartero puede dejar documentos y los habitantes pueden ir a revisarlos al regresar a su casa.

Los buffers son muy importantes y nos pueden ayudar a resolver una enorme cantidad de problemas que me llevaría toda la nota explicarles. Existen muchos tipos diferentes de buffers, hay algunos que funcionan como stacks y que sirven para recorrer estructuras de datos como grafos y árboles, otras trabajan como colas de procesamiento y nos dejan leer datos antes de que se pierdan, otros buffers mezclan datos de muchas fuentes y los combinan e incluso los buffers se relacionan con la recursión. Para hacer un buffer lo mínimo que necesitamos son 4 cosas. La primera obviamente es un espacio en memoria que vamos a usar como buffer. La segunda es un puntero o variable que almacene la dirección de memoria donde se encuenta, la tercera es un valor que indique la longitud máxima del buffer y la última es un índice o conjunto de índices que nos indiquen en qué localidad del buffer escribir los datos de entrada y leer los datos de salida. La combinación de la longitud máxima y los índices nos dirán si el buffer está lleno o vacio. Y aunque la administración de esta información suena muy complicada ya verán que existen muchas técnicas para manejarlos de manera eficiente por lo menos en ensamblador.

Problemas de los buffers:
Underflow y Overflow

Para los que no han leido las entradas mas elementales, el overflow es cuando hay demasiados datos en el buffer y los nuevos datos que llegan al no poder ser almacenados se pierden. El Underflow es lo contrario, cuando queremos obtener datos y el buffer está vacío. El Underflow es mas peligroso de lo que suena en ciertas aplicaciones como por ejemplo la grabación de datos en medios físicos como los discos. Si ocurre un buffer underflow la pieza puede quedar arruinada o en el caso de audio y video en tiempo real la comunicación puede presentar cortes. Es por eso que cada que se va a tener acceso al buffer ya sea para leer o escribir datos en él es necesario verificar que no van a ocurrir ninguna de estas dos condiciones. Pues si no se hace esta prueba no solo puede haber pérdidas de datos entrantes o cortes en el flujo de información sino que en casos de buffers muy mal diseñados puede haber problemas de sobreescritura que acaben por afectar otros datos importantes del programa y en casos muy dramáticos causar un fallo de protección de memoria o una caida completa del sistema. Les aconsejo que si consideran que el buffer puede ser peligroso lo coloquen en una región de la memoria alejado de los datos mas críticos.

Por suerte existe una técnica que nos puede evitar al mismo tiempo el problema del overflow, underflow y la sobreescritura. Esta técnica involucra máscaras de bit. El primer consejo es hacer que los buffers siempre tengan una longitud igual a una potencia de 2. Pueden ser 2,4,8,16,32,64,… Para el ejemplo vamos a tomar un buffer de 8 elementos. A partir de su dirección inicial, las siguientes 8 localidades se pueden numerar como 0,1,2,3,4,5,6 y 7 y los índices tanto de lectura como de escritura nunca deben de ser mayores que 7 ni menores que cero. Lo que cualquier programador que no sabe de ASM haría (y los que manejan leguajitos de ‘objetos y métodos’ ni siquiera harían esto) sería comprobar que ambos índices estuvieran dentro de ese rango antes de acceder al buffer y mandar un mensaje de error si esto no se cumple. Pues bien, como nosotros programamos en ensamblador nos basta con comprobar el estado de los bits que estén por encima de los 3 menos significativos. O lo que es lo mismo hacer una máscara AND con 0FCh (para índices de 8 bits). Si el resultado de esta operación es diferente de cero significa que los apuntadores están fuera del rango de cero a 8. Recuerden que los valores negativos tienen el bit mas significativo activado. De este modo si queremos detectar esta condición y encender una bandera que indique que hay un error basta hacer un AND seguido de un SETNZ. Si quisiéramos forzar a que los índices siempre se mantengan dentro del rango de 0 a 7 podemos hacerles un AND con un 3. Esto es especialmente importante para los buffers en forma de cola o los interesantísimos buffers circulares.

Voy a dejar el tema de los buffers circulares y de los buffers que funcionan como stacks y queues para otro dia porque son temas muy complicados para solo mencionarlos. De momento solo mencionaré que los buffers de Stack tienen un mismo índice que se usa tanto para leer como para escribir datos y que se incrementa o decrementa dependiendo de la operación que se haga. En los buffers de queue en los que los primeros datos en salir son los que mas tiempo llevan dentro del sistema el asunto es manejar dos índices uno para cada operación. Cuando ambos índices son iguales significa que el buffer está vacio y cuando la distancia entre ellos es igual a la longitud máxima del buffer este ya está lleno.

Para hacer buffers queue es necesario entender lo que es un buffer circular. Un buffer circular puede aceptar una cantidad infinita de datos pero solo puede recordar tantos datos como lo indique su longitud máxima. Los datos mas viejos se pierden por sobreescritura. Para hacer un buffer circular primero se define una extensión de memoria cuya longitud sea una potencia de dos y luego el puntero de entrada se mantiene dentro de ese rango por la fuerza por medio de máscaras AND. De ese modo no importa cuantas veces lo incrementemos ni durante cuanto tiempo el índice permanecerá dando vueltas en esa extensión de memoria sin salirse. Este tipo de buffers son muy importantes en la programación de videojuegos y en la animación de objetos articulados. Un Queue en realidad es un buffer circular que tiene un segundo puntero que va ‘persiguiendo’ al puntero de entrada de datos. Y es importante que un buffer queue sea en esencia un buffer circular porque he visto a muchos estudiantes que crean buffers capaces de caminar a todo lo largo de la memoria del sistema y aplastar por sobreescritura el resto de las variables cual si se tratara de las orugas de un tanque. Si el buffer queue se hace de manera circular se va a mantener en su lugar sin peligro de sobreescribir otras estructuras. Y esto es porque en los buffers queue los índices siempre se incrementan.

Por hoy no me voy a poner a trollear. Solo voy a comentar que voy a estar al pendiente de un juego que me dijeron que iba a salir publicado en este último cuarto del 2012. Espero que quienes lo están haciendo puedan terminarlo y recuperen su inversión, porque si siguen como hasta ahorra puede que a esta empresa le llegué su «Ultimo dia en La Industria». Trollface.

Informe asm86[008]

–Sagas épicas y señales de caminos–

Desde hace tiempo he estado revisando que tanto se leen las diferentes entradas del blog de ASM y comparando números he encontrado información interesante como que la entrada que mas se lee es la de «¿Cuantos bits tiene un byte?» y que es una de las mas sencillas e intrascendentes. Al principio pensaba que esta entrada era leida principalmente por niños o estudiantes muy principiantes de alguna escuela relacionada con computadoras. Luego entre las mas leidas están una serie de entradas donde se explican conceptos muy generales de la programación como lo que es un stack, organizacion de memoria y la forma de codificar la información. A partir de ahí la serie de programación gráfica tiene mas o menos las mismas lecturas que las notas en las que suelto al troll. Una buena parte de los que llegan lo hacen buscando imágenes y no solo de mis horrorosos dibujos en paint sino de una que otra imagen ‘safe for work’ que he tomado a modo de fair use de un famoso sitio de otakus donde por cierto esas imágenes tan safe no son precisamente las mas buscadas. En cuanto a las entradas menos leidas están algunas que son demasiado recientes como para ser comparables con las otras o cuyo nombre no describe realmente lo que contienen. En fin, luego de revisar todos esos datos descubrí como puedo hacer que este blog sea mas usable para los lectores: Trabajar mas en las Sagas.

En la mitología del norte de europa se le llama saga a un conjunto de relatos seriados sobre las hazañas de sus dioses y héroes. En épocas recientes este mismo término se ha usado para describir historias largas divididas en varias entregas dentro de un mismo comic o animación. Si algunos de ustedes son otakus sabrán de lo que hablo si digo que el anime de Saint Seiya se divide en sagas como la del Santuario, Poseidon, Hades y otras que de momento no recuerdo el nombre exacto. En cada una de ellas se cuenta una subhistoria de aventuras diferente pero que pertenece al mismo universo.

En el no menos épico mundo de la programación en ensamblador también hay historias largas y emocionantes que merecen ser contadas por capítulos a lo largo de mucho tiempo y por supuesto hay que hacer que los lectores puedan comenzar estas historias en el momento que quieran y no se pierdan buscando lo que quieren. Ya desde hace mucho he recibido comentarios de que no es facil encontrar tal o cual entrada o que parece ser que la gente no ve que hay entradas que llevan cierta secuencia. Es por eso que estoy pensando crear una especie de sistema de caminos para que los lectores puedan orientarse. Al final de cada entrada que sea parte de una saga van a encontrarse un apartado con la imagen de la señal de caminos que se muestra en esta entrada. Junto a ella encontrarán primero que nada el enlace a la entrada que le sigue. Un poco mas abajo la entrada anterior y si es necesario un enlace a la página donde sale la propia saga. Este proceso va a ser completamente manual y probablemente no se actualice durante meses. Pero no quise usar un sistema automatizado de entradas relacionadas porque no siempre guardan la secuencia que uno quiere y en peores casos relacionan temas que no tienen nada que ver.

Ahora que lo pienso el hecho de que este sitio tenga estructura de blog sirvió en su tiempo para publicar artículos de manera desordenada sin que se notara demasiado que se trataba de trabajos icompletos. Y este como ya han visto es un problema muy viejo a la hora de escribir aquí. De hecho, no dudaría de que algunas de estas sagas, si no es que todas van a quedar inconclusas o incluso pausadas durante meses o años. Creo que lo mejor es que me ponga a buscar una imagen que represente eso de manera macabra y graciosa.

Pues es todo por hoy, lo mejor es que me ponga a crear ese sistema de carreteras y sobre todo que lo haga de manera eficiente para no quedar con caminos sin terminar. Esta vez no hay troll porque parece que al fin alguien está haciendo un juego mas o menos decente en México, solo espero que estos no me defrauden el dia en que los conozca personalmente. Y no, esta vez no me ofrecieron nada.

¡Los Esqueletos Siempre Sonrien! (Parte 1)

–Demasiado optimismo puede matar a un programador–

Imaginen que caen en las garras de un monstruo que los destruye de manera lenta y sumamente dolorosa a lo largo de meses o años pero que les hace creer que todo va a estar bien. Que si tienen el valor para atacarlo les hace creer que si lo siguen golpeando con esa arma tan debil van a poder algún dia vencerlo y que si tratan de salir corriendo va por ustedes y les nubla la razón para que no lo hagan. Un monstruo que no pretende asustarlos ni mucho menos hacerlos huir. Solo algo que recuerda al sufrimiento de cuerpo y mente sugiere que algo está muy mal. Al final, sus cuerpos mueren mientras sus mentes permanecen atrapadas en un hermoso sueño del que no despertarán a menos que alguien los regrese a la realidad de un golpe y les muestre la horrible y verdadera cara del monstruo del que están siendo víctimas. Y esta nota es como ese golpe que anula ese diabólico hechizo. De inicio no les va a gustar pero ya me lo agradecerán después.

No sabría como llamar a este enemigo abstracto, aunque ya en la mitología de la India existían espíritus malignos capaces de anular la capacidad de percepción del ser humano esto tiene mas que ver con aquello que algunos llaman esperanza. De hecho en el mito de Pandora se decía que grandes horrores habían salido de su caja y que tan solo quedó dentro la esperanza cuando por fin lograron cerrarla. Este monstruo abstracto al que trato de imaginarme como un Esqueleto Sonriente se aprovecha de la idea de que la gente considera que la esperanza es algo bueno y les tapa los ojos de la razón a sus víctimas mientras devora sus almas. Y cada que te escucha quejarte se te acerca al oido y te llena de optimismo con frases como «échale ganas», «tu puedes» o «sigue intentándolo». Ahora veamos un poco mas sobre este esqueleto sonriente.

El Esqueleto Sonriente es el gemelo maligno de la Esperanza. Sus principales víctimas son los apostadores a quienes les hace perder grandes cantidades de dinero haciéndoles creer que en la siguiente tirada de dados van a ganar pero también suele susurarles a los enfermos que sus síntomas en realidad no son tan graves como para ir al médico o engaña a algunos enamorados diciéndoles que la persona que los ha rechazado toda la vida en realidad si los quiere. Y como este escrito es sobre programación, me voy a concentrar en como el Esqueleto Sonriente ha destruido las carreras de muchos programadores. En especial las de muchos desarrolladores de videojuegos.

Demasiado optimismo puede matar a un programador. De momento voy a mencionar el caso del creador de un juego conocido como Kingdoms of Amalur quien terminó en la ruina por su excesivo optimismo. En cierto momento tuvo un capital millonario, un gran equipo de desarrolladores a los que les daba todo tipo de prestaciones exóticas y todo lo necesario para terminar y llevar su juego al mercado. El tenía grandes esperanzas de que este juego fuera un gran éxito. Y si bien pudo terminar y sacar a la venta un juego que sin ser el mejor si que era mucho mas que bueno sus costos se elevaron tanto que ni vendiendo varios millones de copias pudo escapar de la quiebra.

El caso Amalur se repite mucho en todos los niveles. Desde empresas con presupuestos millonarios como la que acabamos de ver hasta modestos desarrolladores independientes que quieren hacer juegos en la computadora de su recámara. De hecho, me atrevería a decir que los programadores tienen que vérselas con el Esqueleto Sonriente desde que se les ocurre su primera idea para un juego hasta que reciben el pago final por sus servicios. Es mas, no me extrañaría descubrir un día que el CEO de alguna empresa de videojuegos sea el mismísimo Esqueleto Sonriente. Y si no me creen solo piensen por un momento lo siguiente: Muchos geeks relacionados con la programación tienen como máxima aspiración convertirse en desarrolladores de videojuegos profesionales y vivir de hacer juegos. Tienen la idea de que se trata de un trabajo muy divertido solo porque se la pasaron muy bien en sus épocas de gamers. No tienen idea de lo que en realidad es hacer juegos.

Lo mas siniestro es que en realidad nadie se beneficia del fenómeno del Esqueleto Sonriente. A primera vista podría parecer que un productor puede sacar ventaja al sobreexplotar a los desarrolladores para obtener mas horas de trabajo por un mismo salario pero a la larga termina con costos demasiado elevados y acaba con serios problemas de liquidez. Y al igual que el apostador compulsivo, todos pierden su dinero, su tiempo y en casos extremos hasta sus vidas o por lo menos buena parte de ellas tratando de sacar a flote proyectos imposibles de terminar. En el caso de proyectos personales el problema no va mas allá de dejar las cosas en el olvido (díganmelo a mi) pero cuando hay dinero de por medio, siempre hay alguien que tiene que pagar.

Conoce los límites de tu poder

Antes de discutir como hacerle frente al Esqueleto Sonriente veamos a uno de estos en acción: Digamos que ustedes van a un evento de geeks como por ejemplo una convención de comics. Ven que uno de los conferencistas en un «profesional» de la industria de los videojuegos. Durante la conferencia este les dice no solo lo maravilloso que es hacer videojuegos y las enormes fortunas que se mueven todos los dias. Tras varios minutos de hablar mucho y no decir nada finalmente llega a la sección donde comenta como pueden los pobres principiantes iniciarse a hacer videojuegos. Aquí es donde entran las bien conocidas herramientas de aficionado que pueden encontrar si buscan en google como hacer videojuegos sin saber programar y en el mejor de los casos da los nombres de algunas herramientas de diseño de licencia libre. Por cierto, siempre me he preguntado porqué en estas pláticas nunca dan detalles sobre herramientas libres que tienen aplicación mas seria en desarrollo de videojuegos como los compiladores GCC por ejemplo.

Ahora vamos a saltarnos lo ocurrido entre que salen de una de estas conferencias llenos de ganas de hacer videojuegos y vámonos hasta el momento en el que ya comenzaron a hacer uno pero no pueden terminarlo. Comienzan a notar que casi no duermen, que han descuidado sus estudios o trabajos honestos o si fueron lo bastante estúpidos y jugaron con dinero de verdad a que no van a poder cumplir con las fechas de entrega. Pero todo está bien porque están haciendo el trabajo de sus sueños y la envidia del troll de internet que dice que sabe de Ensamblador se los recuerda cada que se meten a leer su blog. En eso yo me apiado de su miseria y les doy un golpe para despertarlos del hechizo del Esqueleto Sonriente y lo que ven no les gusta nada:

He escuchado mucho de algunos el término «Reality Check», y a la mayoría de los que les he escuchado este término tuvieron que cambiar de empleo en menos de un año. Esto es parecido a eso que llaman Reality Check pero con la diferencia de que a cada quién le toca una realidad diferente dependiendo de sus muy particulares circunstancias. La primera cosa que uno debe de hacer tras escapar del hechizo del Esqueleto Sonriente es estar muy pero muy consciente del límite de sus propias capacidades. Y esto no es para que se sientan poca cosa sino para que no intenten hacer algo que nunca van a poder terminar. Si por ejemplo yo les dijera que soy capaz de hacer en una semana un programa para una plataforma que desconozco por completo seguro fallaré. Pero si el excesivo optimismo del Esqueleto Sonriente aparece diré que si puedo hacerlo y fallaré intentándolo. Esto no es nada sencillo. Pero la única manera objetiva de medir nuestras capacidades es probándonos a nosotros mismos. Antes de lanzarse a dibujar ustedes solos todos los cuadros de animación de los 20 personajes de su nuevo juego de peleas o a programar las inteligencias artificiales únicas que le han de dar una personalidad propia a cada uno de esos 20 peleadores mídanse ustedes primero. Vean cuanto tardan en dibujar un solo cuadro de animación digno de mostrarse en el juego o si pueden hacer que por lo menos el peleador controlado por el CPU es capaz de caminar hasta donde está el jugador. Mas que ser realistas o moderados con lo que se proponen, lo que les pido es que sean objetivos. Pues es muy sencillo confiarse y lanzarse a hacer cosas que están por completo fuera de nuestras capacidades.

No me voy a ir sin antes darles el golpe que les devolverá la visión de la realidad. Y tras dárselo la primera cosa que ven es que están tirados en el suelo, sin dinero, sin comida, sin energía y lo que es peor sin un juego terminado. Primero me reclaman del porqué destruí su lindo sueño y yo procedo a detener sus golpes y girarles la cabeza para que queden cara a cara con el temible Esqueleto Sonriente.

En la siguiente entrada vamos a ver que hacer cuando uno recién acaba de salir del hechizo del Esqueleto Sonriente. Las etapas por las que uno pasa son enojo, desengaño, miedo, desesperanza y finalmente resignación, aunque la resignación puede no ser el último paso si siguen los consejos que voy a darles. De momento lo que les recomiendo es que si ustedes son programadores aficionados y creen que están viviendo «su sueño» primero borren esas sonrisas idiotas de sus caras, pues tanto optimismo no va a hacer que un mal código funcione, pues no olviden que aunque ya estén muertos los esqueletos siempre sonrien.

¡No Puedes Escapar de la Programación!

–Cuando haces videojuegos todo tiene que ver con programar–

Como saben quienes han leido estos escritos desde hace tiempo, un tema del que escribo mucho es sobre programación de videojuegos, de hecho me interesé en el ensamblador porque en aquellos años era el lenguaje en el que se programaban los mejores juegos. Esta forma de pensar me llevó un día a la idea de abrir otro blog relacionado con el tema que mas se toca aquí (incluso mas que el ASM) y me refiero al desarrollo de videojuegos. Pero cuando escribía las posibles entradas me di cuenta de una cosa: ¡De que todo se relacionaba con la programación!.

Esta sentencia no es del todo mia. Es parte de una entrevista que escuché hace mucho por radio analógica. En un programa sobre computadoras entrevistaban a uno de los egresados de una de las en ese entonces muy contadas escuelas de videojuegos y el invitado dijo que no importaba a que área del desarrollo de videojuegos uno se dedicara, siempre se relacionaba con la programación de una forma u otra. Y esto lo confirmé cuando intentaba escribir una entrada de como se crean los sprites y vi que la mayor parte del texto hablaba sobre estructuras de datos, alineación de memoria y transferencias eficientes de secuencias numéricas. Es decir que nada que ver con lo que la gente que yo conozco que se dedica a dibujar para videojuegos hace. Ahora veamos las principales áreas del desarrollo de videojuegos que aunque lo intenten no pueden huir de la programación:

Los Artistas Gráficos no pueden escapar

Suponiendo que ustedes sean artistas gráficos porque en verdad les gusta dibujar y no porque programar les daba miedo de seguro tienen un estudio propio con una mesa de dibujo, lámpara flexible, una colección de tintas y lápices siempre disponible y si tienen dinero puede que hasta una tableta gráfica. Las paredes de su lugar de trabajo sostienen aquellas obras que los hacen sentir orgullosos y que les levantan la autoestima cuando el último cliente al que le hicieron los dibujos de esa campaña publicitaria no les pagó lo que querían. En fin, el asunto es que cuando intentan meter su arte en un videojuego este no se ve tan bien como lo hacía en los dibujos de las paredes. Ni siquiera se ve tan bien como se veía en la pantalla de la computadora en la que diseñaron. En lugar de eso los personajes parecen planos y sin detalle. No se aprecian los gestos faciales ni las expresiones en los juegos para móviles, los trazos se ven toscos e irregulares y las fotos digitalizadas de los personajes parecen recortes de revista. El artista se siente mal, pero nada de esto sucede porque sea un mal dibujante, sino porque no sabe como funciona el sistema gráfico de una computadora.

Algunos de estos errores comunes son por ejemplo no calcular bien la resolución en la que va a aparecer la imagen. Si tan solo dibujan en papel y usan un scanner a la hora de ajustar el tamaño los detalles grandes se van a deformar y los pequeños a perder por completo. También está el problema de la profundidad de color. Un Scanner puede capturar hasta 48 bits de profundidad de color pero las pantallas de muchos sistemas de videojuegos con dificultad alcanzan los 32 bits y aunque los alcanzaran el ojo humano puede no percibir bien las tonalidades. Algunos intentan paliar este cambio retocando las imágenes digitalizadas antes de integrarlas al juego. Debo advertirles que esto nunca funciona. Si una imagen digitalizada y pegada directamente a un juego tiene el aspecto de un recorte de revista una imagen digitalizada y retocada en un editor gráfico va a parecer un recorte de revista al que le dibujaron encima. Otro problema al convertir un dibujo a sprite sin saber programar es el de que queda «delineado». Las figuras quedan con un contorno que hace que no se vean debidamente integradas con el resto de la escena. Esto es por no saber manejar la profundidad de color. De todos estos problemas hablaré en el futuro porque necesitan una nota para ellos solos. Ahora veamos como los modeladores 3D que no saben programar se dan de narices al tratar de hacer modelos para videojuegos.

Los Modeladores 3D no pueden escapar

Esta historia la vi en persona. Cierto modelador 3D se quejaba de que los modelos que hacía para videojuegos eran demasiado simples y angulosos y que cuando hacía que se vieran bien estos alentaban demasiado el juego o incluso no corrian. Esto sucede porque los primeros editores 3D para computadoras personales como el 3D Studio no hacían realmente modelos de objetos sino de escenas completas y a la hora de importar uno de esos archivos a un juego había demasiada información que en realidad no se usaba. Otro detalle que los modeladores 3D que nunca han hecho modelos para videojuegos es que los modelos se procesan en Tiempo Real. Hay reglas sobre como deben diseñarse esos objetos para que se vean bien en un videojuego de acción rápida y que no sobrecarguen las rutinas de rendering. Por ejemplo muchos de estos se dibujan incompletos de modo que al moverse rápido el cerebro humano los une. Si son observadores o tienen un Playstation de primera generación que funcione podrán ver como muchos personajes en realidad no tienen articulaciones sólidas. Otra manera de aligerar el rendering es usar las texturas de manera que parezca que el objeto tenga relieve irregular u obedezca a cambios de iluminación. El conocido como Normal-Mapping es en realidad una optimización para simular superficies irregulares en un objeto formado por caras planas.

Los modeladores 3D cuyo trabajo no se relaciona con los videojuegos no necesitan saber esto porque rara vez les piden hacer modelos que van a ser presentados por un sistema de visualización en tiempo real. Casi siempre lo que les piden son animaciones e imágenes fijas o en el caso de los que trabajan para cuestiones de ingeniería modelos muy detallados que no necesariamente se ven realistas. Al hacer modelado para videojuegos no se debe de hacer tanto detalle porque hace el modelo demasiado dificil de procesar. Pero tampoco basta con disminuir la cantidad de polígonos para convertir un modelo detallado en uno que pueda incluirse en un videojuego. Esto da al modelo una apariencia falsa y plástica. El proceso para convertir un modelo detallado en uno apto para un sistema en tiempo real comienza desde antes de diseñar el modelo detallado y toma en cuenta detalles tan poco artísticos como la precisión numérica usada para representar los vértices o que al multiplicar las dimensiones y profundidad de color de las texturas el resultado sea una potencia de dos alineable en memoria. En mi experiencia he visto gente que hace modelos de millones de caras con efectos de luz dificilísimos de procesar cuando podrían obtener resultados mas vistosos y eficientes con unos cuantos miles de caras, iluminación interpolada y unos cuantos juegos de texturas.

Por cierto, en mucho tiempo de convivir con desarrolladores de videojuegos, tengo por lo menos 10 años en los que no he visto que abran un archivo de imagen ni mucho menos uno de un modelo 3D a nivel binario. Casi siempre el sistema en el que están trabajando los carga de manera automática o los mas avanzados llaman a una función de una API (o a la clase de un paquete como dicen ahora) que lo carga en la memoria con tan solo pasarle el nombre del archivo. Les recomiendo que si quieren saber en lo que se están metiendo intenten un día por lo menos abrir uno de estos archivos en modo texto y desplegar los valores mas importantes. Conocer a nivel de bit los formatos gráficos de archivo no solo les ayudará a decidir cual es el formato que mas les conviene sino que podrán optimizar mejor los recursos y hacer gráficos mas rápidos, de mejor calidad y sin errores extraños relacionados con fugas de memoria.

Los Game Producers no pueden escapar

Esta última parte la pongo nada mas para reirme. Pues me resulta gracioso como los que menos parecen relacionarse con la programación en una empresa de videojuegos son los que mas daño pueden causarle a la empresa por sus pobres conocimientos sobre computación. Vamos primero con los game producers. Un game producer, o al menos los que yo he conocido personalmente son jóvenes egresados de prestigiosas carreras de negocios y tienen experiencia en comercio internacional. Para ellos es sencillo conseguir fondos para arrancar proyectos y conocen gente que les ayudará a publicitar y vender sus productos. Su problema es que decisiones que parecen perfectamente razonables para un negocio cualquiera pueden ser verdaderos suicidios a la hora de hacer videojuegos. Pues una cosa que casi todos los game producers aprenden a la mala es que esto de los juegos es lo que en cultura corporativa se conoce como «Bet Your Company» que es cuando inviertes meses o hasta años en producir algo que no sabes siquiera si se va a vender. Un Producer puede hacer cálculos del costo de desarrollar un videojuego a lo largo de un año y luego ver que la adquisición de una licencia de un engine puede recortar ese tiempo y el costo a la mitad. Cuando ve que el desarrollo no avanza según lo planeado contrata a mas ingenieros para sacar el trabajo y hasta prevee como cubrir las inminentes pérdidas. Y al final si es listo hace un trabajito para un cliente corporativo, queda tablas con las deudad y liquida la empresa. Esto le pasó porque aunque su razonamiento era perfecto para producción industrial o negocios tradicionales al no saber de programación cometió errores que lo llevaron a la bancarrota. Y es que para sacar a flote un negocio de software es necesario conocer una serie de fenómenos que solo ocurren en este tipo de negocios como que mientras mas ingenieros se unen al trabajo en etapas avanzadas mas tiempo tarda el sistema en terminarse o que lograr que un programador pueda modificar un código de otra persona cuesta mas dinero y toma mas tiempo que si el mismo lo hiciera desde cero. Incluso hay grandes tomos sobre administración del desarrollo de software y las carreras de ingeniería en computación mas serias comienzan a orientarse mas a eso que realmente a programar. Un productor o especialista en negocios que no sepa de programación puede cometer este tipo de errores y otros que le harán perder mucho dinero y sobre todo no cumplir a tiempo con los deadlines.

Los Beta Testers no pueden escapar

Finalmente llegamos a lo mas bajo de la empresa de videojuegos. Conocido en otra época como Beta Tester, un QA es un pobre diablo al que le obligan a jugar los mismos juegos malos una y otra vez durante horas para detectar errores. Si tanto los jefes encargados del departamento de control de calidad como los QA’s no saben nada de programación van a mantener las partidas durante dias y noches enteras y al final se les van a colar errores. Y eso ocurre porque probar un videojuego no es simplemente jugarlo sino que el que lo prueba debe de ser capaz de destruirlo.

Suponiendo que antes de pasarle al probador humano los programadores ya efectuaron toda una batería de pruebas automatizadas para llevar al videojuego a su límite y que el encargado de probarlo sabe de programación seguro hará pruebas que ningún jugador considerado normal haría. Por ejemplo, un programador sabe que los números se guardan en espacios de memoria de longitud limitada y no pueden crecer indefinidamente. Una prueba sería acumular todas las monedas o items que pueda para ver cuantas puede cargar el personaje, llevar el contador de puntuación a su máximo a ver si se detiene o reinicia o intentará atraer a la mayor cantidad de monstruos en una sola pantalla. Estas pruebas casi siempre conducen a un viejo error conocido como Overflow y pueden hacer que el juego se trabe u ocurran cosas extrañas. Otro tipo de prueba es la siguiente: Si conoce el concepto de banderas y toma de decisiones puede intentar cosas como tomar una vida al mismo tiempo que recibe el golpe final o intentar guardar el juego justo en el momento que va a aparecer la pantalla de game over. Incluso si conoce el concepto de máquina de estado finito y aceptores puede deducir y probar combinaciones de acciones que potencialmente podrían llevar al juego a un fallo. En fin, un QA que sepa de programación puede descubrir errores que un jugador normal no podría localizar ni aunque jugara durante años.

Ya para irme, les recuerdo que si se interesan por hacer videojuegos no pueden escapar de la programación. No importa si son artistas, productores o simple control de calidad. Les digo esto porque he visto grupos de desarrollo que no tienen programadores o estos son muy pocos en comparación con los especialistas en otras áreas. O que simplemente los menosprecian y marginan. Si sus trabajadores no tienen un mínimo de conocimiento de programación por lo menos procúrenles un asesor que si sepa y los oriente en su trabajo. Aunque viéndolo bien, si los artistas, productores o QAs no les interesa un mínimo la programación. ¿Para qué quieren dedicarse a hacer videojuegos?

Anime, Videojuegos y Cálculo Diferencial

Tips para estudiantes de la carrera de Programación de Videojuegos

Hoy en día comienzan a aparecer universidades con carreras tan interesantes como Animación y Desarrollo de Videojuegos. Cuando yo era pequeño y no sabía nada de programación la existencia de una escuela donde uno apendiera a hacer juegos sonaba tan fantástica (en el sentido de fantasía imposible) como la de la escuela para magos de Harry Potter. Pasado un tiempo corrió el rumor de que empresas multinacionales como Nintendo tenían unos pocos centros de entrenamiento en los que capacitaban a sus ingenieros y en cierto momento a finales del siglo pasado se destapó el rumor de que esta misma empresa tenía uno de estos centros ubicado al norte del continete americano. Tal instalación era conocida como Digipen y se rumoreaba toda clase de cosas respecto a lo que pasaba ahi dentro. Para todo niño y adolescente gamer era un sueño entrar a un lugar como ese. Pero como si no fuera suficiente la enorme distancia, la muy reducida matrícula (entonces solo admitian 2 estudiantes por año) y la dificultad de las materias. Sus jefes habían puesto una sentencia que sonaba mas como una maldición para alejar a los profanos e impuros: «Si quieres aprender a hacer videojuegos con nosotros debes de ser muy bueno con las matemáticas».

Les cuento esta historia para que los jóvenes de hoy sean conscientes de la enorme fortuna que tienen. Pues ya en México y otros paises de habla hispana existen carreras donde pueden aprender a hacer videojuegos. Tal vez no sean tan buenas como Digipen pero al menos cuentan como carreras profesionales y se encuentran registradas ante el gobierno. Existen carreras para todos los gustos y presupuestos que me llevaría mucho tiempo mencionar en detalle. De momento puedo mencionarles la Licenciatura en Animación y Arte Digital del ITESM que se da en una escuela de mucho prestigio y se enfoca al lado artístico y la Licenciatura en Multimedia y Animación Digital impartida en la UANL que se concentra mas por el lado de la ingeniería y tecnologiá. Pues bien, me han llegado rumores, sobre todo de esta última pero no dudaría que ha pasado también en otras escuelas de que hay un gran desencanto en los alumnos que entran a estas carreras.

Y aquí es donde entra la que podría llamarse como «La Maldición de Digipen» pues como ya habrán adivinado la principal queja sobre estas carreras es que tienen demasiadas matemáticas. No voy a regañar a los gamers y otakus ingenuos como muchos otros lo han hecho en internet sino que les voy a explicar en términos sencillos el porqué las matemáticas se relacionan tanto no solo con los videojuegos sino inculso con la animación tanto tradicional como por computadora.

Imagino que en este mismo momento varios de mis lectores se han de haber atragantado con un Pocky. Voy a darles un instante para que le den un trago a su Ramuné, terminen su partida en linea de Ragnarok y se les pase el susto. Estoy seguro que estos lectores no pueden creer que exista una relación entre las chicas mágicas en uniforme escolar, los emocionantes videojuegos de aventuras en linea y las aburridas y odiadas matemáticas. Pero existe. En esta entrada me voy a concentrar en el cálculo diferencial porque es el que mas se relaciona con la animación. Les recomiendo que sigan leyendo porque no los voy a aburrir e incluso sospecho que esto podría hasta llegar a gustarles.

Primero veamos lo que es la animación. Para que el ojo tenga la ilusión de que el cine y la animación tienen movimiento se presenta una secuencia rápida de imágenes donde cada una es ligeramente diferente de la anterior. Si lo hacemos bien, el ojo interpretará que esa secuencia de imágenes fijas tiene movimiento continuo. Los animadores antiguos hacían esas secuencias de imágenes con lapiz y papel que luego pasaban a una película cinematográfica. Con el tiempo mejoraron su técnica reciclando partes de dibujos, fondos y composiciones primero con materiales físicos y luego con computadoras. Pero sin importar cuanto ha avanzado la animación. La idea de presentar una secuencia rápida de imágenes con ligeros cambios de una a otra y que el ojo humano ve que se mueve sigue siendo la misma. Lo que debe de quedar por ahora claro es que para que la animación funcione los cuadros de animación deben de correr a suficiente velocidad y el cambio de uno a otro no debe de ser tan grande como para notarse. La animación es un cambio de posición con respecto al tiempo.

Ahora veamos como esto se relaciona con los videojuegos. Los juegos presentan también una secuencia de imágenes fijas que el ojo registra como una animación. La diferencia es que el videojuego es interactivo. La estructura de código mas importante en un videojuego y que hace posible esa interactividad se llama «Gameloop». Se trata de un ciclo infinito en el que primero se leen los controles, se ejecuta el programa que controla el juego y al final se genera un cuadro de animación que se muestra en pantalla. En los juegos de acción rápida esto sucede unas 60 veces por segundo. Como esto es muy rápido el efecto es una secuencia rápida de imágenes fijas. Pero a diferencia de la animación que conocemos aquí esos cuadros de animación simplemente se pierden luego de que los vemos. A este proceso en el que se genera un cuadro de animación en una fracción de segundo y que no se guarda en ninguna parte es lo que se conoce como «Animación en Tiempo Real» y es necesaria para que un videojuego presente una animación con la que los jugadores puedan interactuar.

Si nos metemos mas a fondo en el Gameloop vemos que la lógica del juego debe de pensar en esa única fracción de segundo en que existe entre el anterior cuadro de animación y el siguiente. Para que el movimiento sea real y los controles se sientan bien hay que saber que tanto debemos de cambiar la escena. Si lo hacemos bien la animación se verá realista y los personajes jugables responderán a las órdenes del jugador. Ahora veamos un ejemplo muy simplificado de animación normal e interactiva.

Digamos que tenemos una linea recta por la que debe de volar una nave espacial. La nave comienza en el paso cero y cada cuadro de animación avanza uno de esos pasos. Si reproducimos la secuencia de imágenes vamos a crear una animación de la nave que avanza hacia adelante. Si quisiéramos que la animación fuera interactiva, digamos que queremos que la nave avance solo cuando oprimimos un botón haríamos lo siguiente:

Primero colocamos la nave en el punto cero y luego entramos al gameloop. Al inicio del gameloop vamos a ver si el botón está siendo presionado por el jugador. De ser así incrementamos en uno la posición de la nave. Si el botón no está siendo presionado no se aumenta la posición. Al final del gameloop generamos la imagen con la nave en su nueva posición. Podemos hacer que la condición para salir de ese gameloop infinito sea que la nave llegue al paso 100 o que se oprima el botón para terminar el juego. De ese modo tenemos una animación interactiva en la que hacemos que la nave avance cuando presionamos el botón.

Si presentamos la animación a una velocidad de 60 cuadros por segundo la nave hará su viaje en poco mas de segundo y medio en un vuelo ininterrumpido. Desde el punto de vista del programador la nave cambia de posición un poco en cada ciclo del gameloop. Ahora veamos una pequeña sorpresita.

La Animación son pequeños incrementos de movimiento respecto a pequeños incrementos de tiempo…
¡Y eso se llama Diferenciación!

La sorpresa que les tengo es que lo que acaban de leer en estos últimos párrafos es puro cálculo diferencial aplicado. Y mientras me imaginan poniendo una Trollface por haberlos hecho leer algo de matemáticas yo les voy a explicar con palabras sencillas como el ejemplo de animación es lo que lo que se llega a ver en el primer semestre de cualquier ingeniería.

La animación es movimiento. El movimiento se puede representar matemáticamente como la distancia en función del tiempo. En el ejemplo de la nave el movimiento es lineal a velocidad constante y sin aceleración. Se trata de una función lineal de primer grado. Ahora veamos donde entra el cálculo diferencial.

No voy a meter signos raros intercalados con las palabras «sea», «tal que» y «entonces» porque ya los he trolleado demasiado para una sola entrada. Solo les voy a decir que el cálculo diferencial estudia el cambio de las funciones a medida que avanzan en pasos cada vez mas pequeños. Volviendo a la animación. A medida que el cambio en la secuencia de imagen y el tiempo que hay entre un cuadro de animación y el siguiente se reducen la animación se va haciendo mas y mas real hasta llegar a un punto teórico donde los incrementos se acercan al cero y suceden tan rápido que la animación comienza a ser igual al movimiento que existe en nuestro mundo físico.

El movimiento que definimos de la nave es a velocidad constante (un paso por cada unidad de tiempo) y no tiene aceleración (no aumenta su velocidad ni la disminuye). Al avanzar un paso por cada cuadro de animación la nave tiene una velocidad de un paso por cada unidad de tiempo. Y aquí viene otra sorpresita. Ustedes acaban de aplicar la derivada a una función de movimiento sin aceleración. Cuando diferenciamos una función de movimiento sin aceleración el resultado es una constante. En el caso de la animación de la nave esa constante es uno. Si quisieran cambiar la velocidad o definir movimientos mas elaborados, el proceso es el mismo.

De momento solo voy a mencionar todo lo que pueden hacer con esta técnica en el mundo de la animación y los videojuegos. Las funciones de segundo grado se usan para movimientos con aceleración constante como los que involucran a la gravedad en los juegos de plataformas, y las de tercer grado pueden simular la aceleración variable de un motor que varía su potencia. Hay muchas cosas mas de animación que pueden resolver tan solo sabiendo aplicar el cálculo diferencial. En un futuro mas o menos lejano les explicaré mas sobre el tema.

¿Todavía no te interesan las matemáticas?

Personalmente creo que esa aversión por las matemáticas que muestran los aspirantes a programadores de videojuegos viene en parte por los maestros que aunque dominan el tema no saben ni les importa nada del mundo gamer. Por otro lado, si los estudiantes supieran que para lograr un determinado efecto especial necesitan aprender cierta rama de las matemáticas probablemente no le tendrían tanto desprecio. Por ejemplo, a mis amigos y a mi nos tomó mas de un semestre darnos cuenta que para hacer una cámara movil necesitábamos entender el cambio de base en un sistema de matrices ortogonales. Si de inicio hubiéramos visto ese mismo tema en la clase de Algebra Lineal lo mas seguro es que nos hubiéramos quedado dormidos en clase. Pero si en la búsqueda por lograr una cámara movil en un juego 3D nos hubieramos topado con el cambio de base de matrices ortogonales la cosa habría sido mucho mas emocionante.

Tengo que admitir que la situación actual de estos estudiantes me resulta por completo desconocida. Pues cuando llevé las materias de matemáticas en la carrera ya había visto esos temas en libros de computación (especialmente la materia de Matemáticas Discretas) o por lo menos había escuchado que algunos de esos temas se relacionaban con la programación de videojuegos. Ya para terminar esta nota que ha quedado tan larga, mi consejo es que si quien lee esto tiene un cargo importante en alguna universidad (y si conocen al Rosas pásenle el enlace a esta página) organice las clases de modo que las matemáticas no sean tan obvias. Si comienzan la clase con «Vamos a hacer un Angry Birds pero necesitamos averiguar como programar el lanzamiento de los pájaros con la resortera» será mucho mas ameno y divertido que si empiezan con un «Y esto es un polinomio de segundo grado y deben de aprenderlo bien porque les va a servir cuando hagan juegos». Al final de ambas clases los alumnos sabrán como se relacionan los polinomios de segundo grado con el tiro parabólico y el movimiento con aceleración constante pero los primeros habrán puesto mas ateción y lo mas importante: Habrán aprendido a resolver un problema de programación de videojuegos usando las mismas matemáticas que usaría un programador verdadero. Si los alumnos van con la idea de que hay un conocimiento oculto que les permitirá hacer sus juegos y los maestros los reciben con la conciencia de que sus alumnos quieren aprender cosas que les van a servir para hacer videojuegos y animación ambos se verán beneficiados y con ello será posible levantar en latinoamérica verdaderas escuelas de animación y desarrollo de videojuegos. Pues recuerden que hasta hace poco el decir que ingresarían en una escuela de programación de videojuegos sonaba tan increible como anunciar que pretendían aprender a manejar el Sable de Luz con el Maestro Yoda o ir a entrenar al Santuario para obtener la Armadura de Pegaso. Hoy en día ya existen verdaderas carreras universitarias que aunque no sean las mejores, al menos ya existen. Ustedes tienen una oportunidad que muchos otros nerds de hasta hace poco nunca tuvieron, y lo mas importante. Muchos ingenieros arruinaron su vida profesional o se amargaron en la carrera para lograr que las universidades tomaran en serio esta clase de temas. Y si un dia se sienten decepcionados por estas escuelas, recuerden que pueden recurrir a mi aunque sea para tener a alguien que los escuche quejarse.

Proceso, Subrutina, Función y Método son cosas diferentes

–¿Y ustedes cuando aprendieron a programar?–

Es posible darse una idea de en qué año aprendió alguien a programar por la forma como llama a los grupos de instrucciones que son llamados por un programa cuando interrumpe su ejecución. Quienes aprendieron a programar antes de los 60 del siglo pasado les llaman «procesos», los de los 70 y principios de los 80 los llaman subrutinas. De finales de los ochenta y toda la década de los 90 les llaman funciones y los que aprendieron a programar ya entrado el siglo XXI les llaman Métodos. Esto tiene que ver con las modas vigentes de la programación en cada una de estas épocas pero aunque tienen varias cosas en común. No son lo mismo. Y como este es un lugar donde se habla de ensamblador me voy a concentrar en describir como se han implementado este tipo de códigos para soportar estas técnicas de programación.

PROCESOS
resultado = a + b

Primero veamos lo que es un proceso. de acuerdo con los manuales de Intel. Un proceso es un grupo de instrucciones que cumplen una tarea determinada. Por ejemplo en ensamblador para sumar 2 números primero hay que recibir las posiciones de memoria en las que se encuentran, cargar el primero de ellos en el acumulador. Sumarle al acumulador el contenido de la segunda celda de memoria y luego guardar el resultado en la celda de memoria donde debe de almacenarse el resultado. Esto en un procesador actual son unas 5 instrucciones (aunque la suma en si es solo una). Ahora bien, la computadora ejecuta una tras otra las instrucciones que se le dan sin tener la menor idea de lo que está haciendo. Eso de agrupar el código lineal en procesos es tan solo para que los programadores humanos lo entiendan. Y la computadora va a ejecutar esas instrucciones hasta que reciba la orden de detenerse.

Los grandes códigos muy rara vez son lineales. Y en los códigos muy grandes es común que se necesite llamar a los mismos procedimientos muchas veces. Para eficientizar el uso de la memoria y la reutilización de código a alguien se le ocurrió que esos fragmentos de instrucciones se podían guardar en un lugar separado de la linea principal de ejecución del programa. De modo que cuando se necesitara ejecutar ese grupo específico de instrucciones tan solo había que hacer que la ejecución del código saltara hacia ese sitio y que al terminar regresara al punto exacto a donde se había dado el salto. Esto lo puede hacer porque cuando se le dice que tiene que dar ese salto el sistema guarda la posición donde se encuentra y luego tan solo la lee para regresar a donde estaba. Como si tuviéramos una cuerda a la que le amarramos un extremo al sitio donde empezamos para poder regresar con tan solo seguirla. Este sistema es tan viejo como las primeras computadoras de la década de los 50 aunque hay rumores extraoficiales que existían computadoras primitivas de tiempos de la Segunda Guerra que eran capaces de hacer esto. Ahora veamos como esta manera de llamar trozos de código separados en cualquier momento ha evolucionado con el paso de la tecnología.

Subrutinas:
GOSUB suma

El primer intento de organizar el código de programación fueron las subrutinas. Una subrutina era un grupo de instrucciones que se escribía al final del código principal justo después de la instrucción que indicaba el fin del programa. Aunque en algunos casos había quien las mezclaba con el propio flujo del programa principal y las aislaba por medio de saltos incondicionales. En el caso del antiguo BASIC se usaba la instrucción GoSub seguida del nombre de la subrutina. Cuando el código llegaba a esta parte primero guardaba la posición donde iba y luego saltaba a la subrutina. Ya en la subrutina, la última instrucción era RETURN. Cuando el procesador llegaba ahí hacía un salto hacia la dirección que había guardado previo al salto y seguía su camino en la linea principal del programa.

En ensamblador, este proceso fue copiado directamente con instrucciones como CALL y RET. CALL hace lo mismo que GoSub, guarda la posición en la que se encuentra y luego salta a donde se encuentra la subrutina. Cuando llega a RET tan solo toma la posición desde la que saltó y continúa su camino como si nada hubiera pasado. Aquí la clave es el STACK. Como ya saben el STACK es una zona de la memoria donde se guardan datos de manera que el último en entrar es el primero en salir. Esto permite que las subrutinas llamen a su vez a todas las subrutinas que quieran y que el CPU siempre pueda regresar al punto del programa del que la primera de ellas fue llamada.

Las subrutinas fueron muy útiles y todavía se siguen usando para programas pequeños y aislados. Aunque conforme el código si fue haciendo mas y mas estructurado mostraron serias desventajas. La primera de ellas fue que trabajaban directamente con los datos del programa principal, de modo que si uno quería reutilizarlas en otro programa debía copiar también cualquier estructura de datos, información o pieza de código con la que interactuara. Para que una subrutina fuera verdaderamente portable no debía de interactuar con ningúna variable o estructura ajena a si misma. Algunos programadores astutos escribieron subrutinas con una sección propia de la memoria de esa misma subrutina y evitaron su ejecución por medio de un salto. El problema con esto era que ya no se podía llamar a las subrutinas de manera tan libre como antes y la recursión (una rutina que se llama a si misma) resultaba imposible. Era necesario que cada que se llamara a una subrutina se creara un espacio de memoria en el que pudiera hacer lo que quisiera sin alterar el resto del programa y que cuando terminara este mismo espacio desapareciera. Además de que había que tener control sobre la información que esta subrutina regresara. Y fue así como nacieron las funciones.

Funciones:
resultado = suma(a, b);

Como respuesta a las debilidades de las subrutinas se crearon las funciones. Una función es en esencia una subrutina que se comporta del mismo modo que lo hace una función matemática. Como supongo que quienes leen mis escritos no saben nada de cálculo voy a explicarles. Una función matemática recibe un grupo de argumentos, hace una serie de cálculos con ellos y regresa un único resultado. Tanto las funciones matemáticas como las de programación toman una serie de números a los que llaman argumentos y devuelven un único resultado. Una función que no recibe ningún argumento, que tampoco retorna un resultado y que de preferencia tampoco tiene un espacio para datos internos es idéntica a una subrutina.

Ahora veamos como se implementa una función en ensamblador. Lo primero que tenemos que entender es que las funciones tienen su propio espacio de memoria que toman prestado cuando son llamadas y que devuelven cuando terminan de ejecutarse. Este espacio lo tomamos del STACK y formamos lo que llaman un Stack Frame. Un Stack Frame es una sección de la memoria gestionada por el STACK donde guardamos variables internas y recibimos argumentos externos. El tema del Stack Frame requiere mas de una entrada para explicarlo en su totalidad así que no voy a entrar en detalles. En ensamblador lo primero que hacemos antes de llamar a la función es introducir al STACK los argumentos del último al primero usando la instrucción PUSH. Una vez hecho esto llamamos a la función con CALL. Ya en el cuerpo de la función lo primero que hacemos es definir el stack frame guardando el apuntador base del stack y creando un espacio de direcciones virtuales (ya se que esto se oye muy complicado pero no es imposible) en el que el Stack Frame tiene de un lado los argumentos de entrada, luego la posición en la que va a regresar, luego los datos del stack frame anterior y al final el espacio para variables locales. Luego sigue el código de la función. En el cual debemos de trabajar solamente con los datos del stack frame y evitar relacionarlos con cualquier variable o estructura de datos externa. Solo así podemos garantizar que la función sea independiente y reutilizable en otros proyectos.

Para terminar la función tenemos que destruir el Stack Frame que creamos al principio. Esto es sencillamente un llamado a la instrucción LEAVE seguida de un RET con un argumento extra igual a la cantidad de bytes que ocuparon los argumentos de entrada. La instrucción LEAVE deshace el stack frame de manera automática y aunque se supone que trabaja con la instrucción ENTER. Yo en lo personal nunca he visto que ENTER se use.

Por cierto. Para que una función sea considerada como tal debe de retornar un único valor numérico. Como este valor numérico no puede ser guardado en ninguna parte por el código de la función lo que se hace es lo siguiente. Antes de ejecutar las instrucciones que destruyen el Stack Frame guardamos en el registro acumulador el valor de retorno de la función. De modo que cuando la función termine de ejecutarse y el CPU vuelva al código del que fue llamada. En el registro acumulador se encuentra el resultado de la función. De este modo podemos guardarlo en donde queramos, procesarlo o simplemente ignorarlo y seguir con el programa. El como hacer funciones en ensamblador verdaderamente portables es un tema del que un día voy a hacer una serie de entradas. Pues se trata de un tema complejo pero muy importante que debe de ser dominado.

Pero como era de esperarse, las funciones no son la solución para todo. Pues con la llegada de la programación orientada a objetos o simplemente OOP surgió la necesidad de asociar las funciones con eso que llaman objetos. Antes una función podía ser llamada desde cualquier lugar por cualquier código. Pero cuando se programa orientado a objetos cada función es ejecutada por un objeto o interviene un objeto en particular. La única manera de lograr esta lealtad entre las funciones y los objetos fue la creación de lo que los jóvenes programadores de la época actual conocen como Métodos.

Métodos:
resultado = Calculadora.suma(a, b);

Los métodos son como las funciones en cuanto a estructura interna pero se diferencian de estas en que solo pueden ser ejecutadas por el objeto al que pertenecen. Y es en los métodos en donde se ve la verdadera diferencia entre un objeto y una simple estructura de datos. En el ejemplo del subtítulo. El método suma solo puede ser ejecutado por una instancia del objeto llamado Calculadora. Las ventajas de esto es que (dicen los que defienden la OOP) se tiene mayor control de quién está haciendo que cosa. Personalmente a mi me parece un desperdicio irresponsable de memoria, burocracia excesiva y una sobrecarga peligrosa en la gestión interna de la memoria del sistema operativo. La única ventaja que hasta ahora le he encontrado a la OOP es que es muy facil modelar sistemas muy grandes en papel antes de sentarse a programar.

En fin, en la OOP cuando queremos que algo se haga debemos de averiguar que objeto es capaz de hacer aquello que queremos, crear una instancia y darle la orden de que haga lo que queremos. El sistema tiene que asegurarse de que no sea posible llamar al método sin pasar primero por el objeto. Piensen en un jefe que le ordena a sus trabajadores especializados que hagan labores en lugar de hacerlos él mismo. Ahora veamos como se hace en ensamblador para echar a andar un sistema de llamada que usa objetos y métodos.

Un método en ensamblador es idéntico a una función excepto por una cosa: Uno de sus parámetros lo relaciona directamente con el objeto al que pertenece. En el resto de sus componentes internos es igual a una función. La diferencia mas grande en los métodos no radica en el método en sí sino en el sistema que los manda ejecutar. Ahora veamos un poco de como se define un objeto.

En programación se define objeto como una entidad abstracta moldeada a partir de una clase que tiene un conjunto de atributos y métodos propios que bien pueden ser privados, públicos o protegidos. En ensamblador un objeto es una simple estructura de datos cuya primera mitad guarda datos propios como cualquier otro conjunto de variables y la segunda mitad contiene las posiciones de memoria donde se guardan los métodos que tiene derecho a ejectuar. Algunos sistemas tienen estructuras internas que gobiernan a los objetos o que simplifican su estructura interna. Por ejemplo en ciertos modelos de programación basados en Windows existe una tabla intermedia que asocia los objetos con los métodos para mejorar la seguridad. Creo que la mayoría de los que leen esto ya saben todo esto así que no voy a profundizar mas. Ahora veamos lo interesante que es ver como se maneja un sistema de métodos orientados a objetos en ensamblador.

Cuando queremos llamar un método perteneciente a un objeto desde ensamblador. Lo primero que debemos de hacer es crear una instancia del objeto. Para lo cual llamamos a la función constructora que recibe una serie de argumentos entre los cuales destaca la posición de memoria donde el objeto va a ser creado. Lo creamos e identificamos el valor que asocia el método con el objeto. Una vez encontrado este valor hacemos la llamada al método como si fuera una función. Por desgracia no hay una forma general de hacer esto y cada sistema tiene sus propias reglas para manejar los objetos y los métodos. En tiempos del MS-DOS Borland tenía la suya. Windows en los tiempos del modelo objeto componente COM tenía el suyo y los sistemas basados en iOS tienen su sistema propio. Por suerte es muy raro que tengamos que construir uno de estos sistemas desde cero como cuando comenzaron las funciones. Casi siempre el propio sistema operativo tiene su manera de gestionar todo esto. Casi siempre…

En fin, personalmente llamo procedimiento a cualquier grupo de instrucciones que llevan a cabo una sola tarea y llamo subrutina o función a un segmento de código «llamable» dependiendo del manejo de los argumentos y el humor del que amaneza ese dia. El término Método solo lo uso en relación con sistemas orientados a objetos. Lo que no deben de olvidar es que no importa que tan extraña sea la moda vigente en programación. Si corre en una computadora puede programarse en ensamblador. No piensen que programación orientada a objetos solo es Java o C++. Siempre se puede combinar la velocidad y control del Ensamblador con cualquier rareza intelectual que se ponga de moda en los ambientes tecnológicos. Y aunque no es sencillo, el resultado bien lo vale. Pues solo cuando programan en ensamblador la computadora va a hacer lo que ustedes le ordenan. De lo contrario, ustedes tendrán que hacer lo que les ordene la computadora. O en el peor de los casos, el inventor del software con el que tienen que trabajar para ganarse la vida en sus trabajos honrados.

Informe asm86[006]

–3D, Ciencia de Revista y Vividores–

En Noviembre del 2010 escribí el último informe asm86. Había decidido ya no escribirlos para ya no quitarle el tiempo a la gente que lee estos escritos en busca de programación en ensamblador. He decidido retomarlos para mantener informados a los lectores de cambios y demás cosas intrascendentes. Por lo que pueden perfectamente ignorar estas entradas si lo que buscan es programación.

¿Y la serie de Programacion Gráfica?

El tema de hoy es sobre la serie de programación gráfica que inicié desde octubre del 2011. La verdad es que esa serie resultó ser mucho mas extensa de lo que pensaba. Tanto así que una de cada nueve entradas escritas en toda la historia de este blog pertenecen a esa serie. Por si fuera poco, aunque esto no se si es bueno o malo. Muchos estudiantes que por lo que se ve ni siquiera han terminado la secundaria encuentran las explicaciones de esa serie muy útiles para hacer sus tareas de física. Espero que al menos esas entradas les inspiren a estudiar algo con valor científico o por lo menos los interese por las matemáticas. En fin, quiero suspender esa serie y rematarla con unos pocos ejercicios prácticos. De ese modo podrán usarla para sus cursos en las nuevas carreras de desarrollo de videojuegos que tanto están proliferando en latinoamércia. Puede que no sean tan valiosas como la visita anual de un instructor certificado en el uso del último y mas costoso paquete de diseño pero para los 3 o 4 que si quieren programar de verdad y no solamente hacer prácticas profesionales (o internships si no es escuela pública) seguro encontrarán esa serie como algo valioso.

Se lo que muchos de ustedes han de estar pensando. Que esperaban que esa serie les dijera como hacer un videojuego 3D de última generación. Lamento decirles que eso no es algo que se aprenda en unas pocas semanas leyendo unas cuantas docenas de notas en internet. Yo mismo llevo estudiando estas cosas desde 1997. Año en el que una buena parte de los que leen este blog (sobre todo los que vienen para que les ayuden con la tarea) ni siquiera habían nacido. Por si fuera poco, en esa serie no quise incluir nada de código de ningún lenguaje para evitar que se convirtiera en otra colección de llamadas a API y scripts de engine que tanto abundan hoy en internet sobre todo en las páginas de los «profesionales» del videojuegos. Y algunas ni a eso llegan.

El verdadero propósito de la serie de programación gráfica para principiantes fue inducirlos a lo que es en realidad la programación gráfica: Matemáticas. En realidad desde la primera entrada donde decía que solo necesitaban lapiz, papel y calculadora hasta la última en la que se generan vistas arbitrarias de una escena en 3D no necesitamos mas poder que el de una calculadora escolar. O una hoja de cálculo si es que no tienen mucha paciencia. Suponiendo que supieran la suficiente programación para conectar puntos con lineas rectas y conocieran los algoritmos mas elementales de programación de videojuegos lo mas avanzado que podrían hacer sería un videojuego como el de la imagen que acompaña esta entrada. Un juego vectorial de Star Wars creado en 1983. O también pueden tomar un engine y usarlo con un mínimo conocimiento de lo que están haciendo. Pues es para darse un facepalm ver como desarrollladores autodenominados profesionales tienen problemas tan tontos como el de que las unidades terrestres no se quedan pegadas al piso o que las cámaras nunca hacen las tomas que quieren.

En fin, no dejo de sentirme como un troll por este asunto así que les adelantaré que van a necesitar hacer por lo menos una multiplicación de matrices con el lenguaje de programación que ustedes mejor entiendan o que usen una hoja de cálculo porque en las últimas entradas vamos a ver como se diseña una escena vectorial y se le toman «fotografías» en diferentes partes del espacio. Ya en el futuro lejano veré si continuo en una segunda serie donde trate temas como iluminación, detalle de superficie, eliminación de partes ocultas o técnicas de animación. Pero eso será muy en el futuro, pues primero tengo que explicarles conceptos matemáticos que no hemos visto como funciones, cálculo vectorial, derivadas parciales y otras cosas que mejor no les platico para que no se decepcionen desde ahora. Espero que con esta primera serie que está virtualmente terminada (ya no va a haber temas nuevos sino solo practicar lo ya visto) sean por lo menos capaces de entender lo que es la verdadera programación gráfica y desarrollen sus propias cosas. Ahora pasemos con temas menos tecnológicos.

Los Vividores de la Ciencia

Existe la leyenda de cierto ejército cuyo nombre está prohibido mencionar en Internet había logrado increibles avances científicos en un período tan corto que hasta hoy en día hay quien asegura que habían recibido ayuda de los extraterrestres. Cuando les preguntaron a sus ingenieros como habían logrado tanto en tan poco tiempo mencionaban que la única diferencia era que su ciencia era diferente a la que acostumbraban hacer sus enemigos. Y que por desgracia es como se hace la ciencia hoy. Ellos aseguraban que la manera equivocada de hacer ciencia era hacerla demasiado teórica. Cuando la ciencia es demasiado teórica y poco práctica el resultado es que tenemos a un grupo enorme de personas que cuesta mucho mantener y que no producen bienes útiles ni comercializables fuera de unas pocas publicaciones que solo unos pocos intelectuales en el planeta entienden. Ellos decían que no podía invertirse dinero real en una ciencia teórica y que trabajando de este modo podían pasar generaciones antes de obtener verdaderos avances. Tal vez fue por la esperanza de terminar un arma que evitara su inminente derrota o que sus ideas sobre la ciencia fueran ciertas. El asunto es que ese modo parasitario de hacer ciencia, que para evitarme problemas voy a llamar «Ciencia de Revista» parece estarse extendiendo en latinoamérica en eso que ahora llaman desarrollo de videojuegos. Y no parece ser que sea con el inocente fin de «impulsar el conocimiento» que unos pocos académicos persiguen. Mas parece un plan de grupos bien definidos para hacerse de dinero facil y mano de obra barata.

Estos grupos usan las universidades como fuente de mano de obra casi regalada y para ahorrarse obligaciones legales. Esto no es nuevo y lleva haciéndose desde hace bastante. Lo que me entristece es que con ese pretexto se están perdiendo valiosos recursos. De hecho se rumorea que grandes eventos de eso que ahora llaman «geeks» se hacían tan solo para sacarle dinero al gobierno y a los patrocinadores ahora ya no van a ser tan grandes. Creo que alguien ya se está dando cuenta de que las empresas que dicen apoyar a impulsar no están rindiendo como negocios ni pagando los impuestos que deberían de pagar por haber ayudado a su creación. Yo propongo que el conocimiento debe de ser libre y que las empresas de videojuegos en latinoamérica deben de ajustarse a las mismas reglas que el resto de las empresas de la región. Eso de darles dinero del gobierno por proyectos no redituables hechos por adolescentes que se la pasan todo el día chateando en Facebook no es la forma de fomentar el desarrollo tecnológico y mucho menos cuando el salario de estos ‘trabajadores’ no alcanza los niveles mínimos con el pretexto de que se trata de ‘internships’. Estos grupos ni siquiera están fomentando el empleo porque solo contratan a gente de círculos muy pero muy elitistas y no precisamente porque sean los mejores. Y a los pocos que contratan ni siquiera se trata de empleos permanentes pues rara vez trabajan por mas de 2 años seguidos. Espero que si algún funcionario público encargado de darle dinero a estos vividores lee esto recapacite y mejor utilice ese dinero para mejorar la infraestructura de comunicaciones digitales que buena falta hace en latinoamérica. Sobre todo la de las universidades públicas porque es una verguenza que los estudiantes no puedan tener acceso a Internet luego de haberse gastado el cheque de todo un mes en el enganche de sus netbooks a crédito.

Por ahora los dejo y mejor me pongo a programar, que tengo mucho que leer y como recordarán la lectura es la tarea en la que un programador invierte mas horas.

Programación Gráfica: Recorte de Lineas de Liang-Barsky

–Como cortar un segmento de linea con un plano de recorte–

En la entrada anterior vimos todo lo necesario para entender lo que es el recorte de un modelo 3D. Que el recorte comienza desde que decidimos si cortamos o no y acaba en la reconstrucción del modelo que acabamos de recortar. En esta entrada vamos a ver un algoritmo de recorte de lineas en el espacio conocido como el Recorte de lineas de Liang-Barsky. Les recuerdo que el recorte es una operación básica en programación gráfica pero que mucha gente que afirma dedicarse a esto de los juegos 3D ignora por completo. Pero primero pasemos con las matemáticas.

En la primera fotografía tenemos las dos únicas cosas involucradas en el recorte de lineas en el espacio 3D: Un segmento de recta definido por sus 2 puntos extremos y un plano de recorte. Piensen en el plano de recorte como una navaja que corta un trozo de alambre muy fino. En la imagen el plano pueden verse 3 puntos del plano y un vector normal (la flecha que sale como un clavo) Para recortar necesitamos como mínimo uno de esos 3 puntos de las orillas del plano y el vector normal. Aunque cualquier punto en el espacio que haga que la ecuación del plano sea cero nos va a funcionar. Otra cosa que deben de recordar es que en una superficie completamente plana el vector normal va a ser siempre el mismo sin importar que punto de la superficie elijamos. Sobra decir que para que el algoritmo de recorte funcione el plano de recorte debe de quedar entre los dos puntos extremos de la linea que queremos cortar. Aunque veremos que el algoritmo de Liang-Barsky también funciona cuando esta condición no se cumple. Ahora veamos el algoritmo en acción.

En la tercera imagen vemos el algoritmo de Liang-Barsky en acción. El plano se ha acomodado de tal forma que solo lo podemos ver desde uno de sus filos. El segmento de linea es partido por el plano de recorte y podemos ver el punto exacto en el que esto sucede. También podemos ver una flecha extra que parte desde el punto naranja del plano. ¡Y que llega directo al punto de recorte!. En resumen, el algoritmo que estamos estudiando toma en cuenta que este vector que señala directo al punto de intersección está en ángulo recto con el vector normal al plano de recorte. Este vector lo vamos a llamar Vector Escoba porque «barre» la linea a todo lo largo hasta que topa con el plano que la va a cortar. Hasta aquí tenemos toda la información visual que necesitamos para aplicar el recorte de linea. Ahora pasemos a lo que todos los enginefags que vienen a este blog nada mas para ver como me burlo de ellos tanto temen: Las matemáticas.

Primero vamos a traducir las dos imágenes anteriores en expresiones matemáticas programables. Para hacer el recorte lo mínimo que necesitamos son una linea y un plano de recorte. Y a partir de ellos obtenemos los siguientes datos:

Vector normal al plano (N): Dependiendo de si hemos definido el plano en forma de ecuación de plano o con 3 vértices el método será diferente. Lo mas directo es tomar 3 vértices no colineales, convertirlos en 2 vectores mediante restas y luego hacer un producto cruz, aunque si el plano de recorte es fijo (como el de una toma de cámara) es mejor tomar los factores A, B y C de la acuación del plano Ax + By + Cz + D = 0 directamente.

Punto en el plano (Ppl).-Es un punto perteneciente al plano de recorte, puede ser cualquier trio XYZ que haga que la ecuación del plano sea igual a cero o si el plano se definió por 3 puntos en el espacio podemos tomar cualquiera de esos 3 puntos. Para que el algoritmo fuera mas sencillo de entender, el punto Ppl y el vector N se encuentran colocados de modo que N tiene a Ppl como base, aunque pudo haberse elegido cualquier otro punto del plano. Recuerden que N es igual en cualquier parte del plano.

Vector Direccional de la linea (D) El vector D se obtiene cuando tomamos las coordenadas del punto final de la linea y les restamos sus respectivas coordenadas xyz del punto inicial. El resultado es un vector que apunta hacia donde se supone se dirige la linea. Se obtiene en notación vectorial como D = p1 – p0.

Vector Escoba (E).-Este es el mas dificil. Se trata de un vector que tiene su origen en un punto del plano y su punta en algún punto dentro de la linea que queremos cortar. El problema es que no tenemos las coordenadas de ese punto, así que aquí es donde trataremos de obtenerlas. Ahora vamos a ver como crear la fórmula de recorte de lineas desde cero.

Explicación de las Ecuaciones

Lo primero que sabemos es que debe de haber un ángulo recto entre los vectores N y E. Y esto solo puede suceder si el producto escalar entre los vectores N y E es igual a cero.

N . E = 0

El problema es que como el punto al que señala el vector E no es una coordenada fija en el espacio sino que barre cual escoba toda la longitud de la linea, hay que definir esa coordenada como una función paramétrica. Entonces E sería igual a cualquier punto dentro de la linea a cortar menos el punto en el plano Ppl:

E = P(t) – Ppl

Entonces como el producto escalar entre los vectores N y E debe de ser igual a cero, si sustituimos E por la expresión anterior nos queda:

N . [P(t) – Ppl] = 0

Ahora sustituimos P(t) por su forma paramétrica p0 + (p1 – p0) * t

N . [p0 + (p1 – p0) * t – Ppl] = 0

El siguiente paso es engañoso. Hay que agrupar lo que está entre los paréntesis cuadrados en dos partes. Una es p0 – Ppl y la otra es (p1-p0) * t. Como se trata de coordenadas espaciales xyz, el resultado de este par de restas son dos vectores que ya conocemos. Si a eso le agregamos que t es un escalar que multiplica un vector podemos hacer un par de productos punto como indica la siguiente expresión:

N . [p0 – Ppl] + N . [p1-p0] * t = 0

Finalmente aplicamos un poco de álgebra para despejar t. Primero restamos a ambos lados de la ecuación N . [P0 – Ppl] y luego dividimos ambos lados por N . [p1 – p0] y el resultado es:

t = -N . [p0 – Ppl]/(N . [p1 – p0])

Ahora bien, si nos fijamos [p1 – p0] es el vector D que indica la dirección en la que va la linea que cortamos y [p0 – Ppl] es uno de los vectores escoba. Si profundizamos mas en las matemáticas que hacen funcionar el algoritmo de Liang-Barsky nos damos cuenta de que el parámetro t es en realidad el resultado del producto punto entre ese vector escoba y el vector D que se forma de la diferencia entre las coordenadas iniciales y finales del segmento de linea que estamos cortando. De hecho si el punto final de la linea p1 perteneciera al plano de recorte [p0-Ppl] seria igual a D multiplicada por -1, el parámetro t se eliminaria haciendose igual a uno y nos quedaría la igualdad N.D = N.D. Ahora veamos algunos casos especiales de la aplicación de este interesante algoritmo.

Casos especiales y Validaciones

Antes de simplemente aplicar la fórmula es necesario hacer algunas validaciones muy básicas. Para empezar tenemos que asegurarnos de que el denominador de la fórmula no sea igual a cero y esto solo puede ocurrir en los siguientes casos:

N = 0 Esto solo puede ocurrir si no hay plano de recorte. Ningun plano tiene una normal igual a cero

D = 0 Esto solo puede ocurrir si las coordenadas inicial y final de la linea que queremos cortar son las mismas, esto aunque es raro no es imposible. Sobre todo si la linea es demasiado pequeña o ha sufrido demasiados cortes. Es necesario validar y no cortar este tipo de lineas punto.

El Producto escalar N.D es igual a cero. Si esto sucede es porque la linea que queremos recortar es paralela al plano de recorte (lo que no necesariamente implica que esté contenida en el plano). Si de inicio se valida que los extremos opuestos de la linea estén cada uno a cada lado del plano de recorte esto no debería de pasar.

Una vez que nos hemos asegurado que no vamos a causar una de esas temibles divisiones entre cero ya hemos hecho las suficientes validaciones para asegurarnos que la linea es recortable. Lo siguiente es calcular el vector escoba [p0 – Pp1] y calcular el producto escalar de este con la normal al plano de recorte. Luego esta cantidad la dividimos por lo obtenido en el paso anterior y el resultado va a ser un número entre cero y uno que indica en que parte de la linea se dio el corte. Con este simple número podemos hacer muchas cosas que ahora veremos.

Obtener una coordenada espacial XYZ.-Esto es lo mas básico. Para obtenerla solo sustituimos el valor de t en la ecuación paramétrica de la linea, la cual para los que no la recuerden es p(t) = p0 + (p1-p0) * t. No se les olviden que estas son ecuaciones tridimensionales, así que tienen que repetir el cálculo para X, Y y para Z.

Definir dos nuevas lineas a partir de la linea cortada.-Una vez que obtenemos la coordena del espacio del ejemplo anterior que llamaremos p_corte tomamos el punto inicial p0 de la linea original y definimos como punto final p_corte. La segunda linea tendrá p_corte como su coordenada inicial de modo que una linea [p0, p1] pasa a convertirse en dos [p0, p_corte] y [p_corte, p1].

Ver si un objeto está o no dentro de una distancia.Existe un truculento algoritmo para ver si dos objetos se encuentran dentro de cierta distacia al que llamo «método de contacto por pinchazo». Imaginen que tienen que hacer que un monstruo lance una mordida al personaje del jugador si este se le acerca a una distacia mínima. Pueden definir una linea invisible entre las fauces del monstruo y el punto mínimo al que va a atacar. Si quitan la validación de que ambos puntos se encuentren en lados opuestos del plano el algoritmo devolverá un valor de t fuera de las fronteras de cero y uno. Sabrán cuando esta linea entre en contacto con la caja de contacto de otro personaje cuando el algoritmo retorne un valor entre cero y uno. Y no solo eso, sino que el valor entre cero y uno dará mas información de cuanto penetró este alfiler en el objeto. Y todo eso sin tener que usar raices cuadradas ni recalcular posiciones en cada comparación. Pues estos alfileres pueden moverse junto con los modelos 3d del juego. Una aplicación mas obvia de esto son los detectores laser que aparecen en los videojuegos de espias o de acción stealth.

Existen otras aplicaciones del algoritmo de recorte como por ejemplo determinar si algo está dentro de una linea de vista o si se puede eliminar de la vista sin peligro de que se vea la toma alterada. Esa es la eliminación da partes ocultas que veremos muy pero muy en el futuro. Por ahora es mejor dejar esto del recorte como está porque ya vimos suficientes matemáticas por hoy.

En realidad este tema del recorte debimos de haberlo visto hace mucho, mucho antes de que entráramos a la generación de vista en 3D. La razón por la que lo discutimos hasta ahora fue porque es hasta que se genera una vista en primera persona que los algoritmos de recorte se vuelven verdaderamente imprescindibles. Otra razón de esto es porque el algoritmo de Liang-Barsky es mucho mas sencillo de entender en 3 dimensiones. De hecho en los libros que lo mencionan lo explican en dos. El problema es que en dos dimensiones los planos quedan como lineas rectas y el recorte parece estarse haciendo entre dos lineas rectas.

En las siguientes entradas vamos a ver como se genera el volumen de vista y como cortamos una porcion del mundo para proyectarlo en una pantalla de computadora. De momento no voy a hacer un ejemplo de recorte porque la fórmula anterior es lo bastante sencilla para que la intenten ustedes por su cuenta. En cuanto termine las entradas sobre volumen de vista vamos a hacer una práctica donde se pondrán en práctica tanto la aplicación de las Coordenadas de Referencia Visual (o cámara para que me entiendan los grafistas), el recorte en el espacio y el volumen de vista en una misma toma en 3D. Nota aparte, sin contar unos pocos comentarios en las entradas de programación gráfica, llevo casi 4 meses sin insultar. Y aunque me dan ganas de seguir así hay tantas cosas «lulzosas» que me gustaría contar. Pero creo que mejor los dejo como comentarios al margen y llevo estas entradas de programación gráfica al menos hasta el detalle de superficies y eliminación de partes ocultas.

Programación Gráfica: Proyección Paralela

–La visión mas util no es siempre la mas realista–

Hace ya tiempo en la nota llamada «introducción a la vista 3D» les había comentado que además de la ya bien conocida proyección en perspectiva existe un tipo de visión poco realista pero muy importante para manipulación interactiva de modelos llamada Proyección Paralela. En los libros serios sobre gráficas por computadora hablan de la proyección paralela mucho antes que de la proyección en perspectiva por el simple hecho de que es un paso natural a la vista vectorial bidimensional con la que comienzan todos los textos. Yo en cambio decidí comenzar con la perspectiva no solo para no aburrirlos sino porque a menos de que ustedes tengan entrenamiento en dibujo de ingeniería la vista generada por la proyección paralela les iba a resultar poco estética y sin el menor sentido. Pero veamos de una vez como funciona y como aunque pueda resultar extraña es bastante mas sencilla que la perspectiva.

En la primera imagen vemos un volumen de vista para proyección paralela. Las lineas roja, verde y azul son el plano frontal F, el plano de proyección y el plano posterior B respectivamente. La linea punteada que pasa por el centro es el vector normal al plano de visión VPN y el centro de la ventana es el punto de referencia visual VRP. Pero hasta aquí llegan las similitudes con la perspectiva.

La primera y mas visible de las diferencias es que en la proyección paralela no tenemos una pirámide sino un rectángulo. La segunda aunque un poco menos visible es que ya no hay un ojo que indique donde se concentan las imágenes. Si bien el ojo todavía existe ya no puede ser considerado como tal. El punto equivalente al ojo en la proyección paralela simplemente se le llama Punto de Referencia de Proyección PRP y se encuentra en el centro del plano frontal F del volumen de vista. Por cierto, a esta proyección se le llama paralela no solo porque los planos opuestos que definen el volumen son paralelos, sino porque los proyectores que son las lineas que van de los vértices al observador son todos paralelos entre si. Pues aquí los proyectores no se concentran en un punto sino que como clavos caen sobre el plano de proyección y lo atraviesan.

Antes de pasar a las mateméticas, que son trollezcamente sencillas comparados con lo que hemos visto hasta ahora, hablemos mas de la proyección paralela. Personalmente me recuerda a la obra de pintores cubistas como Picasso. Pues aunque no se trata de imágenes visualmente realistas si revelan mucha información de los objetos. Por ejemplo las piezas no cambian de tamaño con la distancia, podemos comparar mucho mejor las medidas de los objetos y los cursores con los que movemos las piezas son mas sencillos de controlar. Comprobar si los modelos están alineados es mas sencillo y se eliminan los efectos de las ilusiones ópticas que pueden generar algunos efectos de luz. De hecho, la proyección paralela se parece mas a como el cerebro procesa y almacena las imágenes de los objetos que como las percibimos usando solo los ojos.

Ahora si, vamos con las matemáticas de las proyecciones paralelas. Para obtener los puntos en el palano de proyección a partir de sus coordenadas (x,y,z) lo único que tenemos que hacer es tomar directamente la X y la Y e ignorar Z. Es decir que X_Proyectada = X, Y_Proyectada = Y y Z se ignora. Para crear un volumen de vista paralelo basta con definir los valores máximos y mínimos del puerto de vista en el plano de proyección y los valores que ubican a los planos frontal y posterior.

Como dije al principio, las proyecciones paralelas se relacionan directamente con el dibujo en ingenieria. El dibujo de ingeniería, a diferencia del dibujo artístico no está pensado para ser estético, ni siquiera para parecerse al mundo que conocemos a nivel visual. En el dibujo técnico lo que importa son las medidas cuantificables en números y no las proporciones. Incluso si tomáramos todos los tipos de lápices que existen y los ordenáramos del mas blando al mas rígido. Los lápices usados por los artistas y los ingenieros quedan en los extremos opuestos de esas escalas, quedando el lapiz escolar justo en la mitad.

Siguiendo con el tema del dibujo de ingeniería. Mucho antes de que se inventaran los gráficos en tiempo real los dibujantes de máquinas creaban vistas múltiples de una misma pieza. Vistas frontal, lateral y superior. Dividían una hoja en 4 partes y junto con estas vistas planas incluian una vista en perspectiva para mostrar la pieza de manera entendible. De ese modo. El dibujo en perspectiva les daba una idea a los constructores de lo que iban a armar y las otras vistas los datos para poder armarlas.

Por cierto, en dibujo de ingeniería existen otras vistas generadas en la antiguedad que intentaban simular una proyección en tres dimensiones. Estas vistas solo las voy a mencionar por nombre esta vez, se trataban de la vista isométrica, axonométrica y caballera. Para que me entiendan los mas gamers, la vista isométrica se usó en algunos juegos antiguos de aventuras en la que los cuartos parecían ser vistos desde una de sus esquinas superiores como en el juego Diablo de Blizzard. La axonométrica es la que se usó en los primeros juegos de estrategia en tiempo real exitosos y permitía ver los objetos de frente y un costado como en el primer Starcraft y la caballera o de gabinete es la vista que se maneja en los juegos del género beat’em up como el Final Fight. Estas vistas aunque parecen tener profundidad en realidad son proyecciones paralelas y la manera de lograrlas es haciendo que el centro de la ventana no corresponda directamente con el punto de referencia de proyección. Cuando se hace esto el volumen de vista se tuerce como una pila de libros desbalanceada. Y luego por medio de una matriz de Shear o Sesgo que endereza la pila pero mantiene paralelos los planos de proyección, frontal y posterior del volumen de vista. Cuando se aplica esa transformación, todos los objetos contenidos en el volumen de vista se tuercen y quedan en la forma de la vista que queremos. Mas adelante les voy a hablar de este sesgo de vista que por cierto también se aplica a nuestra ya conocida proyección en perspectiva.

Ejemplo de Proyección Paralela

Ahora veamos un ejemplo de proyección paralela. En la imagen vemos una escena escena con 3 cubos marcados con las letras A, B y C. El punto de referencia de proyección se encuentra en (0,0,10) El valor del plano posterior B es igual a 2 y el frontal F a 10. El punto de referencia visual VRP que corresponde con el centro del plano de proyección es (0,0,7). La posición de los cubos se muestra en las vistas lateral y superior. Los valores xmin, ymin, xmax,ymax son -2, -2, 2, 2. Y multiplicamos la vista final por un factor de 2 para poder representarla en la hoja a tamaño legible. Para entender mejor los datos de este volumen de vista paralelo voy a usar una hoja de triturado numérico:

;VOLUMEN DE VISTA PARALELO

VRPz	= 7		;coordenada z del punto de referencia visual
B 		=  2	; Plano posterior o Backplane
F		= 10	; Plano frontal
XMIN	= -2	;X minima de la ventana
YMIN	= -2	;Y minima de la ventana
XMAX	=  2	;X máxima de la ventana
YMAX	=  2	;Y máxima de la ventana

ESCALA  =  2	;factor de escala para ampliar la vista final

;VERTICES DEL CUBO A	
 A_1 	= 0, 0, 9
 A_2	= 1, 0, 9
 A_3	= 1,-1, 9
 A_4	= 0,-1, 9
 A_5 	= 0, 0, 8
 A_6	= 1, 0, 8
 A_7	= 1,-1, 8
 A_8	= 0,-1, 8

;no pongo los vértices de los cubos B y C porque esos pueden leerlos directo del dibujo

Como recordarán de la introducción a la vista 3D. Las lineas proyectoras pasan en linea recta hacia el plano de proyección sin llegar a tocarse nunca entre ellas (de ahí lo de paralelas). Y es aquí que vemos que la proyección paralela es sumamente sencilla. Basta con tomar directamente las coordenadas X,Y e ignorar la Z. Así que vamos a triturar los vértices del cubo tomando solo sus coordenadas x,y y luego multiplicamos por el factor de ampliación para obtener las coordenadas finales. Va otra hoja de triturado numérico.

;PROYECCION PARALELA DEL CUBO A

;primero proyectamos al plano tomando x,y e ignorando z. Usamos P para no perder los valores originales del cubo A al proyectar.

 P_1 	= 0, 0
 p_2	= 1, 0
 p_3	= 1,-1
 p_4	= 0,-1
 p_5 	= 0, 0
 p_6	= 1, 0
 p_7	= 1,-1
 p_8	= 0,-1

 ;ahora escalamos por el factor ESCALA para obtener los puntos en la hoja. Recuerden que los pasos se cuentan desde el origen en el centro.

 p_1 	= 0, 0
 p_2	= 2, 0
 p_3	= 2,-2
 p_4	= 0,-2
 p_5 	= 0, 0
 p_6	= 2, 0
 p_7	= 2,-2
 p_8	= 0,-2

Ahora tenemos los 8 vértices del cubo A proyectados y escalados para poder dibujarse e una cuadrícula de 8 por 8 como la que vemos en la última foto. De momento vamos a dejarlo en el modo puramente matemático, pero ya verán al final de esta serie que incluso es posible obtener directamente las coordenadas de pixel en pantalla por medio de una transformación para al final en lugar de escribir vértice a vértice se copie toda la imagen con una sola transferencia de memoria. Así que por ahora cuenten desde el centro de nuestra «pantalla» de 8 por 8 cuadros en papel. De momento solo les he mostrado el cubo A, pero con las fotos que les he dado pueden calcular los vértices de los cubos B y C y transformarlos con las mismas operaciones ustedes mismos.

En la imagen pueden verse dos cosas. La primera es que aunque los cubos están a diferente distancia del plano de proyección todos tienen las mismas medidas como si estuvieran todos a la misma distancia. Solo podemos ver sus caras frontales. Esta vista lo que nos dice es que los cubos tienen las mismas medidas. Incluso podemos confirmarlo con solo ver la cuadrícula. Si la profundidad es demasiado importante inculso podemos mostrar los cubos en direrentes colores para indicar la profundidad a la que se encuentran sin perder la información sobre sus medidas. Que es lo mismo que los ingenieros conocen como ‘curvas de nivel’.

Antes de cerrar esta entrada, hablemos un poco sobre la proyección paralela. Para empezar, la proyección paralela es un caso particular de la proyección en perspectiva. Pues se trata del caso particular en que el ojo del observador se haya a una distancia infinita del objeto que queremos proyectar. Pues conforme el observador se aleja los rayos proyectores se vuelven mas y mas paralelos entre si. Esto puede expresarse de manera algebráica. Pero eso lo veremos mas adelante cuando unifiquemos los dos tipos de proyección en una misma matriz de vista. Por ahora pónganse a programar y recuerden que aunque no necesiten la proyección paralela para el gameplay de su juego si les va a ser muy util si algún dia quieren hacer su propio editor de gráficos 3D.

Programación Gráfica: Volumen de Vista y Zoom

–Como funcionan las miras de los First Person Shooters–

Esta es la continación de la entrada anterior sobre el volumen de vista. Como ya vimos, se trata de un volumen en forma de pirámide cuya punta termina en el ojo del observador y que contiene la porción del mundo que abarca el campo visual del jugador. Lo que vamos a ver hoy es como funciona este volumen de vista y como si sabemos controlar sus parámetros podemos crear efectos como el de una mira telescópica de un rifle de francotirador, cámaras capaces de obtener primeros planos de objetos móviles o con un poco de práctica obtener tomas grupales mas cinematográficas de manera automática.

En la primera imagen vemos una corte lateral del típico volumen de vista. Las diagonales inclinadas son definidas por las dimensiones de la pantalla y las lineas verticales de colores los planos frontal y posterior. El mas importante, aunque no forma propiamente parte del volumen, es el representado por la linea verde que es el plano de proyección. Cuando vamos a generar una vista 3D lo que hacemos es cortar la porción del mundo que queda dentro de la pirámide y luego proyectar aquello que quede dentro sobre el plano de proyección con las ecuaciones de proyección en perspectiva que discutimos hace ya tiempo. La linea punteada indica la dirección en la que el jugador está viendo. Esta linea de vista pasa exactamente por el centro de todos los planos.

Lo primero que necesitamos entender para comprender el volumen de vista es que los 3 planos de colores son siempre paralelos entre si. De ese modo la distancia entre ellos puede reducirse a una simple cantidad escalar en lugar de una compleja estructura de datos vectoriales. Lo segundo es que los valores que definen el volumen de vista están dados en coordenadas de referecia visual. La tercer cosa es que el corazón del volumen de vista se sitúa justo en el centro del plano de proyección, que correspondería con el centro de la pantalla y por donde pasa la linea de vista. Una cuarta cosa que confunde mucho a los principiantes es que el volumen de vista se abre en dirección opuesta a la que indica el vector que define el plano de proyección. Esto hace que el número que indica el alcance del campo visual sea cada vez menor conforme la distancia de vista aumenta. Esto es completamente contraintuitivo pero es necesario para que los cálculos funcionen.

Si somos conscientes de estas cuatro cosas podremos definir un volumen de vista de cualquier proporción y longitud con tan solo 6 valores. Ahora veamos con detenimiento cada una de las partes que componen un volumen de vista 3D.

Como definir un Volumen de Vista

En la segunda imagen se ve el volumen de vista con mayor detalle. El corazón del volumen de vista está a la mitad de la linea vertical verde marcada como VRP (view reference pointo o punto de referencia visual) que como recordarán indica el punto central del plano de proyección. Este punto es muy importante porque todos los demás números se relacionan con este.

El ojo, o punto de referencia de proyección PRP queda en la punta de la pirámide. Si a este punto le restamos las coordenadas del punto de referencia visual obtenemos las componentes del vector normal al plano de proyección VPN. Este vector es común no solo para el plano de proyección sino también para los planos frontal y posterior. Mas adelante verán que el punto donde se situá el ojo al final corresponde con el origen de un transformado y muy óptimo sistema de coordenadas de referencia visual.

Xmin,Ymin,Xmax,Ymax.-Son 4 valores que indican las dimensiones de la pantalla. Mientras mas grandes sean estos valores mayor será el tamaño de la imagen que se va a generar en pantalla y por consiguiente el volumen de vista será mas amplio. Xmin y Ymin son las coordenadas de la esquina inferior izquierda de la pantalla y Xmax, Ymax las de la superior derecha. Pueden ser simétricas repecto a la pantalla. Estos valores no solo definen la amplitud del volumen de vista sino que nos permiten mostrar la imagen en diferentes tipos de monitores o tamaños de ventanas en un ambiente gráfico. Y por supuesto se considera que estos puntos son coplanares al plano de proyección.

Plano Posterior.- Mostrado en azul es el plano que limita la distancia máxima hasta donde se puede ver con claridad. Y aquí es donde comienza la confusión. Pues este número debe de ser menor que el valor que define el plano fronta.

Plano Frontal.- Mostrado en rojo. Es el plano que queda frente al ojo del jugador y que es el que evita que los objetos entren en su ojo (lo que generaría una división entre cero) El número que define el plano frontal debe de ser MAYOR que el del plano de posterior.

Plano de ProyecciónMostrado en Verde, aunque este no es precisamente parte del volumen de vista es importante asegurarnos que se encuentre en un punto entre los planos frontal y posterior, y para que esto suceda la componente Z (N en coordenadas de vista) del punto de referencia visual que indica el centro de la pantalla sea mayor que el valor del plano posterior pero menor.

Como la relación entre los números que definen los planos de proyección, frontal y posterior son completamente contraintuitivos (palabra que significa que algo en realidad es opuesto a como uno podría imaginarse que es) voy a explicarlo con otro dibujo. En la siguiente imagen tenemos un volumen de vista a lo largo de un eje horizontal. Este eje horizontal es la normal a los planos frontal (rojo), de vista (verde) y posterior (azul). El ojo o punto de referencia de proyección se encuentra en 16, el valor de F que define el plano frontal es 13, la componente z del punto de referencia visual VRP y que coincide con el centro de la pantalla es 10, el valor de B que define el plano posterior es 4. En la parte de abajo pueden verse lineas de colores mas gruesas que indican los valores de B, VRPz y F en términos absolutos. Por el lado izquierdo se tienen los valores máximos y mínimos de la vertical de la pantalla Ymin y Ymax. Es importante recordar siempre que en el sistema de coordenadas de referencia visual la normal al plano de proyección que se despliega en pantalla sale del monitor en dirección al usuario. Así que el volumen de vista se extiende en dirección opuesta a esa normal que en términos físicos sería hacia dentro del monitor.

Les aconsejo que jueguen con estos valores para obtener diferentes volúmenes de vista. El del ejemplo es un caso de un volumen de vista simétrico en el que la linea de vista coincide con el vector normal a los 3 planos. Pero este no es siempre el caso. Como cuando uno camina por la calle y mira de reojo hacia un lado sin girar la cabeza. Para lograr este efecto se dan valores máximos y mínimos de la ventana que no sean simétricos. Digamos que queremos hacer una pantalla de 4 unidades de alto por 4 de ancho, los valores simétricos serían -2,-2, 2, 2. Quedando el centro de la pantalla en 0. Pero también podríamos hacer que los límites fueran 0,0,4,4. Esto sin cambiar la posición del ojo o punto de referencia de proyección. Para poder procesar este tipo de vista se usa una extraña operación llamado Sesgo de Vista que reacomoda los planos y los realinea con la linea de vista ideal. Reacomodando con ello parte del mundo. Este tema se discutirá mas adelante porque también se aplica a la proyección paralela.

Como Simular una Mira Telescópica

Ahora veamos como controlando los 6 valores del volumen de vista podemos simular una mira telescópica en un juego de disparos en primera persona. En algunos juegos antiguos se simulaba la visión telescópica simplemente creando otra cámara que se acercaba al objetivo. Esto causaba algunos errores muy tontos en algunos juegos como por ejemplo que el personaje pudiera verse su propia nuca si se acercaba al objetivo lo suficiente. Por no mencionar que el temblor de las manos que hace tan emocionantes los tiros a largo alcance tenía que ser simulado. En fin, unos pocos juegos si implementaban la mira telescópica del modo que vamos a ver ahora mismo.

En las últimas imagenes se ven los dos casos. En ambos se tiene la misma situación en la que el jugador tiene frente a si a su oponente a una distancia fija. En la vista sin ampilificar tenemos F = -1, VRPz = -4 y B = -8 mientras que en la amplificada tenemos F = -1 VRPz = -3 y B = -7. La razón del signo negativo es porque el punto cero coincide con el ojo del tirador y la normal a los planos crece hacia la izquierda. Y la razón por la que estos 3 valores no son iguales como pretendía que fuera en un inicio es por simple descuido mio. En el recuadro inferior de cada toma tenemos la proyección que genera ese volumen. Los valores de Xmin, Ymin,Xmax y Ymax son -1, -1, 1, -1. que generan una imagen de 2 por 2 unidades que a su vez ha sido escalada por un factor de 2 para ampliarla y hacerla mas visible en un cuadro de 4 por 4. En la imagen que percibe el jugador puede ver a su oponente de las rodillas hacia arriba y aunque puede atinarle no puede hacer un tiro de mucha precisión. Veamos los datos de esta vista como los ve la computadora:

;VISTA SIN AMPLIFICAR
;el origen est\a en la cabeza del tirador 
;el volumen crece en sentido contrario a la normal de los planos
;la normal de los planos va hacia la izquierda

F: 		-1 	; plano frontal F en rojo
VRPz: 	-4	;plano de proyecci\on en verde. Coordenada z del VRP
B: 		-8		;plano posterior B en azul

;coordenadas inferior izquierda y superior derecha de la apertura de la ventana.
xmin: -1	
ymin: -1
xmax:  1
ymax:  1

Ahora veamos que sucede en la escena amplificada de la imagen.

Del lado derecho tenemos exactamente la misma situación con los dos personajes parados en el mismo sitio. Los valores de F, VRPz y B siguen siendo los mismos. Pero ahora los valores de Xmin, Ymin, Xmax y Ymax son -0.5, -0.5, 0.5 y 0.5. Con lo que el volumen de vista se estrecha tal y como pasa como si nos asomáramos por una mira telescópica. Como ahora tenemos un plano de uno por uno mostrado en una pantalla de 4 por 4 unidades el resultado es un acercamiento en el que podemos ver con mayor detalle la cabeza y parte del pecho del personaje oponente. Si el cambio no se hace en un solo paso sino en incrementos o decrementos pequeños pueden lograrse efectos drámáticos de acercamiento y por supuesto replicar los movimientos de modo mas realista.

;VISTA AMPLIFICADA
;el origen est\a en la cabeza del tirador 
;el volumen crece en sentido contrario a la normal de los planos
;la normal de los planos va hacia la izquierda

F: 		-1 	; plano frontal F en rojo
VRPz: 	-3	;plano de proyecci\on en verde. Coordenada z del VRP
B: 		-7		;plano posterior B en azul

;coordenadas inferior izquierda y superior derecha de la apertura de la ventana.
xmin: -0.5	
ymin: -0.5
xmax:  0.5
ymax:  0.5

Otros efectos que pueden lograrse es el de encuadre. En el que se definen puntos en el propio objetivo que correspondan directamente con los límites de la ventana o asociar directamente el punto de referencia visual a un objetivo para obtener primeros planos. Puede crearse la ilusión de que algo pasa a mucha velocidad por delante del jugador (como un avión supersónico en un juego de simulador de vuelo) con tan solo deslizar los valores mínimos y máximos de la pantalla en un sentido u otro. Y por supuesto ajustar la vista a diferentes tamaños de ventanas y monitores, que es la función mas importante de esos valores.

Para los que no entendieron la explicación del párrafo, seguido de cada una de las imágenes se muestran los datos del volumen de vista en el formato de triturado numérico.

Ya para terminar por hoy quiero comentarles sobre las ventajas y desventajas de la proyección en perspectiva. La principal ventaja es que es realista en el sentido que imita como los humanos ven su mundo. Es buena para un juego o una animación. Pero no en situaciones en las que necesitamos manipular objetos de manera interactiva como lo haríamos en un editor 3D. En la siguiente entrada vamos a discutir sobre otro tipo de proyección que aunque no es realista vence todas estas limitantes. De momento sigan programando y recuerden que en este curso de introducción a la programación gráfica no necesitan de grandes conocimientos o computadoras muy avanzadas. Así que no se dejen asustar cuando alguien venga a decirles que eso de hacer 3D es algo inalcanzable.

Programación Gráfica: Volumen de Vista

–Como se define el Campo Visual en los Videojuegos–

Cuando hacemos un juego 3D podemos crear mundos inmensos. Juegos de guerra con miles de unidades combatiendo en una gran ciudad, de aventura en linea con toda clase de paisajes, pueblos y bestias míticas o peligrosas pistas de carreras de varios kilómetros de extensión. En resumen, mundos tan grandes que no podamos abarcar solo con nuestra vista. Esta última declaración no es poética. A menos que lo que programemos sea una simulación de un juego de mesa cuyo tablero fuera mas pequeño que la pantalla (y aun ahí podríamos acercar la cámara a las piezas) lo que percibimos a cada momento en pantalla es una sección muy pequeña del mundo 3D que estamos explorando. Esa porción queda dentro de un volumen en forma de pirámide conocido como volumen de vista. En esta entrada discutiremos que es un volumen de vista y como funciona.

Si ustedes llevan tiempo queriendo hacer juegos 3D y nunca se habían preguntado que es un volumen de vista es normal. Pues las fronteras del volumen de vista nunca aparecen en la escena directo en la pantalla. Digamos que es como verse uno mismo la nariz. Siempre está frente a nosotros a donde quiera que vamos pero a menos que tengamos un problema de salud serio nunca entra en nuestro campo visual. El único rastro de la existencia del volumen de vista que los gamers pueden percibir es un error gráfico conocido como Pop-Up. En los juegos 3D antiguos (y algunos nuevos no muy bien programados) era muy común ver como algunas figuras aparecían de la nada. Esto era muy notorio en juegos de carreras o simuladores de vuelo. Primero el camino se veía completamente despejado y luego en la lejanía se materializaba de la nada una montaña o un edificio. A veces incluso podíamos ver como estos se ‘construian’ de adelante hacia atrás como si hubieran estado cubiertos con un manto de invisibilidad. Con el tiempo se fueron implementando técnicas mas o menos ingeniosas para disimular este problema como poner niebla u oscuridad y hacer aparecer esos objetos como si fueran sombras. La verdad es que lo que pasaba era que esos objetos que se materializaban de golpe era porque acababan de entrar en el volumen de vista por su cara mas grande. En realidad ocurría exactamente lo mismo con los objetos que entraban por un lado de la pirámide pero como estos quedaban fuera del campo visual nadie lo notaba raro. Ahora veamos que demonios es la figura de la primera foto.

El volumen de vista, como ya se dijo notas atrás, es una pirámide cuya punta o ápice se situa en el ojo del observador y se extiende conforme se aleja en dirección a lo que este está viendo. Ese es el volumen de vista infinito. Pero los usados en gráficas por computadora y por supuesto los juegos 3D no lo son. De hecho usar un volumen de vista infinito tiene muchos problemas. El primero es que ese volumen de vista no es realista. El ser humano tiene una distancia límite a la que puede ver con claridad y algunos objetos lejanos se generarían en tamaños tan pequeños que incluso serían mas pequeños que un pixel. El segundo problema tiene que ver con los objetos que se acercan demasiado al ojo. Si el vértice de algun objeto 3D llega a tocar el ojo del observador la ecuación de proyección en perspectiva daría una de las cosas mas temibles en el mundo de la computación: ¡División entre Cero!. Sin mencionar que los objetos serían demasiado grandes para ser visibles. El tercer problema es un poco mas dificil de explicar pero tiene que ver con que un volumen de vista infinito, o incluso uno finito pero demasiado grande generaría un volumen en unidades negativas en un sistema de coordenadas tridimensionales de mano derecha. Ahora veamos como convertir un volumen de vista infinito e inmanejable en un volumen de vista finito facil de programar.

Volumen de Vista Finito

Lo primero que vemos en la primera foto es que la figura cuenta con un ojo (la bola verde) y 3 planos (en la foto solo se representa el plano mas grande). El plano que está entre los otros dos es nuestro ya conocido plano de proyección y es donde las imágenes se van a proyectar. El cuadro que cierra el extremo mas grande es el plano posterior (plano B por backplane)del volumen de vista y limita hasta donde podemos generar nuestras imágenes. El mas pequeño es el plano frontal (plano F por front) y es el que limita que tan cerca pueden generarse los objetos que queremos proyectar. Recuerden que cuando trabajamos en 3D también manejamos algunas coordenadas fuera de la pantalla. Otra manera de considerar el plano posterior es como un cristal de seguridad que evita que los objetos de nuestro mundo 3D nos golpeen en los ojos. Una manera de recordar cual es el plano frontal y cual el posterior es simplemente recordar que estas posiciones son con respecto al plano de proyección y que estos 3 planos comparten el mismo vector normal (o un múltiplo escalar de este). Por lo menos así es como es al principio. Ahora veamos como controlar las dimensiones de un volumen de vista.

Un volumen de vista, sin importar si se trata de una proyección paralela (la que sirve para los editores) o perspectiva (la de los juegos en su gameplay) consta de 6 planos. La vista paralela es un cubo y la perspectiva una pirámide con el ápice o parte mas alta recortada. De momento nos vamos a concentrar en la proyección en perspectiva por ser la mas interesante para un programador de videojuegos. Pero antes de explicar como definir un volumen de vista vamos a discutir el porqué nos interesa hacerlo y que ganamos si logramos controlar sus dimensiones.

Como ya dijimos el volumen de vista abarca aquella porción del mundo que el jugador puede ver. Dependiendo de las circunstancias la vista puede cambiar. Por ejemplo si queremos cambiar de visión normal a visión telescópica o encuadrar un objeto distante en pantalla sin cambiar el punto de observación como podría ser el caso de una cámara externa o la vista por la mira de un rifle en un juego de disparo en primera persona solo tenemos que ajustar estos 6 valores. En otra nota futura voy a detallar esos 6 parámetros. Pero por ahora solo voy a comentar que 4 de ellos indican las distancias horizontales y verticales a partir del punto definido por el vector normal al plano de vista y los últimos dos indican la distancia hacia delante y hacia atrás del plano de visión. Se toma como centro, es decir si estos 6 valores fueran cero el volumen de vista se reduciría a tan solo un pequeño punto en el centro del plano de proyección.

Antes de irme quiero contar un poco sobre las últimas notas que vienen. Originalmente pensé que esta serie me iba a tomar a lo mucho cuatro meses pero esos 4 meses ya pasaron y apenas estoy alcanzando el final del segundo tercio de lo que tenía pensado escribir. Espero terminar esta serie de principiantes antes de que comience la temporada de calor y si se puede hacer una recopilación de estas entradas en un PDF de distribución libre para antes de que el verano termine. Lo que quiero comentar ahora que estoy reflexivo es hablar con ustedes sobre su propio volumen de vista. Y es que la segunda cosa que mas detiene el desarrollo de la programación gráfica entre los aficionados después del no saber matemáticas es precisamente el miedo que el 3D infunde a los principiantes. Soy lo bastante viejo para recordar los primeros juegos 3D para sistemas de 8 (si de 8) y 16 bits en la década de los ochenta. Ahora esos juegos se ven obsoletos y torpes pero en su momento esas estructuras de alambre verde en fondo negro, triángulos con dientes de sierra, texturas planas que parecían tableros de ajedrez y escenas con iluminación constante y cero sombreado despertaban exactamente los mismos comentarios que escucho de los desarrolladores en la actualidad. Que si para hacer 3D se necesita de miles de científicos y presupuestos de millones de dólares, que una sola persona no es capaz de hacer juegos 3D si solo tiene una PC y vive en un sótano (eso vayan y díganselo a John Carmack del DOOM a ver que cara les pone) o que no hacen 3D por la razón que se les ocurra.

El miedo que estas gráficas causan no se ha desvanecido a pesar de que ya se trata de algo bastante común. Lo único que tengo que decir al respecto es que esas empresas que crean este tipo de tecnología no comenzaron de ese tamaño y en el pasado hicieron juegos muy sencillos y quien no me crea solo busque en google juegos tan sencillos como Commander Keen o el One Must Fall 2099 y luego sorpréndanse al averiguar quienes los hicieron y qué están haciendo ahora. La habilidad de programar buenos juegos que tienen estos grupos fue lo que los hizo ricos y no como muchos piensan que fue la riqueza la que los hizo capaces de hacer buenos juegos. De hecho los algoritmos del 3D son muy viejos, algunos aún mas viejos que las propias computadoras. No deben olvidar que si le tienen demasiado respeto a una ciencia nunca la van a poder dominar, que estas cosas fueron creadas por humanos y que sobre todo programar es muy pero muy barato.

Como consejo, cuando alguien venga a decirles que ustedes no pueden hacer algo solo porque no tienen recursos (sobre todo si quien se los dice tuvo esos recursos y ni aun así pudo hacer las cosas) recuérdenle algo que le escuché gritar a un viejo hacker que conocí durante mis aventuras con el sistema GP32 cuando se dio una pelea típica sobre ensamblador: ¡El que TU no seas capaz de hacer algo no significa que NOSOTROS tampoco podamos hacerlo!

Así que si quieren hacer 3D ponganse a programar, lean algunos libros de matemtáticas y sobre todo no dejen que ningún desarrollador frustrado que se las de de profesional les cierre su propio volumen de vista.

Programación Gráfica: Triturado Numérico

Solo puedes programar lo que la computadora puede hacer

Hace no mucho tiempo, mientras hacía de Troll en el sistema de preguntas y respuestas del Yahoo. Encotré la que probablemente sea la pregunta mas inteligente que alguien interesado en la programación de videojuegos puede hacer: ¿Como es posible que una computadora que solo puede leer y escribir números y hacer operaciones matemáticas muy básicas con ellos sea capaz de crear el mundo virtual de un videojuego con todos sus elementos? La respuesta es sencilla: No puede. Al menos no puede hacerlo de manera directa como muchos por ahí se imaginan. Los mundos, personajes, historias y todo aquello que creemos vivir cuando jugamos no son otra cosa que señales digitales procesadas que se mueven de un lado a otro pasando por el CPU. O como cierto escritor de videojuegos dijera alguna vez: «Cuando crees que están combatiendo contra ejércitos enteros lo único que haces es contemplar puntos de colores desde el sillón de la sala de tu casa».

Esta reflexión no es la típica de tantos autodenominados «designers» que sin saber programar ni dibujar quieren su rebanada de esto de los videojuegos. De hecho esta nota puede ser bastante cruda o bastante alentadora dependiendo de cuanto les interese programar. Pues aquí se discute lo que sucede dentro de la computadora cuando hacemos esa cosa rara que llaman 3D.

Al escribir esto, recuerdo una declaración de cierto profesor de computación del que solia reirme mucho. Una de sus tantas frases célebres era que no le gustaba programar en Ensamblador «Porque cuando uno programa en ensamblador está limitado solo a lo que la computadora puede hacer» esta frase puede tener sentido hasta que uno se detiene a pensar en como hace entonces la computadora para hacer algo que se supone que no puede hacer. Aunque si vemos las cosas desde el punto de vista de alguien que no sabe nada de programación la frase no carece del todo de significado. Pero para eso tenemos que regresar a la primera pregunta con la que comienza esta nota.

Las computadoras, consolas de videojuegos, teléfonos y cualquier otro dispositivo electrónico programable no tiene idea de que lo que está ejecutando es un videojuego y es incapaz de diferenciarlo de una aplicación de cálculo de ingeniería o un software para reproducir contenido multimedia. Por dentro lo único que sabe es que tiene que ejecutar un montón de instrucciones que hacen cálculos repetitivos sobre una inmensa cantidad de datos. Y como ustedes están aquí porque les interesa la parte de la programación y no el retoque de botones de interfaces vamos a ver todo esto del modo como lo ven las computadoras. Pero antes de continuar veamos un concepto computacional conocido en el mundo de la ciencia como Number Crunching

Number Crunching
Hojas de Triturado Numérico

Number Crunching, que puede traducirse al español como «Triturado de Números» es cuando a una computadora se le dan unas cantidades enormes de números para que les aplique un conjunto de operaciones matemáticas y nos devuelva un resultado. Ese resultado puede ser tan sencillo como SI o NO, un número o una lista larga de valores, del mismo modo que existen máquinas que trituran enormes rocas para extraerles los metales o simplemente para pulverizarlas y convertirlas en cemento. El triturado numérico es habitual en la exploración del espacio, la economía, el pronóstico del tiempo y como veremos aquí también en la Programación Gráfica. En resumen, la programación gráfica es un ejemplo de la aplicación del triturado numérico. Y como tal vamos a tratarla aquí.

En fin, para no dar mas rodeos con el tema, lo que quiero anunciar es que este curso de programación gráfica para principiantes ya está llegando a un punto en el que aunque puede seguirse trabajando con lapiz, papel, calculadora y mucha paciencia ya estoy llegando a un límite en el que mostrar los cálculos hechos en una hoja de libreta que luego se fotografía resulta impáctico para ser presentado en una página de internet. Pues ocuparían demasiado espacio y serían muy difíciles de leer. Por lo que he considerado hacer algo para representar mejor este triturado numérico y a la vez enseñar un poco la manera como se hacen los cálculos gráficos en ensamblador.

Lo primero que voy a hacer es recurrir a una ventaja muy util que me ofrece este sistema de hospedaje de blogs y que nunca uso: La posibilidad de escribir ventanas de código con su propio formato. En estos recuadros uno puede escribir un texto y se le van a respetar el formato, y aunque existen otras formas de hacerlo esta parece ser la mas limpia y conveniente. Sin embargo, no basta con eso, es necesario definir un formato para presentar estos números.

Antes de explicarles que es esto del formato de triturado numérico quiero recordarles que estas hojas no son código de programación aunque están escritas de manera que sean facilmente adaptables al ensamblador. Ahora veamos de una en una.

Comentarios.-Una linea de comentarios comienza con un punto y coma ; y termina al final de la linea. Son solo para explicar lo que significan los números y no tienen nada que ver con los cálculos

; Este es un comentario de una linea

; Este otro comentario que puede
; abarcar mas de una linea

Etiquetas Las etiquetas son como el nombre de las variables y se usan para hacer referencia a los datos, y estos datos pueden ser desde sencillos números enteros hasta sofisticadas estructuras con muchos tipos diferentes de datos. Son palabras terminadas en dos puntos : y seguidas por las cantidades a las que apuntan. Para los que ya tienen experiencia en programación piensen en estas como variables.

;un ejemplo de etiquetas
; etiqueta_01 hace referencia al entero 64

etiqueta_01: 64

Enteros y FlotantesLos números que lleven punto decimal en alguna parte son números flotantes, es decir que pueden tener partes no enteras como 3.14 o -17.31. La inmensa mayoría de los cálculos gráficos se trabajan en punto flotante en punto flotante. Mientras que los enteros no tienen punto en ninguna parte y aunque no se usan para cuestiones 3D si se necesitan para cuestiones de la logica del programa.

;ejemplo de valor flotante o real

valor_flotante: 123.45


;ejemplo de valor entero

valor entero: 123

Escalares y Vectores

Las etiquetas pueden hacer referencia a valores individuales o a secuencias de números. Cuando tenemos un número solo se dice que es un escalar y cuando se tiene una secuencia de valores tenemos un vector. Por lo regular se trata de valores flotantes pero aquí podemos trabajar también con enteros. Las matrices son un caso escalar de vector que aunque es lineal se expresa en renglones separados para leerlo mejor.

; un escalar es un número solo mientras un 
; vector es una secuencia de números

escalar: 1.0
vector:  1.2, 2.3, 3.4, 4.5

matriz:  0.0  1.0  2.0  3.0 
         4.0  5.0  6.0  7.0
		 8.0  9.0 10.0 11.0
		12.0 13.0 14.0 15.0

En fin, este cambio lo hago porque se acerca el final de la serie de programación gráfica para principiantes, deben de quedar solo alrededor de 10 notas y unas cuantas prácticas, y para estas prácticas vamos a necesitar estas hojas de triturado numérico para poder mostrar de manera detallada como se trabajan los números involucrados en programación gráfica. Y regresando una vez mas a la pregunta original sobre como una computadora que solo puede procesar números puede ejecutar un videojuego, confirmamos una vez mas que no puede hacerlo. Los mundos de aventura de los videojuegos son creados por los artistas digitales y los programadores solo hacen que esos mundos, personajes e historias puedan ser vividas por los gamers en sus computadoras. Un trabajo un tanto frio, pero eso no impide que algunos programadores, si no es que todos, sueñen sus propias ideas para videojuegos que por su propia cuenta quieran implementar.

La Saga del Aprendiz de Programador

Tutorial para Aprender Ensamblador desde Cero

La imagen que acompaña a esta entrada es de la película Matrix. En la escena el protagonista conecta su cerebro a una computadora que le «instala» todos los conocimientos necesarios para hacerlo capaz de pelear. Aunque en la escena original lo que dice no es que ya sabe ensamblador sino kung-fu. Para su desgracia yo no cuento con una máquina como esa para enseñarlos a programar en cosa de minutos ni creo que ustedes quisieran arriesgar sus neuronas de ese modo si la tuviera, sin embargo estoy dispuesto a entrenar a otros interesados en la programación en ensamblador por medio de las entradas que he escrito estos últimos años.

Este es un directorio con todas las entradas sobre ensamblador escritas con los principiantes en mente. Y al escribir estas lineas pienso en dos tipos de lectores muy diferentes: Por un lado están los que solo quieren saber lo mínimo de ensamblador para aprobar una materia de sus estudios de ingeniería en computación y seguir felices con sus vidas administrando bases de datos y construyendo páginas web. Mientras que por el lado opuesto se encuentran aquellos valientes que al menos ya saben o han escuchado hablar de las grandes cosas que es posible hacer sabiendo programar en Ensamblador y en Lenguaje Máquina y están dispuestos a entrenar muy fuerte durante años para poder dominar este lenguaje. Sepan ambos que esto de programar en ensamblador no es algo que se pueda hacer en uno o dos semestres, la única diferencia es que los primeros van a encontrar mis escritos mucho mas ofensivos que los segundos.

Debo de advertirle a los del primer grupo que ya alguien calificó mis escritos como extremadamente ofensivos, por lo que no esperen de mi parte nada de eso que algunos llaman ‘ser políticamente correcto’. Estas entradas están pensadas para alguien que no tenga estudios especializados en computación pero que al menos tenga la suficiente dedicación para leer estas entradas en su totalidad. En cuanto a los del segundo grupo, que ya sabe que esto del ensamblador no lo van a dominar en un semestre y no les importa es probable que las burlas, ataques y demás peleas que van a presenciar en las siguientes entradas les resulten divertidas. Por cierto, este directorio se irá actualizando y reorganizando según lo considere conveniente, así que vengan seguido, y no se olviden que en cuanto ustedes ganen confianza y digan «Ya se ensamblador», yo estaré ahí para contestarles «Muéstrame».

Ensamblador desde cero

Una breve introducción de lo que te espera.

Fundamentos del Sistema Binario

Siempre se nos dice que las computadoras trabajan con ceros y unos. Para programar en ensamblador uno debe de ser capaz de entender el sistema de números binarios. En esta entrada se discute un sencillo método para convertir en binario números de 0 a 255. El porqué de estos límites se explican en la siguiente entrada.

Cuantos bits tiene un byte

Esta es hasta ahora la entrada mas leida de toda la historia del blog y por una muy buena razón. Aquí se explica que demonios es eso del bit y el byte, porqué un byte solo puede contener un número entre 0 y 255. Al final un byte es una cajita de 8 bits que puede almacenar un número en el rango mencionado

Prog, Hex and Rock’n’Roll. Sistema Hexadecimal

El sistema de numeración hexadecimal es una manera mas manejable de representar números binarios y permite trabajar con estructuras de datos mucho mejor que si usáramos los números de base 10 que la gente usa todos los dias. Todo lo que es procesable por una computadora puede ser representado por secuencias de números hexadecimales y eso incluye imágenes, texto, música, código y todo lo digitalizable.

Manejo básico de la Memoria

Aquí se explica como se almacenan los datos en una memoria de computadora a nivel software. Piensen en la memoria como una calle con casas numeradas (dirección de memoria) y que en cada una de estas pequeñas casas puede vivir un número (contenido de la memoria). Aquí es donde se ven las ventajas de usar sistema hexadecimal

ASCII-zofrenia o Secretos del Código ASCII

Seguro se han preguntado como hace la computadora para manejar textos si todo lo que puede almacenar y procesar son números binarios. En esta entrada se explica que el Código ASCII fue creado para lograr esto y como las disposición de sus letras no es arbitraria. Existe toda una lógica tras el orden de las letras y los números que pueden ser representados por un byte.

Funcionamiento de un STACK

Un stack es una estructura de datos básica que todas las computadoras utilizan y que incluso algunas implementan por hardware. Stack se traduce al español como ‘pila’ pero no en el sentido de pila de energía sino en el de apilar. Como una pila de libros por lo que les recomiendo usar siempre el término stack para evitar confusiones.

Este no es el fin de la saga, de momento hay muchas entradas que no he alcanzado a incluir aquí y en el futuro tengan por seguro que voy a escribir mas entradas destinadas para los iniciados en la programación en lenguaje máquina. Y recuerden que cuando mas capacitados están para aprender algo nuevo es precisamente cuando son conscientes de que no saben nada.

La última actualización de este directorio fue en febrero 2 del 2012, regresen seguido para ver las actualizaciones.

---

Pueden empezar por aqui

[SIGUIENTE] Ensamblador desde Cero

Programación Gráfica: Fundamentos de Recorte

–Como Cortar Objetos 3D–

Como ya dije hace mucho, una de las técnicas que uso para ver que un libro sobre gráficas por computadora realmente toma el tema de la programación gráfica en serio es ver como manejan los algoritmos de recorte. El recorte en gráficas vectoriales es algo que se utiliza casi tanto como las ecuaciones de proyección pero que en la mayoría de los casos se hace de manera transparente al usuario. Lo interesante es que los algoritmos de recorte no solo se usan para rebanar figuras en el espacio sino que también se utilizan para validar contactos, física, simulación de linea de vista como cuando queremos saber si el jugador puede ser visto por una unidad enemiga o para algo tan elemental como separar lo que queda dentro de nuestro campo visual en un mundo 3D de lo que queda afuera, aunque esto último solo lo saben los que han intentado hacer su propio engine gráfico pues como dije al principio, los motores actuales hacen esto de manera completamente transparente al desarrollador. Pero antes de explicar como funciona el recorte veamos una pequeña historia que viví de propia mano hace no mucho tiempo.

Como ya dije, el recorte de lineas, polígonos y sólidos basados en vectores en el espacio es algo tan elemental en la programación gráfica como las ecuaciones de proyección en perspectiva o la transformación de coordenadas. Pues bueno, una vez estaba muy feliz en la comunidad de internet de desarrollo de videojuegos que todos los creadores de videojuegos de latinoamérica conocen y alguien llegó con la noticia de que los programadores (esos si son programadores) de Konami habían implementado un sistema de recorte arbitrario en tiempo real en su nuevo motor gráfico llamado entonces el Fox Engine. Si bien tiene un gran mérito implementar un sistema de recorte arbitrario y en tiempo real por la complejidad de las estructuras de datos que están involucradas hacer un recorte en el espacio no es algo tan sorprendente como suena. De hecho, si los programadores de ese sistema gráfico no hubieran sabido desde antes como hacer un recorte no habría sido ni siquiera capaces de programar el engine gráfico en primer lugar. Como es de esperarse tales declaraciones tuvieron revuelo y creo que por ahí hasta salieron rodando algunas sandias virtuales. En ese entonces no quise hacerla de pleito porque de todos modos la mayoría de la gente ahí presente no me iba a entender pero aquí que estoy entre programadores si que puedo explicar con toda tranquilidad en que consiste el recorte en 3D y toda la ciencia que hay detras de este.

Recorte de lineas rectas en el espacio

Lo primero que tenemos que saber sobre el recorte en 3D es que este se da exclusivamente entre rectas y planos en el espacio. En los casos que estemos trabajando con un espacio vectorial en dos dimensiones se considera que los planos de recorte son perpendiculares al plano donde se lleva a cabo la acción cual si se tratase de muros. Lo segundo es que siempre es el plano el que recorta a la linea recta, nunca se recortan dos lineas rectas porque hacer que dos rectas en el espacio 3D se crucen es casi imposible ni tampoco se cortan dos planos porque el resultado es una recta con un sinfin de ecuaciones posibles. En cambio, cuando un plano corta a una recta (o visto de otro modo cuando una recta perfora un plano) el resultado es un sencillo número que dependiendo de nuestras necesidades puede convertirse en las coordenadas de un punto en el espacio, un valor escalar o una simple bandera de decisión para la lógica del juego. En el caso del recorte se trata de lo primero, de obtener la coordenada del espacio donde el segmento de recta y el plano se intersectan. La última cosa que deben de saber del recorte es que no basta con ser capaces de calcular el punto donde la linea y el plano se encuentran sino que es necesario redefinir por completo el modelo 3D a nivel de sus estructuras de datos. Y cuando digo completamente me refiero desde la definición de sus vértices, aristas y caras hasta el detalle de superficie y la forma como lo afectan otros modelos cercanos. Incluso en algunos casos puede ocurrir que al cortar un objeto este se multiplique (se hagan dos o mas) aunque si se siguen ciertas reglas estos casos pueden presentarse muy pocas veces.

En la primera imagen tenemos la situación en la que un segmento de recta definido por sus dos extremos inicial y final son cortados por un plano en el espacio. Y en la segunda imagen tenemos dos representaciones de un plano y un segmento de recta. Repasemos como se definan matemáticamente estas dos entidades. Como recordarán, un segmento de recta o arista tiene un punto inicial p0 y un punto final p1 y si la definimos en forma paramétrica existe un parámetro t que va de cero a uno entre estos dos puntos. Por su parte un plano se define por un punto en el espacio y un vector perpendicular que lo traspasa del mismo modo que un clavo a un trozo de madera. Aunque como ya saben es posible obtener estos dos datos a partir de 3 puntos en el espacio que no estén alineados que es como suelen definirse las superficies planas en los juegos 3D. El recorte de lineas toma como entradas los 2 puntos extremos del segmento de la linea que queremos cortar y el punto y el vector que definen el plano de recorte. El algoritmo de recorte regresa como resultado el valor del parámetro t en el que el plano recorta a la linea. Existen muchos algoritmos usados para hacer el recorte pero los dos mas usados y del que todos estos descienden son los algoritmos de recorte de Cohen-Sutherland y el de Liang-Barsky. El algoritmo de Cohen-Sutherland es bueno para computadoras muy sencillas que solo puedan manejar valores enteros y obtiene el punto de intersección por medio de la búsqueda de raices conocida como Método Bolzano mientras que el de Liang-Barsky aplica una fórmula directa y sencilla pero que requiere que el equipo tenga capacidad de procesamiento de punto flotante. En las siguientes entradas vamos a examinar ambos algoritmos y tomaremos lo mejor de cada uno. De momento solo necesitamos saber que los algoritmos de recorte toman como entrada una recta definida por dos puntos y un plano de recorte que ha de funcionar como una navaja. La función retorna el parámetro t en el que el segmento de recta y el plano de recorte se intersectan. Función que veremos con detalle en la siguiente entrada.

Con el parámetro t devuelto podemos hacer muchas cosas. La mas obvia es obtener la coordenada espacial en la que se da el corte. Para hacer esto basta sustituir el valor de t en las ecuaciones paramétricas de la recta. Aunque puede darse también el caso en el que la recta y el plano sean paralelos entre si y nunca se corten o incluso que la linea sea coplanar al plano de corte que al final es como si no se cortara. Otra cosa que puede pasar y de hecho pasa la mayoría de las veces si no se hace una buena validación es que el parámetro t devuelto por la función de recorte de un valor fuera del rango de 0 a 1. Cuando esto sucede la linea si es cortada por el plano, pero en un punto que está mas allá de sus extremos finales. Recuerden que matemáticamente las lineas rectas en el espacio tienen longitud y delgadez infinitas. Y para colmo de males, encontrar el punto en el espacio en los que un plano y una linea se intersectan es apenas una muy pequeña parte de lo que es el recorte.

Antes y despues de recortar

Resulta que hay que hacer una larga cantidad de validaciones y cálculos previos antes de hacer un recorte y una vez obtenidos los puntos en los que las lineas son cortadas es necesario reconstruir todo el modelo para poder representarlo en pantalla. Como ambos temas son demasiado extensos y esta entrada ya me quedó muy larga solo voy a mencionar las técnicas que hacen esto y en otra ocasión las describiré en detalle. La primera de las validaciones es conocida como la prueba dentro-fuera en donde nos aseguramos que la linea tenga sus extremos en lados opuestos del plano de recorte. Esto se hace evaluando las coordenadas de los vértices en la ecuación del plano y comparando el signo. Proceso que en los procesadores Intel actuales se resume a una sola instrucción de ensamblador. Si los signos son opuestos la linea puede ser cortada. Esta prueba dentro-fuera se extiende a algo llamado Prueba de Eliminación de Cohen-Sutherland que se usa para generar vistas de mundos complejos y determinar contactos en el espacio de varios miles o millones de vectores. Otra validación, que en realidad es una potente optimización consiste en aprovecharse de que hacer recortes usando planos perpendiculares a los ejes coordenados toma la tercera parte de las operaciones matemáticas que requiere hacerlo respecto a un plano cualquiera, así que es posible escalar y sesgar todos los objetos de nuestro mundo 3D y minimizar las operaciones de recorte. Esto puede parecer un esfuerzo inutil pero reescalar el mundo usando matrices es mucho mas eficiente que hacer recortes arbitrarios e incluso puede agregarse este escalamiento a la matriz de transformación de vista de modo que cambiaríamos lo que podrían ser varios millones de validaciones y dos tercios de otros millones de cálculos de punto flotante por una humilde multiplicación de matrices de 4 por 4 que podemos hacer en menos de una docena de ciclos de reloj.

De acuerdo, lo anterior fue apenas la preparación para cortar los modelos 3D. Ahora veamos que ocurre luego de que hemos dado el hachazo. En realidad hacer un recorte en 3D es mas parecido a una amputación quirúrgica de una extremidad que a un simple corte de un material sin vida, pues no solo debemos de ser cuidadosos para no cortar si no hay necesidad sino que después de haberlo hecho necesitamos hacer toda una reconstrucción. Lo primero que obtenemos luego de hacer un recorte es una lista de coordenadas xyz en la que cada una de las aristas se cruza con el plano de recorte. Si solo queremos obtener el punto donde se cruzan no necesitamos hacer nada mas pero lo mas probable es que queramos quedarnos con las piezas separadas. Y ahí es donde comienzan los problemas porque ahora cada una de las aristas se habrá duplicado. Digamos que tenemos una arista cuyos puntos extremos son p0 y p1 y que el recorte se da en un punto intermedio que llamaremos pR que obtuvimos sustituyendo el parámetro t dado por la ecuación paramétrica pR = p0 + (p1-p0)*t. Ahora tendremos 2 aristas separadas. La primera va del punto p0 a pR y la segunda va de pR a p1. Si mas adelante queremos reposicionar estas nuevas aristas obtenidas basta con cambiar sus nuevos valores iniciales y finales. Pero el problema de la reconstrucción no termina aquí.

Recortar un modelo 3D de estructura de alambre es el caso mas sencillo de reconstrucción de un modelo post-corte. El caso mas común y verdaderamente complicado es cuando queremos recortar un modelo construido a partir de polígonos con detalle de superficie. Pues a la hora de reconstruir el polígono no solo se corre el riesgo de que estos se dividan en muchos mas pequeños sino que deben de reconstruirse. Esta es una de las muchas razones por la que usamos caras triangulares para construir objetos complejos. Los triángulos al ser recortados respecto a planos de recorte rara vez se dividen en mas de dos partes, sus coordenadas de textura y normales son mucho mas sencillas de ajustar luego de ser cortados y en el caso del recorte de volumen de vista que es la aplicación mas importante del recorte ya existen muchos algoritmos para cortar estos triángulos de manera eficiente e incluso eliminarlos por completo sin necesidad de cortarlos. En el caso del recorte de vista no importa mucho si recortamos un polígono y lo dejamos abierto. El problema es cuando queremos recortar un sólido en un editor 3D o peor aun hacerlo en tiempo real como en el Fox Engine de Konami. Pues no solo hay que redefinir por completo vértices, aristas y polígonos sino que incluso es necesario definir polígnos y aun sólidos que antes no existían. Piensen un momento en el caso de una sandia. En su versión original se usa una textura verde con blanco para simular la cáscara de la fruta. Pero a la hora de cortarla necesitamos una textua roja que muestre el interior de la fruta. A menos que de inicio hubiéramos definido un conjunto de propiedades internas de la sandia esta ni sus polígonos van a existir cuando hagamos el recorte. Otro buen ejemplo del recorte es la madera. Podemos usar una textura para la parte externa pero si usamos la misma imagen va a parecer como si la pieza de madera estuviera forrada con papel adhesivo color madera. Ahora veamos como se hace para cerrar una figura que ha sido cortada de esta manera.

Recorte y Reconstrucción de Sólidos 3D

Cuando recién cortamos una figura hecha por polígonos con detalle de superficie y solo tenemos la lista de puntos donde cada arista es cortada por los planos tenemos que reconstruir cada polígono de manera individual. Afortunadamente existe un algoritmo que hace esto al momento de recortar que se llama Algoritmo de Sutherland-Hodgman que para explicarlo en pocas palabras funciona igual que uno de esos plásticos adhesivos que se usan para sellar los recipientes de comida. Ese algoritmo recorre los vértices del polígono en forma circular y agrega o elimina vértices dependiendo de los puntos obtenidos luego de recortar. Para los casos en los que quedan huecos en el modelo 3D se aplica una variante del algoritmo de Sutherland-Hodgman basado en el conocido (aunque no por todos los titulados) Algoritmo del Cerco Envolvente en el que se van creando nuevas caras conforme un plano ‘envolvente cubre las partes abiertas del modelo 3D. Una vez obtenidos los datos sobre vértices, aristas y caras de estos nuevos polígonos que antes no existian ya tenemos un modelo 3D usable, aunque por regla general los recortes nunca se hacen uno solo a la vez y en muchos casos es necesario repetir el proceso una y otra vez como en el caso del viejo recorte de vista.

Ya para terminar porque esta entrada quedó demasiado larga y no encuentro por donde recortarla quiero dejar claro el porqué los algoritmos de recorte son tan necesarios en Programación Gráfica y a la vez tan poco conocidos por quienes reciben dinero por dedicarse a estas cosas. Resulta que la aplicación mas elemental del recorte 3D es la creación del volumen de vista. Tema que veremos en un futuro espero no muy lejano. Las tecnologías actuales usadas por los aficionados hacen este recorte de manera automática y los que usan software de modelado 3D ni siquiera son conscientes de que hay que recortar aquello que queda fuera de nuestro campo visual. Es por eso que esto del recorte no es entendido por cualquiera. Sobre todo por la parte de la redefinición de datos involucrada en un buen corte. Recuerdo en tiempos de los primeros editores 3D que el ponerle nombre a cada sólido luego de cortarlo era un proceso tedioso y desconcertante. Manejar esta redefinición de datos requiere mucho conocimiento de programación gráfica y no solo de como hacer llamadas a una API. Es decir, de cosas que no cualquiera que diga dedicarse a esto de los juegos 3D domina realmente. Es por eso que mi último consejo es que si quien está leyendo esto tiene bajo su mando a un equipo de desarrollo de videojuegos y quiere reducir costos mandando a algunos empleados de vacaciones forzadas páselos de uno en uno a su oficina donde tiene su computadora con monitor dual y dígale que le explique como funcionan los algoritmos de recorte. Verá como estos algoritmos no solo sirven para recortar lineas y polígonos. ¡También sirven para hacer recorte de personal!