Vagabundos de 32 Bits

¿Era ese el final de los Programadores de Ensamblador?

Esta historia es continuación de la nota anterior llamada “Desterrados de 32 Bits” que a su vez es continuación de “Revolución de 32 Bits” y cuenta uno de los episodios mas deprimentes en la historia de la programación en Ensamblador de principos de este siglo.

En la última entrada se cuenta como de la noche a la mañana, se volvió casi imposible programar en Ensamblador para computadoras con Windows basados en tecnología NT (como el 2000, ME y XP) y como muchos tuvieron que dejar de lado la programación en Ensamblador y rebajarse a manejar bases de datos para poder sobrevivir. Y de como mis compañeros programadores y yo decidimos hacerle frente a este destierro sin obtener lo que se dice los mejores resultados en el proceso. Sin mas, aquí está la historia:

El asunto no podía quedarse así, por lo que en ese entonces reuní a lo que entonces era mi pequeña banda de forajidos computacionales y en una junta tomamos una de las decisiones que, aunque tuvo muchas cosas buenas retrasó nuestro avance en el desarrollo de videojuegos por al menos nueve años. Ahí, frente a unos demos de DirectX, recuerdo especialmente uno de una calabaza de halloween que desplegaba un Framerate de 120 FPS, nos preguntamos:

¿Continuamos con la programación directa del hardware o nos metemos con DirectX?

¡Demonios! Si pudiera regresar el tiempo justo a ese instante me abofetearía a mi mismo hasta que solo me funcionaran el sentido del oido y el sentido común y me gritaría a mi mismo:

¡No seas 9*n3+@5! ¡Es perfectamente posible programar para Windows en Ensamblador!

Pero en ese entonces tenía un concepto muy equivocado sobre lo que era programar para Windows. Creía que la única manera de desarrollar para las versiones mas avanzadas de este sistema operativo era con herramientas como el Visual Studio y similares. Las cuales en ese entonces (o sus equivalentes de ese entonces) aunque eran buenas resultaban muy caras, extremadamente difíciles de conseguir, con infomación casi nula y aún bien dominadas el rendimiento del producto final no se comparaba con el de una aplicación programada completamente en Ensamblador. Por lo que, confiados en nuestra habilidad para programar en ASM tomamos una decisión tan valiente como ingenua: ¡Nuestros juegos debían de ser capaces de ejecutarse sin sistema operativo!

Hoy en día es mas o menos conocido el concepto de Live CD entre los aficionados a Linux. Y para los que no saben, un live CD es un disco que uno pone en una computadora y que es capaz de correr una aplicación completa sin necesidad de alterar en lo mas mínimo el sistema operativo instalado, y se usa para versiones de prueba de sistemas operativos. Nuestro plan era hacer juegos que funcionaran de la misma manera. Durante ese tiempo, que abarcó mas o menos 2 años aprendimos muchísimo sobre como hacer un sistema operativo y, al igual que cuando intentamos hacer un compilador propio y nos topamos con FASM, esta vez nos topamos con MenuetOS. Un interesante sistema operativo de Europa Oriental programado completamente en Ensamblador. Aprendimos mucho de esa experiencia, aunque mas hubiéramos aprendido de haber sabido hablar ruso. Algunas de las hazañas que conseguimos en ese entonces fueron:

• Arrancar una PC sin sistema operativo por medio de un Bootloader en Floppy y CD
• Hacer controladores de discos y periféricos para ese bootloader.
• Entrar al modo protegido desde ese bootloader
• Tomar control sobre el misterioso BIOS de 32 bits.
• Manipular el BUS PCI y todos lo periféricos conectados al mismo.
• Manipular las tarjetas de video de aquel entonces compatibles con el estandar VESA 2.0 y superior.
• Mover grandes cantidades de datos con el DMA de 32 bits.
• Y muchas cosas igual o mas impresionantes que al final no nos sirvieron para mucho.

Al final, ya cuando teníamos la capacidad de desarrollar software mas o menos decente que corriera desde un live CD (por cierto, en esa época las grabadoras caseras de CD eran tan caras como una computadora de escritorio) nos topamos de narices con que la gente no aceptaba ningun software que no corriera en Windows. Era una ironía que aún teniéndo la capacidad de desarrollar un sistema operativo completo si hubiéramos querido eramos incapaces de programar unos humildes juegos.

A partir de entonces no ocurrió nada bueno, salvo el haber levantado una pequeña oficina en un local que había permanecido abandonado durante cuarenta años. Y que a pesar de tener serias carencias nos sirvió bien para continuar nuestras investigaciones por los primeros 2 años de este siglo XXI. En ese corto espacio jugamos a ser una empresa de 3 (5 si contamos al Samuel y a Aldape) programadores sin documentos ni ganancias. Pero que logramos uificar todo lo que hasta entonces habíamos desarrollado.

Sin embargo, al pasar el tiempo y no lograr avances que fueran redituables el grupo se fue debilitando. Ya no éramos mas los programadores capaces de trabajar en un demo por 3 días seguidos de campamento en la oficina, algunos se vieron obligados a trabajar por hambre y necesidad. Eso sin mencionar que en ese entonces fue cuando me expulsaron de la universidad cuando ya iba en mi penúltimo semestre. El juicio fue algo traumático pero mas traumáticos fueron los meses antes y después del mismo. Y como ya comenté, no podré poner un pie en mi antigua facultad hasta bien entrado el 2024. Pero si regreso no va a ser como estudiante. Por cierto, mas o menos a la mitad del siguiente año fue cuando nuestro grupo de desarrollo acabó de desmoronarse por completo. Aunque aun nos veíamos ocasionalmente para planear estrategias que nunca llevábamos a cabo. Y aunque habíamos caído, aun no estábamos muertos.

Y aun estaba por venir lo peor…

Los siguientes dos años fueron los peores, no tiene caso que comente mis tragedias personales pero solo voy a decirles que en ese entonces fue cuando comenzó mi odio contra los lamers, pues en ese tiempo no encontraba trabajo ni como barrendero y el ver como todos los empleos en computación se los llevaban gentes cuyas únicas habilidades eran copiar querys, escribir documentos html (y no precisamente con un editor de texto), hacer clientes con editores de Visual Basic y trabajar con hojas de cálculo era algo que me enfurecía mas allá de los límites del razonamiento humano. Aún recuerdo como disimulé el asco al saludar de mano a un jefe de recursos humanos que tenía unas horribles manchas en la piel.

Y así pasé ese tiempo hasta que un día me llegó el chisme de que al otro lado del mundo alguien estaba desarrollando una nuevo consola de videojuegos y que no encontraba programadores. Esa pequeña aventura fue lo que me mantuvo vivo durante esos años negros y aunque no terminó como me hubiera gustado,si me hizo sentirme mejor conmigo mismo y me ayudó a reconstruir parte de mi antiguo equipo de desarrollo. Dicho aparato era conocido como GP32 de una empresa de Corea del Sur llamada Gamepark ubicada en Seoul. Espero poder escribir sobre ese asunto un día de estos. Pero supe que lo peor había pasado cuando, durante una sesión de programación con esta consola portatil, el buen Julio dijera:

–Te ves mucho mas repuesto que como te veías en los años de universidad… ¡En especial el último!

En fin, en el tiempo en que tuve esa consola coreana en mis manos recuperé mucho de lo que había perdido en años anteriores y si no fuera porque mi familia me obligó a rehacer mis estudios muy probablemente estaría escribiendo este blog desde algún lugar de Corea del Sur. Sin embargo, a pesar de esta gran victoria semipersonal (pues el Julio también colaboró muy de cerca) la programación para sistemas Windows había quedado abandonada durante siete años y dudo que en los 2 próximos años pueda hacerse algo que valga la pena vender. Apenas hace un año y luego de meses de ingeniería inversa y otras artes oscuras que no se si sea seguro mencionar en público es que logré hacer funcionar el ensamblador en una computadora con CPU de nucleo múltiple en Windows Vista. Y es ahora cuando realmente puedo retomar todo lo que dejé pendiente hace ya tanto tiempo.

Derrotados pero no muertos

Como se dijo en la nota anterior, este regreso a la programación en Ensamblador para Windows se debe en gran parte a los esfuerzos de grandes programadores como Iczelion, el autor del FASM Thomasz Grysztar, gente de sitios como asmcommunity.net y otros muchos mas que a partir de mucha investigación lograron devolverle su merecido lugar a la programación en ASM. En la siguiente entrada se hablará de este feliz regreso. Sin embargo, apenas se había descubierto el camino a seguir. El recorrerlo y llegar hasta el final era un esfuerzo de proporciones épicas, mismas que se detallarán en la siguiente nota donde además de eso se contará como los programadores de Ensamblador regresamos al territorio del que alguna vez fuimos cruelmente expulsados.

Destierro de 32 Bits

C:\>RUN\DOS\RUN>

Esta es la continuación de la entrada anterior titulada “Revolución de 32 Bits”.

La última nota trató sobre el como las PC’s equipadas con procesadores 386 y superiores abandonaron lentamente la programación en 16 bits para dar paso a aplicaciones mas avanzadas de 32 bits. Y como el mundo tuvo que esperar casi 10 años para ver juegos que realmente aprovecharan el hardware de estos entonces poderosos equipos. En esta parte de la historia se cuentan unos años horribles en los que llegué a pensar que era el fin de la programación en Ensamblador para computadora personales.

Corrían los últimos años del siglo veinte, poco a poco las conexiones de tipo Dial Up se volvían inoperantes y los primeros monitores LCD (de esos que si uno no estaba parado directamente de frente a ellos no se veían) comenzaban a aparecer. Esa era una época maravillosa en la que el DOS y el Windows 95 cohabitaban en la misma computadora y existía la controversia de que tanto uno dependía del otro. Tiempos en que el Windows NT solo existía en equipos empresariales y aunque era muy estable no servía para jugar. En ese tiempo aún había juegos que para jugarlos adecuadamente había que salirse del Windows. Pues correrlos desde dentro de este sistema, aunque era posible disminuían severamente su desempeño. La razón de esto era el Modo Virtual 86

Modo Virtual 86

Las computadoras de 32 bits (no recuerdo de momento a partir de que CPU) tenían una modalidad interesante de operación llamada Virtual 86 Mode, en que podían imitar no solo uno, sino a una multitud de sistemas de 16 bits y ejecutarlos como una subtarea independiente. De este modo era posible correr al mismo tiempo varias instancias del DOS con sus respectivas aplicaciones sin por ello salirse del Modo Protegido. Esto le dio mucha vida artificial a estas viejas aplicaciones aún a pesar de que hacía mucho tiempo que los CPU’s 8086 habían dejado de fabricarse. Sin embargo, cuando una aplicación de Modo Real trataba de inicializar el Modo Protegido desde el Modo Virtual 86 pasaban errores muy feos, como el Famosísimo Fallo de protección General, Ejecución de instrucciones privilegiadas, fallos de página y otras cosas peores cuya única solución casi siempre era un reset de la computadora completa. Eso sin mencionar que aunque esto no ocurrirera, uno solo tenía acceso a una minúscula fracción del poder de procesamiento y memoria del sistema. Por lo que las aplicaciones de 16 bits ejecutadas en el Modo Virtual 86 rara vez daban buenos resultados. Aunque siempre estaba la opción de reiniciar la computadora en modo MS-DOS.

¿Qué estaba haciendo Bill Gates mientras tanto?

Resulta que en su diseño original, Windows no estaba preparado para suministrar lo necesario para hacer buenos juegos. Su GDI (Graphics Device Interface) estaba pensada con la seguridad en mente y no en el alto desempeño que los juegos requieren. Por lo que, y esto lo leí en viejos libros de historia, intentaron hacer una biblioteca de funciones de 32 bits desde al menos el windows 3.1. Dicha mejora era conocida como WinG pero no tuvo la aceptación esperada y los buenos juegos siguieron corriendo en Modo Protegido desde MS-DOS con ayuda de los Dos Extenders. Sin embargo, un poco mas adelante, Bill Gates finalmente aceptó que la única manera de lograr que los buenos juegos fueran desarrollados para Windows era dándo un acceso mucho mas DIRECT-o al hardware.

Inicios del DirectX.

Antes de entrar en detalle, hay que explicar primero el concepto de Overhead. Como en su origen las computadoras personales tenían muy pocos componentes realmente estandar aparte de un CPU Intel o compatible, era muy común crear capaz de delegación intermedia para facilitar la comunicación entre los dispositivos mas dispares sin cambiar los códigos originales. Por ejemplo, en tiempos del DOS, si uno quería escribir un pixel en pantalla primero tenía que llamar una función de la biblioteca de gráficos de C llamaba BGI(o cualquier otra biblioteca de gráficos) llamada putpixel(); que recibía las coordenadas X, Y y el color. Esta a su vez llamaba al sistema operativo para dar la órden de pintar el pixel, luego el sistema operativo llamaba al BIOS que ejecutaba la interrupción 10h y luego de hacer una complicada y tardada serie de validaciones al fin escribía el mentado puntito de color en la pantalla. Este proceso era tan lento que uno podía hacer un ciclo anidado para pintar la pantalla y podía ver como esta cambiaba de color lentamente. ¡Y pintar una pantalla completa de 320 por 200 tardaba casi un minuto!. Sin embargo, con ensamblador bastaba con conocer la posición de la RAM de Video y escribir un pixel era tan rápido como mover un byte a una posición de memoria. Eso sin contar que existían muchos recursos para manejar la tarjeta de video para hacer animaciones rápidas (de momento recuerdo por lo menos tres). El asunto era como dar acceso a los programadores a esta velocidad sin necesidad de salir del Windows. Y fue así como nació DirectX

Como su nombre lo indica, la idea original tras el DirectX era darle a los programadores el acceso mas directo posible al Hardware sin comprometer la protección de memoria del propio Windows. Mientras que intentaban ahogar los problemas de compatibilidad de hardware con capas de abstracción y emulación de hardware. Al principio DirectX fue un fracaso, pero no tanto porque fuera una mala idea, sino porque la mayor parte de los recursos del sistema estaban siendo usadas por el resto de las aplicaciones. No fue sino hasta la aparición del DirectX 5 que se empezaron a ver juegos para Windows mas o menos decentes. En ese entonces, los juegos de 32 bits soportados en los DOS Extenders ya comenzaban a oler a muerto.

C:\RUN\DOS\RUN>

Los vaqueros del viejo oeste solían decir que no había mejor indio que el indio muerto, y yo digo que el mejor de todos los Windows fue el Windows 98 SE, pues permitía explotar un sistema Pentium III a plena capacidad con todo y sus puertos USB en menos de 30 megas. Además de ser muy estable y ser el último que tenía la opción de reiniciar en Modo MS-DOS. Con un sistema como este fue que mi grupo de desarrolladores renegados aprendimos una buena cantidad de cosas sobre computación. Sin embargo. Sin embargo, con la llegada del temido Windows NT y sus derivados a las computadoras caseras, esta maravillosa era terminó. No mas juegos de 32 bits que tomaban el control absoluto del sistema. De hecho, en esa época, mientras jugaba el juego Hexen en una PC Pentium III con Windows ME apareció una pantalla sobre un error en algo llamado WinOldAp. De acuerdo con una poca de investigación, Winoldap era un servicio del sistema operativo que permitía correr aplicaciones de la época descrita en la entrada anterior “Revolución de 32 Bits” en este caso me enteré de que estaba muerto hasta que el mismo Windows me lo había informado.

…llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras…

Por cierto, y hablando del Windows ME, fue a partir de esta versión del sistema operativo de Micro$oft que la feliz armonía entre el Windows y los programadores de juegos que usaban Dos Extenders (o que entraban al modo protegido por su cuenta) se acabó. A partir del Windows 2000 y el ME ya no había manera de salirse del Windows y tomar el control absoluto del sistema como antes. Recuerdo que hubo una pequeña guerra entre mi grupo de amigos programadores por que sistema instalar en nuestras computadoras. Pues un sistema posterior al Windows 98 no nos permitía programar como lo habíamos hecho hasta entonces. Y la peor parte es que todas las herramientas para desarrollo en Windows eran inadmisibles dados nuestros métodos de trabajo. Llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras por lo que, como abandonar la programación en ASM no era una opción decidimos hacer lo mejor que se nos ocurrió: ¡Programar en Ensamblador para otras plataformas! Aunque eso significara crear la nuestra propia.

Y en ese entonces fue cuando se dio nuestro destierro de la programación en Ensamblador para computadoras caseras. Aunque en ese tiempo hicimos muchos avances en otras áreas relacionadas con el Ensamblador que se mencionarán en la siguiente entrada. Pero eso no nos salvó de experiencias terribles que poco a poco fueron debilitando al equipo aunque sin llegar a acabar con él por completo.

En la siguiente entrada se contará de que fue de la programación en Ensamblador (o al menos la parte que me tocó vivir) durante los primeros años del presente siglo y como gracias a los esfuerzos de grandes hackers como Iczelion y otros cuyos seudónimos no alcanzo a recordar los programadores de Ensamblador pudimos regresar a la escena de la computación casera de la que alguna vez nos sentimos desterrados. Pero entre ese tiempo, muchos de nosotros nos convertimos en poco menos que vagabundos y esos oscuros años son los que se narrarán mas adelante.

Revolución de 32 Bits

–Y la Lenta Muerte de los Sistemas de 16 Bits–

Quienes han entrado a la Red Social de Programadores de Ensamblador de seguro han leido los escritos de b1ackpig sobre el formato PE. Para quienes no sepan de que hablo, PE o Portable Executable es el formato de los programas de aplicación del Windows. En esos documentos se hace referencia a un importante evento histórico ocurrido en la década de los noventas: “La Transición del DOS al Windows”. Aunque detrás de todo esto se hallaba la verdadera transición de la programación de 16 a 32 bits. Veamos primero un poco de historia…

Desde que Intel inventó el procesador 8086 e IBM lo adoptara para construir su famosa IBM-PC, la tecnología de los 16 bits era el estandar de las computadoras de sobremesa, en esos tiempos los sistemas de 8 bits eran poco menos que consolas de videojuegos y los de 32 bits solo podían hallarse en costosas computadoras dedicadas a la investigación. Sin embargo, todo cambió alrededor de 1985 cuando Intel desarrolló el procesador 80386. Esta paqueña maravilla era capaz de hacer todo lo que en su tiempo solo podían hacer las grandes computadoras de los centros de investigación. Sin embargo, dado que era un procesador muy avanzado no había una plataforma de hardware que lo aprovechara a su pleno potencial y de haberse construido hubiera sido sumamente costosa. Como muestra, la primera computadora de escritorio equipada con este CPU llegó a costar ¡10,000 DOLARES!

Debido a esto, no fue sino hasta los últimos años de la década de los ochentas que las computadoras para civiles con CPU’s de 32 bits llegaron al mercado de masas. Sin embargo, al igual que el 286 que bien podría considerarse un mal prototipo del 386 (modo protegido de 24 bits, registros de 16 y problemas de compatibilidad hacia atrás), estas poderosas computadoras de 32 bits seguían siendo programadas como el viejo 8086. Mas adelante, con la llegada del 486 de Intel comenzaron a verse algunos sistemas que rebasaban el megabyte en RAM. Y entonces fue cuando realmente comenzó la guerra por la optimización.

Si ustedes tienen o superan los treinta, de seguro recordarán una época en que había juegos(sobre todo de Lucasarts) cuyo ejecutable media alrededor de 500 kbytes y que al tratar de correrlos en una 486 con 4 megabytes en RAM, aparecía un mensaje que decía “NOT ENOUGH MEMORY”. ¿Como era posible que una PC recien iniciada con 4 mbytes en RAM no pudiera correr un pinchurriento jueguito que no medía mas de medio mega? La razón de esto era porque estos programas estaban hechos para correr en Modo Real.

Modo Real

Este era el modo de operación por defecto del antiguo CPU 8086. En el se tenían registros de 16 bits, se usaban 20 bits para manejar la memoria. Con 20 bits es posible tener control sobre apenas un megabyte en RAM que son aproximadamente 1,048,576 bytes (100000h en hexadecimal). De estos pocos mas del millón de bytes, solo 640kbytes estaban a disposición de los programas. El resto pertenecía a la memoria de video, llamadas al sistema operativo, vectores de interrupción y hasta unos ROMS fosilizados que estaban ahí desde los tiempos del CP/M (el antepasado no reconocido del DOS). Además, de esos 640 kbytes, ya algunos estaban ocupados por servicios del sistema operativo. De hecho, y nada mas para insultar, este es el ensamblador que aún en este siglo XXI se imparte en buena parte de las carreras universitarias de Ingeniería en Computacion. La pregunta era: ¿Donde estaban los programadores capaces de entrar al Modo Protegido?

En realidad ya existían programas de 32 bits para computadoras personales desde fines de los años ochenta para computadoras basadas en CPU’s 386 o superiores. Un ejemplo era el no tan famoso sistema operativo OS/2 de IBM del cual se dice Bill Gates robó todo lo que no pudo encontrar en la GUI de las computadoras de Apple. La razón por la que el OS/2 no tuvo el éxito esperado era porque no tenía suficiente compatibilidad hacia atrás con el software existente de 16 bits que corría en la inmensa mayoría de las computadoras personales con DOS y las primeras versiones del Windows de 16 bits.

Primeros juegos de 32 bits para PC

Ya entrados los noventas, cuando el estandar eran las PC con CPU 486, DOS y Windows 3.1 ocurrió un fenómeno muy interesante: ¡Aparecieron juegos que rompieron la barrera del mega en memoria! La razón era sencilla. Los programadores habían descubierto la manera de entrar al Modo Protegido desde el DOS. Con esto tenían acceso a toda la memoria del sistema y a los registros de 32 bits. Los mas experimentados entraban por ellos mismos pero también había algo llamado DPMI (Dos Protected Memory Interface) que permitía tener acceso al direccionamiento de memoria de 32 bits desde una “sencilla” aplicación en DOS. Lo de sencilla lo pongo entre comillas porque no era nada facil de hacer. Y como han de imaginarse, los primeros que abandonaron el primer Megabyte de RAM fueron precisamente los que sabían programar en Lenguaje Ensamblador.

Mas adelante apareció un compilador que no solo trabajaba en 32 bits. ¡Sino que además era de uso libre! Llamado DJGPP. Gracias a este compilador y a DPMI’s como el famoso DOS4GW surgieron las grandes leyendas de los juegos de PC de mediados de la década de los noventas. Aunque aún era necesario saber algo de Ensamblador para acelerar algunas rutinas gráficas y mantener la memoria bajo control. De hecho, esta pantalla de advertencia era la que nos decía que el juego a cuyo ícono habíamos hecho doble click iba a ser genial:

Y esta era fue precisamente la que nos tocó a mis amigos y a mi. Los tiempos de las primeras computadoras con un CPU Pentium con FPU integrada, las primeras versiones del Windows 95, las conexiones telefónicas a Internet facturadas por hora y la fiebre de los First Person Shooters. Poco antes de que el Software Libre se pusiera de moda y la única manera de hacer trabajar una PC armada con componentes chinos era instalando copias piratas del Windows que circulaban en cajas de Floppies de 3.5 pulgadas. Y la herramienta mas avanzada de desarrollo de software era el Borland Turbo C++ 3.0 (cuya licencia costaba 500 dólares mas impuestos en tiendas especializadas de informática). En ese entonces intentamos hacer juegos programados en C/C++; pero pronto llegamos al límite del compilador, pues al ser un compilador de 16 bits para DOS no nos permitía manejar mas de un megabyte de memoria ni era facil escribir a la memoria de video. A la fecha no se me olvida lo complicado que era hacer un frame buffer usando las funciones de memoria malloc( ) y free ( ). O new( ) y delete ( ) en C++ o modificar la tabla de los vectores de interrupción para el teclado y el reloj interno del sistema sin que el sistema completo se hiciera porquería. Por estas razones, pero sobre todo por la de manejar una mayor cantidad de memoria es que se decidió que había que programar en ensamblador.

Al principio hacíamos programas en C y compilábamos por separado rutinas de Ensamblador que era posible llamar desde C cual si se tratara de funciones de la biblioteca estandar; al principio esto funcionó bastante bien pues teníamos la “facilidad” de programar en C/C++ combinada con la velocidad y control de las rutinas de Ensamblador. Hasta que notamos que los códigos fuente lo único que conservaban de lenguaje C era solo el main( ) y las { }. ¡Todo lo demás eran puras llamadas a rutinas hechas en Ensamblador! Así que decidimos que era el momento de quitarle las ruedas de entrenamiento a las bicicletas y programar todo en Ensamblador de una vez por todas. ¡Los resultados fueron sorprendentes! Pues programas completos que medían alrededor de 200 kilobytes en C, en ensamblador no ocupaban ni la centésima parte de eso y los errores de desbordamiento y tipo de datos eran rarísimos. En ese entonces trabajábamos con la misma copia pirata del Borland Turbo Assembler que aún circula en muchas universidades de países de centro y sudamérica. Y como ya han de imaginarse, este ensamblador aunque ya podía trabajar en 32 bits no estaba preparado para los grandes avances que se veían venir como por ejemplo la tecnología de Intel MMX. Y aunque es posible programar en ceros y unos (y llegamos a hacerlo) esto era demasiado tardado. Por lo que nuestro siguiente gran reto fue programar nuestro propio compilador de Ensamblador.

Sin embargo, durante la extensa investigación sobre como hacer un compilador propio (y verdadera investigación, no las jaladas sobre “teoría de autómatas” que tanto han desprestigiado las universidades chafas) el buen b1ackpig dio con un interesante descubrimiento: el FASM.

El FASM o Flat Assembler es el mejor compilador de ensamblador que he encontrado y es el que he estado usando hasta el día de hoy. Pues tiene casi todo lo que un programador puede necesitar: (Es libre, posee muchas herramientas, casi no consume recursos, se actualiza muy rápido y tiene muy buena documentación) Hablar de las maravillas del FASM merece su propia entrada en este blog. Sin mencionar que el paquete incluía su propio código fuente en Ensamblador. Yo personalmente aprendí mucho leyendolo. En fin, en esa segunda mitad de la década de los noventas, b1ackpig, el Julio y yo teníamos a la computadora lo suficientemente dominada para programar un verdadero juego de video. Solo faltaba un poco de Programación Gráfica, que en nuestro caso se resumía a simple álgebra lineal y geometría diferencial de libro de texto para hacer verdaderos juegos 3D.

Pero a finales de la década de los noventa ocurrieron unos cambios radicales en el mundo de la computación que nos metieron en serias dificultades; eso mas unos serios errores tácticos que cometí relacionado con la programación gráfica en Windows que retrasaron nuestras investigaciones por años. Eso sin contar que por ese tiempo fue cuando me expulsaron de la universidad. Pero eso es una historia que será contada en la siguiente entrada de este blog.

Mercado de Sueños y Pesadillas

–El Drama de los Artistas Digitales–

Acabo de regresar de la Convención de Historietas organizada en Cintermex en Monterrey. A veces pienso que si llego a desarrollar algo que valga la pena este tipo de eventos son el mejor lugar para mostrarlo. Pero antes de decir todo lo que vi ahí, quiero contarles una pequeña historia acontecida uno o dos años antes de que tomara la decisión de convertirme en programador de Lenguaje Ensamblador…

Primero, tengo que declarar que si hubiera nacido en una era donde no existieran las computadoras, definitivamente me habría convertido en escritor. De hecho soy hijo de un cierto novelista frustrado y tengo algunos primos del lado paterno (uno de las cuales niega su propio apellido) que han escrito unos cuantos ensayos y raquíticos libros de poemas. Sin embargo, la razón por la que no quise ser escritor es que en latinoamérica todos los intelectuales están metidos en política y viven hablando mal del mismo gobierno que les da becas y programas para el “fomento de la cultura” para que no se mueran de hambre. Sin mencionar que la mayor cantidad de dichos libros son puros escritos intelectualoides que nada mas leen los mismos 3 o 4 ancianos hipiescos de siempre y el resto no son mas que panfletos de superación personal con mensajes culpígenos y pseudo-religiosos. Por eso decidí que el mejor medio para contar mis historias era a traves de un buen juego de video y el mejor lenguaje para esto es el Ensamblador.

Mi (no muy buena) experiencia en el mundo del Comic

Bueno, tras este preámbulo ahora va la historia: Resulta que en mis años de preparatoria yo realmente quería ser escritor; pero por lo contado arriba decidí buscar una opción mucho mas comercial. Un amigo de aquel entonces tenía una hermana que era entintadora en un grupo que hacía historietas y fue por medio de este contacto que me acerqué a ese mundo. En esos tiempos fui a las primeras convenciones de juegos de mesa y comics organizadas en Cintermex. En ese ambiente vi lo típico a lo que se enfrenta la gente que se dedica al ‘arte comercial’. Peleas con los editores, discusiones por los recursos económicos; divisiones por ideas y lo mas divertido de todo, las peleas con dibujantes rivales.

Que puedo decir, creo que el mejor término que puedo usar para designar a estos artistas es el de dibujantes, pues era lo que mejor hacían. Aunque uno de ellos era guionista-escritor. De hecho solo éramos 2 escritores y yo no pasé de corregir faltas de ortografía de un par de cuartillas. Y aunque era un grupo mas o menos numeroso, yo solo recuerdo haber tratado con tres de estos artistas de manera mas o menos constante: he aquí algunos de ellos y escribo sus nombres por si alguien los conoce…

Francisco Pineda: Dibujante de aspecto reservado y con fuertes influencias de los comics japoneses. A pesar de ser uno de los artistas mas importantes de aquella organización (y quien mas me inculcó el odio hacia cierto dibujante rival) no supe que fue de su carrera artística. Lo último que escuché de él es que entró a trabajar en Agua y Drenaje de Monterrey y no precisamente dibujando los promos publicitarios. Se dice que su novia (de entonces), quien también era dibujante, si logró publicar un par de tiras en uno de los periódicos locales y a la fecha, por una búsqueda que hice en el google, parece que da clases de dibujo en una pequeña escuela de arte.

Jose Luis “Abril”: Este era el típico artista intelectual de cabello largo y caracter dificil. Otro buen dibujante que se decía era hijo de un pintor al que por mi escasa preparación intelectual no conozco su obra (aunque llegué a estar parado en medio de su estudio). Este era el mas interesado en hacer arte para videojuegos y estába en pláticas con él para integrarlo en un grupo de desarrollo de videojuegos hasta que en una reunión uno de mis secuaces (el Julio) se emborrachó e hizo un pleito memorable en casa de su inestable novia. Por no contar el “Incidente Rococó” del que el propio Julio puede hablarnos en los comentarios. Por cierto, me encontré a este artista en una convención de historietas posterior a ese incidente. Ya había cambiado de novia y veía el asunto como un incómodo recuerdo. Me pregunto si aún se dedicará a dibujar o ya habrá tomado un trabajo de adulto responsable.

Arturo Vega: Un mulato de considerable estatura y tono de voz tan alegre como imponente. Este era el otro escritor y por cosas que me contó parece que si llegó a elaborar el argumento de un par de revistas de historietas. Vagamente recuerdo una historia de un esgrimista greñudo, un nerd que se había condenado al infierno por ver no se que cosas y una rubia cuyo nombre era un juego de palabras medio gótico. Decía sentirse un poco relegado por los dibujantes. Lo último que supe de él fue que formó una familia e intentó incursionar en la animación digital. Por cierto, en cierta época hubo un programa de radio de historias de terror escritas por aficionados y se rumoreaba que los mejores relatos de ese programa había sido escritos por él usando un seudónimo.

Ahora vamos a pasar a la parte de las peleas. Todos los que nos dedicamos a crear algo artístico tenemos un Némesis, que puede ser un artista o programador con el que queremos medir fuerzas o simplemente alguien que no nos agrada porque llama mas la atención de los medios que nosotros. En el caso de estos dibujantes, dicho personaje era un artista regiomontano que se había hecho famoso por su habilidad para dibujar patos. Y aunque su producto era de una calidad bastante superior a lo que normalmente se podía encontrar en los puestos de historietas del norte de México su estilo gráfico no acababa de gustarme. No vale la pena mencionar el nombre porque luego los buscadores pueden dar con este sitio. Pero este personaje era autor de declaraciones a los medios tan humildes como “Soy demasiado profesional para trabajar en México”. Hoy en día este ser entró a trabajar de colorista a una de esas granjas de dibujantes que tienen algunos estudios norteamericanos; pero lo que les dice los frikis mexicanos es que dibuja el solo los mejores comics de Marvel sentado en las rodillas del mismísimo Stan Lee. Creo que con este pequeño dato muchos de los que asistieron a la convención de Historietas de Cintermex en Monterrey ya sabrán de quién estoy hablando.

Por cierto, husmeando en una cierta página de internet bien conocida por dibujantes de todos los niveles y presupuestos, encontré una nota de uno de los artistas que fue a la convención. Era un poco triste ver como invitaba a los alumnos de su escuela de arte a ir a condición de que le ayudaran a pagar la renta de la mesa en el evento. La verdad es que es lamentable ver a artistas tan talentosos pasar por ese tipo de humillaciones. A veces pienso que las empresas desarrolladoras de videojuegos (en Monterrey hay 2 de ellas legalmente consolidadas pero de las dos no se hace una) podrían encontrar buenos diseñadores en esta clase de eventos, pues son artistas jóvenes con experiencia en las artes digitales. Parece mentira que al otro lado del mundo empresas de videojuegos gasten grandes sumas en contratar estudios de animación para que les diseñen sus personajes mientras que en latinoamérica hay una enorme cantidad de artistas talentosos dispuestos a vender sus obras por comida.

En fin, esa fue la triste historia de un grupo de dibujantes de historieta cuyo destino no estoy muy seguro de conocer. Y el mundo de la programación de videojuegos no es demasiado diferente de esto, salvo por el hecho de que los buenos programadores de juegos son mucho menos numerosos que los buenos artistas al menos en latinoamérica. Hasta ahora no me ha tocado ver a un solo grupo de desarrollo de juegos pasar por este tipo de penurias. ¿O será acaso que como casi no hay programadores de juegos no me ha tocado ver estas escenas?

Arte para videojuegos a precios accesibles

Por cierto, lo único de valor real para este blog que hice durante toda la proyección fue preguntarle a un artista de doblajes proveniente de Chile sobre si los estudios de doblaje se alquilan para dar voces a personajes de videojuegos. La respuesta me sorprendió, pues me dijo que no solo hay actores profesionales que prestan su voz para doblar juegos ya hechos a otros idiomas; sino que hay una gran cantidad de ‘estudios’ donde experimentados ‘voice actors’ hacen voces para juegos y animaciones nuevas. ¡Y por menos de lo que cuesta contratar a un estudio de doblajes serio! No voy a entrar en la pelea sobre si el doblaje Mexicano es mejor que el de los otros países pero también el mas caro. La verdad es que una de mis preocupaciones a la hora de desarrollar videojuegos era la del costo de contratar actores profesionales para grabación de voces y captura de movimiento. Pero si esto sigue así, puede que estos estudios sean la clave para que pequeñas empresas desarrolladoras de videojuegos puedan producir juegos con arte de buena calidad a un precio razonable para todos. Por una parte me da tristeza ver que cada vez es mas dificil que un buen artista tenga buenos ingresos; pero por otra parte no deja de alegrarme el hecho de que gracias a esto ahora hay acceso a artistas PAGABLES. Y supongo que eso también es bueno para ellos al ver ampliada su cartera de clientes.

Me pregunto si en Guadalajara o el Distrito Federal las empresas de desarrollo de videojuegos se presentan en las convenciones de Historietas o solo van a los eventos organizados por ellos mismos y los que solo van ellos y uno que otro grupo de escolares despistados enviados por sus institutos. Sea como sea, esto ya se tardó. Lo que me tranquiliza es que gracias a este blog mis proyectos ya no son delirios solitarios y realmente hay gente interesada en esta clase de desarrollos. Supongo que ahora debería de hablar de una psicosis colectiva. Por cierto, en la comunidad de programadores de ASM ya somos 9. Aunque aún le falta bastante para crecer; espero que para este nuevo año podamos hacer algo que realmente valga la pena. Por ahora es mejor programar porque a como van las cosas yo también voy a acabar de maestro en alguna escuela de programación y, si es que llego a hacer un juego, también voy a tener que pedir cooperación a mis alumnos para que me ayuden a pagar una mesa en algún evento de videojuegos.

¡Un Año de asm86.wordpress.com!

–Doce meses de programación en Lenguaje Ensamblador–

 

Pues como bien nos ha recordado b1ackpig, en este mes de noviembre del 2009 se cumple el primer año de operaciones de esta especie de blog. Aun recuerdo aquellos dias de noviembre de 2008 cuando decidí que no quería dejar morir este poderoso lenguaje. Y porque al no poder regresar en el tiempo para enseñarme a mi mismo a programar en él, quise hacer aquella página de Internet que me hubiera gustado encontrar en esos ahora tan lejanos años en los que comenzaba a programar, en espera de que otros que apenas comienzan su camino sepan al menos que hacer.

Debo de admitir que al principio no esperaba tener demasiados lectores, (hoy tengo poco mas de 100 hits únicos por día y en ciertas fechas rebasa los 240) y no me interesa demasiado tenerlos. Pues la programación en Ensamblador no es algo que se considere popular. Pero como lo contrario a lo popular es lo elitista, se que quienes leen las estupideces que escribo aquí con cierta regularidad se cuentan entre los mejores programadores, o al menos les interesa llegar a serlo algún día. No dudo que entre quienes leen esto se encuentren varios programadores mucho mejores que yo, y espero que pronto comenten para aprender de ustedes. Pero bueno, ahora que releo las entradas mas antiguas me doy cuenta de que se pueden dividir en estas categorías:

• 1.- Tutoriales para principiantes
• 2.- Peleas con lamers
• 3.- Temas mas o menos avanzados que no llevan a ninguna parte
• 4.- Notas sobre el Desarrollo de Videojuegos (y su relación con el ASM)

Además de una buena cantidad de violencia gratuita y algunos enlaces a otros recursos de programación mas o menos valiosos. Y por consejo del buen b1ackpig, he pensado en hacer una recopilación de varias notas (si no es que de todas) en un PDF, pero sería mas que un Copy-Paste. Pues ahora que tengo mas de 100 entradas con sus casi 300 comentarios ya puedo hacer algo que valga la pena. Ese PDF se dividiría en 4 partes, la principal sería un manual de programación en Ensamblador, la otra serían los temas sobre ensamblador que son demasiado avanzados para un simple tutorial o que no se detallan lo suficiente para explicarlos. Y la tercera sería la sección que bien podría llamarse “Ahora a insultar” y abarcaría todas las notas sobre las peleas con lamers y demás peripecias y batallas épicas libradas en este blog. El tema del desarrollo de videojuegos en realidad quedaría repartido en estas 3 primeras secciones (tutoriales detallados, temas a discusión y desde luego las épicas peleas con otros autodenominados “profesionales de la industria” de los videojuegos que me he topado en internet). Por último, la cuarta parte sería el verdadero contenido original del libro. Y ahí escribiría todo lo que no se hubiera dicho en los 3 capítulos pasados.

Si esto va bien, podría hacerse cada año no solo para festejar sino a modo de recopilación mas o menos usable. Pero esto, si es que se llega a hacer va tomar un tiempo y saldrá hasta ya entrado el mes de diciembre de este 2009.

Ahora la cosa es discutir un poco sobre el futuro: pues ya este proyecto comienza a tomar forma. He pensado en muchas cosas, una de ellas es la de hacer un podcast para que aquellos que por cualquier razón no pueden estar demasiado tiempo frente a la pantalla puedan seguir informándose sobre la programación en Ensamblador. Otra cosa que me urge hacer es comenzar el tema de la programación gráfica en Ensamblador, pues recientemente me he topado a un par de “Investigadores” del tema que la verdad… bueno, por ahora estoy de muy buen humor como para ponerme a insultar. Pero como ustedes ya saben una de las cosas que mas me enfurecen de esto de la programación es que gente que no sabe hacer otra cosa que scripts para un engine o llamadas a una API reciba trato de “Profesionales de la Industria” mientras que otros que genuinamente les interesa programar tienen que dejar de hacerlo y acaban administrando bases de datos por comida. Lo bueno es que a la par que este blog, la gente que lo visita ha cambiado mucho, ya casi no vienen lamers y quienes comentan dicen cosas cada vez mas sensatas e interesantes para todos los otros que les interesa programar en ensamblador.

Una cosa que si quiero hacer es poder reunir a todos los programadores de Ensamblador que pueda sean jóvenes aficionados que apenas comienzan o viejos hackers locos que no quieren tirar su 486, y trabajar todos juntos en algunos proyectos que solo en ensamblador pueden hacerse a un nivel respetable. Por ejempo gráficos en tiempo-real, desarrollo de juegos de última generación o cualquier cosa de ese mismo calibre. Como ya han de imaginarse mis fines no son nada pacíficos, en realidad quiero formar un equipo para jugar algunos “partidos amistosos” con otros grupos de “desarrolladores” con los que quiero medir fuerzas. Pues lo mejor que me ha dado este blog es que me ha mostrado que no estoy solo en esto de la programación en ensamblador y que ahí afuera hay otros, no muchos, que se sienten igual. Estoy seguro de que si nos organizamos y trabajamos juntos podremos crear grandes proyectos que puedan desafiar tecnológica y económicamente a los autodenominados “profesionales”. No estoy muy seguro en otros países; pero al menos en México y buena parte de latinoamérica hasta ahora no ha aparecido ninguno de estos que pueda competir contra un grupo de buenos programadores de Ensamblador bien organizados. Estoy seguro de que si trabajamos juntos podremos hacer grandes cosas, y por grandes cosas quiero decir grandes cosas a nivel económico.

No va a ser nada facil; pero programar en Ensamblador tampoco lo es. Vienen cosas impresionantes; pero también tiempos difíciles que van a requerir un gran esfuerzo para quien quiera participar. Pero por ahora festejemos y procedamos a comernos este pastel que espero realmente sea de chocolate.

Modo Protegido

–O el Hotel de los OpCodes Rotos–

 

Una de las cosas mas importantes que tienen los nuevos sistemas operativos respecto a los antiguos es la capacidad de hacer que muchas aplicaciones trabajen de manera simultanea en computadoras que tienen un solo CPU. En otra nota hablaré sobre como demonios hace el sistema para hacer esto; pero ahora quiero responder a una pregunta mucho mas interesante: ¿Como demonios le hace el sistema para que miles de programas corran de manera simultanea sin hacerse porquería unos a otros? La respuesta es precisamente en lo que Intel ha dado en llamar el Modo Protegido.

¿Y que demonios es el Modo Protegido? Se trata de un mecanismo de seguridad jerárquica mas o menos complejo implementado en el propio CPU. Gracias a él es no solo es posible correr muchos programas simultaneamente, sino además de que se logra que cada uno se comporte como si tuviera toda la computadora para él solo. Este sistema se basa en cuatro niveles de prioridad que a menudo se representan como anillos concéntricos donde quien está mas al centro tiene poder sobre los que están mas a la periferia. Pero como esto me parece muy complejo y aburrido como para explicarse en este blog voy a hacer una analogía mas comprensible para (muy pocos de) ustedes: Un Hotel

Un hotel es el perfecto simil de un sistema operativo que corre en Modo Protegido como lo hacen Windows y Linux en su versión x86. Pues en ambos se tiene a un montón de gente (los programas) cohabitando en un mismo espacio mas o menos grande. En el lugar mas bajo de la jerarquía tenemos las habitaciones de los huéspedes. Se supone que cada huesped puede usar una habitación por la cual pagó y nadie puede entrar a una habitación que no sea la suya, al menos no sin el consentimiento de quien está adentro. Cuando la habitación se desocupa esta puede ser usada por alguien mas sin afectar por ello la vida en el resto del hotel. En un sistema en Modo Protegido, una aplicación que es cargada recibe un espacio dentro de la memoria y tiene acceso (o eso es lo que ella cree) a muchos recursos comenzando por un espacio de memoria exclusivo que ninguna otra de las aplicaciones puede leer o escribir (salvo por un error en la función VirtualProtectEx pero eso es otro show). En caso de que una de estas aplicaciones termine su ejecución o peor aún falle y deje de funcionar el sistema no se ve afectado por ello.

En el siguiente nivel de esta jerarquía están los servicios comunes como el comedor, la piscina (eso si la piscina no está cerrada),el gimnasio o cualquier otra area similar. Los huéspedes pueden hacer uso de estos recursos ya sea turnándose o reservando un lugar con anticipación. De este modo, aunque se tenga únicamente una piscina (y si no está cerrada) todos pueden ir a nadar sin temor a que nadie se apodere de esta para él solo. En el Modo Protegido es igual. Todas las aplicaciones pueden hacer uso de los recursos del hardware como discos, pantalla, puertos de comunicaciones o archivos pero para hacerlo tienen que pedir permiso al sistema. Ninguna aplicación puede acceder de manera directa a estos recursos sin desencadenar el temible Fallo de Protección General. Pero puede hacer uso de los servicios de los controladores o Drivers para beneficiarse de esos recursos. Pasando de nuevo a la analogía del hotel, los empleados que dan acceso a estas instalaciones son los controladores de dispositivo.

El segundo nivel mas alto de la jerarquía dentro del hotel lo tiene el personal e instalaciones de mantenimiento. Inmediatamente arriba del personal que da acceso a las instalaciones comunes tenemos al resto del personal del hotel. Entre los que destacan el personal de limpieza, los que asignan las habitaciones a los nuevos huéspedes, los encargados de hacer reparaciones cuando algo se descompone y en general todos aquellos que mantienen el hotel de una sola pieza. Como ya se sabe el personal de mantenimiento tiene acceso a casi todas las areas del hotel como por ejemplo las habitaciones de los huéspedes a los que entran para limpiarlas de vez en cuando. Sin embargo los huéspedes no pueden entrar a instalaciones tales como las oficinas administrativas, las áreas tras los mostradores, la cocina del hotel o al cuarto de máquinas de la piscina (en el caso de que la piscina no esté cerrada). En el Modo Protegido este nivel corresponde a los mas importantes servicios de sistema como por ejemplo el control de la Memoria Virtual, la asignación de espacios dentro de la memoria física, la conectividad de red, el control de ejecución y cambios en el modo de operación, o el manejo de errores y excepciones. Dependiendo de la complejidad del sistema esta parte puede corresponder al nucleo del sistema operativo o estar fuera pero trabajar de modo estrecho con este.

En el nivel mas alto de la jerarquía está el dueño del hotel, el típico gordo sudoroso y sin camisa que se pasa el día espiando a los huéspedes a traves de un complejo sistema de cámaras ocultas tras los espejos de los baños y en las lámparas de techo. Este ser maneja el hotel completo desde su silla mantecosa y decide (dependiendo de lo que ve con sus cámaras) cosas como por ejemplo quién se queda o se va del hotel, se encarga de vigilar de las instalaciones funcionen correctamente y de no ser así mandar al personal de mantenimiento a arreglar las cosas. Por ejemplo, si la piscina tiene SIDA, mandar cerrarla. O evitar de que un grupo de huéspedes con cabello afro la cierren. En pocas palabras, el dueño del hotel es quien tiene control absoluto sobre todo y sobre todos. Supongo que no tengo que explicar demasiado su equivalente en el Modo Protegido. En el anillo de protección de mayor jerarquía, también conocido como el Anillo Cero o “Ring 0” es donde se encuentra el nucleo del sistema. Este nucleo se encuentra en lo mas alto del poder respecto al resto del sistema, sino que tiene acceso directo a muchos servicios privilegiados de la propia computadora que solo desde este anillo de protección es posible manejar sin desencadenar un Fallo de Protección General.

Y bien solo queda por contestar una pregunta: ¿Y que pasa si alguien desobedece estas leyes de protección? La respuesta es el temible General Protection Fault.

General Protection Fault (Fallo de Protección General)

Uno de los errores mas comunes en la era del Windows 95 esa el famosísimo General Protection Fault. Este ocurría cuando una aplicación intentaba invadir un espacio de memoria que no era el suyo o cuando ejecutaba una instrucción de CPU que estaba por encima de su nivel de privilegios. Cuando el Procesador detectaba esta situación generaba la “Exception 0D General Protection Fault”. No se si será coincidencia pero a esta excepción le corresponde el número de mala suerte por excelencia en el mundo occidental, el 13. A grandes rasgos, una “Exception” es un código que se dispara cuando el CPU detecta una condicón peligrosa determinada de antemano. Se supone que en un sistema bien hecho una excepción es como una alarma contra incendios que detecta el fuego y activa los aspersores automáticos para apagarlo y una vez hecho esto regresar a la ejecución normal. Pero en los tiempos del viejo Windows 95 la única manera de salir de una General Protection Exception era reiniciando la computadora.

Otra nota curiosa es la de porqué son exactamente 4 niveles de protección dentro del Modo Protegido. Al parecer 4 era la potencia de 2 mas cercana al 3, pues como todo jefe sabe para manejar a la burocracia se necesitan cuando menos 3 niveles en la jerarquía, donde el mal alto corresponde al jefe y el mas bajo a los que hacen el trabajo manual. El nivel intermedio existe para delegar responsabilidades y encontrar culpables cuando algo falla. De hecho se dice, aunque no lo he comprobado por flojera, que las primeras versiones de Windows de 32 bits solo usaban 2 niveles de seguridad, el mas alto para el nucleo del sistema operativo y el mas bajo para las aplicaciones y que además usaban todos los descriptores de segmento inicializados en la posición cero de la memoria y con un límite de 4 Gb.¡En una época en la que las computadoras mas costosas no pasaban de los 64 megabytes en RAM.! Este diseño hacía que se produjeran muchos fallos de protección general, porque los segmentos de código de los diferentes programas en realidad quedaban unos sobre otros. La explicación de lo que es un descriptor de memoria vendrá en otra nota pero antes quiero dejarlos con algo para pensar:

Todos sabemos que los hoteles no solo se usan para hospedar parejitas, sino que a veces se alquilan para eventos especiales como convenciones, presentaciones de productos nuevos, viajes de negocios (este es el uso mas cercano al original) y algunos eventos deportivos o culturales. De hecho, la inmensa mayoría de las personas que leen este blog por gusto, las mas de las veces hemos han estado en un hotel por cuestiones de trabajo las mas de las veces. Bueno, hay quien hace de lo otro un trabajo pero eso ya no es programación. Ahora la pregunta es ¿Qué tal si para alguno de estos eventos se necesita reservar una instalación completa? Como por ejemplo, cerrar la piscina para organizar una competencia de natación, u organizar un banquete exclusivo en el restaurante del hotel o quizas llevar a cabo un concierto o baile en los jardines. O cualquier otra situación donde se necesite acceso DIRECTo a una determinada instalación.

Les dejo de tarea pensar en esto, pues esa es la clave para programar buenos videojuegos en Windows.

Test Your Might!

–¡Quien Crea Saber Programar que lo Demuestre!–

Durante la época de las arcades de inicios de los noventas, particularmente con los juegos de Mortal Kombat, podía verse un interesante fenómeno entre algunos de los jugadores: algunos ocultaban los movimientos de sus manos con su propia ropa. Al principio pensé que lo hacían para evitar que los dedos se les enfriaran en climas invernales pero esto también ocurría en días calurosos. A veces junto con el jugador principal había un “padrino” que se encargaba de cubir los controles con su propio cuerpo en ciertos momentos clave, particularmente a la hora de hacer los “Fatalities”. A la fecha soy incapaz de entender el porqué de esto; pero luego escuché otra historia que tiene mucho que ver con el asunto. Por cierto, la frase “Test Your Might!” viene precisamente del juego de Mortal Kombat.

Hace ya algunos años cierto maestro me contó una interesante historia de algo que a la fecha no se si se trata de un acto de egoismo, mentiras o simples ganas de fastidiar. Según me contó durante los inicios y mediados de los noventas él quiso dar un curso sobre programación gráfica. En esos tiempos el estandar de los juegos era 320 por 200 a 256 colores. El famoso Modo 13h en el que corrían la inmensa mayoría de los juegos de aquellos días tan lejanos. Quien me contó esta historia decía que cada vez que tocaba el tema de la programación gráfica todos los alumnos permanecián en un silencio nervioso. Cuando pregun\te a que creía que se debía esto, esto fue lo que me contestó:

–”Es que la mayoría no sabía de lo que estaba hablando y los que sabían algo no lo querían decir”–.

“¡Y los que sabían no lo querían decir!” Esta frase se me quedó muy grabada al escucharla, aunque por mucho tiempo después me encontré con situaciones parecidas en toda “la industria” de la computación. Ya perdí la cuenta de las veces que me topé con supuestos profesionales que juraban y perjuraban haber trabajado en grandes proyectos informáticos de talla internacional, desde simples administradores de bases de datos que hablaban por horas y horas de certificaciones hasta un gordo que afirmaba haber programado para la NASA (esta historia ocurrió en una plática con el grupo de usuarios de Linux en Monterrey y este personaje era el padre de un pelado que se parecía a Toru Tanaka). Sin embargo, cuando quería preguntarles acerca de su trabajo y sus descubrimientos todos guardaban silencio y se defendían diciendo cosas como que habían firmado contratos NDA que les impedían hablar del asunto u otros que sencillamente me contestaban con “que ( H!N6@D05 te importa”. La verdad es que, con el tiempo descubrí que la inmensa mayoría de esta gente en realidad era incapaz de hacer aquello que afirmaba poder hacer y de los pocos que realmente habían hecho algo, en realidad eran cosas poco menos que insignificantes. La pregunta aquí es ¿Qué es lo que la gente gana con esto?

Entiendo perfectamente que cuando alguien consigue un logro quiera que todo mundo sepa que lo hizo y como. Como los que presumen sus hazañas o sus conquistas en esas noches de juerga. Pero no entiendo porque alguien que quiere llamar la atención sobre algo que afirma haber hecho al mismo tiempo intenta ocultar los detalles sobre el “como” lo logró. No voy a mencionar ningún ejemplo famoso porque no terminaría nunca. Pero sigo yo preguntándome el porqué de esto. Mi simple lógica me dice que alguien orgulloso quiere que todo mundo vea su obra hasta el mas mínimo de los detalles para que todos se admiren de su capacidad y conocimientos. No tiene sentido que alguien así quiera ocultar precisamente este tipo de cosas.

A veces pienso que este “miedo” puede tener 2 razones: la primera es que en realidad quienes intentan ocultar esta clase de información en realidad son farsantes que en realidad no saben programar y la segunda es que tienen miedo de que alguien “les robe la idea”. El primer punto no tengo necesidad de discutirlo; pero el segundo vale la pena dedicarle un par de párrafos.

Cangrejos a 10 centavos la docena

Se dice que el escritor de la novela DUNAS (DUNE para los fans) dijo alguna vez que las ideas sin desarrollar valían 10 centavos la docena. Una idea solo tiene valor a partir de que uno le invierte el suficiente trabajo y por lo tanto, solo una idea completamente desarrollada puede considerarse robable.

La pregunta es ¿Cuanto desarrollo necesita una idea para ser considerada robable?¿Puede uno realmente decir que la idea que tiene le pertenece realmente a uno?

De hecho, recientemente acabo de terminar de ver un interesante video de una conferencia impartida en el Campus Party (y cuyo enlace pueden encontrarlo en la red social asociada a este blog) donde un empleado de Electronic Arts hablaba de lo que siempre hablan en esta clase de conferencias; mas adelante escribiré una nota completa sobre este video; pero lo que viene a colación con lo tratado en esta nota fue la última parte donde se hablaba del trabajo en equipo. Como de costumbre mencionó aquella fábula de los cangrejos en los que estos se impiden mutuamente la salida del barril donde se hallan atrapados. ( Como paréntesis, cada vez que escucho esta historia me pregunto como es que hace el último de los cangrejos para salir del barril cuando se ha quedado solo ).

Para nadie es un secreto que yo soy muy poco colaborativo para con mis colegas de “La industria”, pues aunque aún (noviembre 2009) no tengo una S.A. Registrada bajo mi nombre si tengo ya un buen rato investigando en “el mundillo” (como dirían los españoles). Yo mismo he declarado unilateralmente la guerra a determinados grupos de “Desarrolladores” y normalmente vivo burlándome de todos los demás. Pero este no es el caso cuando se trata de la Programación en Lenguaje Ensamblador; pues hasta ahora no he encontrado a un solo programador (competente) de ensamblador con el que no me lleve bien. Supongo que por el mismo hecho de que somos pocos es que existe esa hermandad innata entre los programadores de Ensamblador. Por lo que lo mucho o poco que he conseguido en mis investigaciones en estos mas de 10 años voy a compartirlo con esta comunidad.

La pregunta que supongo que han de estar haciéndose es ¿Porqué este imbecil quiere regalar por ahí sus conocimientos tan duramente ganados en lugar de usarlos para producir un buen juego y hacerse rico? Puedo contestar a esto con al menos 3 respuestas:

Primera: Estos conocimientos son exclusivamente para programadores de Ensamblador, esta información le resultará inutil, cuando no imposible de entender a quienes no conocen ni les interesa programar en este lenguaje.

Segunda: Al menos en mi país, y en buena parte de los paises mas avanzados, casi nadie programa en Ensamblador. Sin embargo ya hay grupos que dicen dedicarse profesionalmente al desarrollo de videojuegos. Si alguien se va a llevar mi empleo prefiero mil veces que se lo lleve otro programador de Ensamblador que sea mucho mejor que yo a un maldito lamer que ni siquiera sabe como hacer scripts para un motor gráfico ya hecho.

Tercera: Los trabajos “robables” son aquellos que ya están terminados, no los formados de piezas inconexas. Por lo que aunque veo muy probable que algunos hagan copy-paste con algunas rutinas veo muy dificil que alguien se tome la molestia de hacerlas trabajar todas juntas para formar un videojuego completo. Y acaso hay alguien que logre tal hazaña.. ¡Bienvenido sea al fascinante mundo de la Programación en Lenguaje Ensamblador!

Saben, desde hace ya algunos meses que quiero comenzar a hablar sobre el tema de gráficas por computadora. Pero no lo he hecho porque para poder entrar al tema se requiere de cierto dominio sobre temas de los que casi no he escrito en este blog. Pero espero poder haber cubierto algunos de estos temas y haberles mostrado como hacer una sencilla animación de sprites en uno o dos meses. Mas adelante puede que veamos algo de gráficas vectoriales. Pero por ahora es mejor velar las armas y prepararnos para lo que viene en las próximas notas.

Por cierto, la red social de programadores de ensamblador ya está creciendo, literalmente de la noche a la mañana se inscribieron “two of my most deadly minions” que me han acompañado en esto del ensamblador durante ya algunos años y el maestro que organizó el evento en el Tec de Zitácuaro. Algunas horas después entró otro famoso seguidor y casi un “contributor” que proviene de una tierra donde no es nada facil programar (él sabrá de quien hablo cuando lea esto), un programador argentino que escribe un interesante blog sobre programación tan avanzado que aún yo tengo que leerlo despacio para entenderlo y un programador español que aunque aún no ha mostrado sus habilidades ya demostró su valor al entrar a una red social de locos que solo programan en Ensamblador. En fin, espero que esa red social junto con este blog crezcan, si no con mucha gente, al menos con los mejores. Pues programar en Ensamblador es tan dificil que solo muy pocos entre los pocos pueden realmente dominar este lenguaje.

Espero que un día no muy lejano esta pequeña sociedad tenga el suficiente poder en términos de recurso humano e infraestructura de software para poder convertirse en una verdadera desarrolladora de videojuegos. Hay que actuar ahora que los esfuerzos por levantar estas empresas en México son poco menos que risibles; al menos desde el punto de vista de los programadores de Ensamblador.

Red Social de Programadores de Ensamblador

–Quienes les gusta el ASM ya no estarán solos–

Una vez mas doy mi mas sincero agradecimiento a toda la gente del Tecnológico de Zitácuaro por la conferencia de Gráficas por Computadora a la que me invitaron como expositor. Como recordarán luego de esa conferencia quedaron 2 temas en el aire: El hacer un grupo de maestros que compartan información sobre programación en Ensamblador y otro dedicado al desarrollo de videojuegos en este mismo lenguaje. A dos semanas y desde mi escondite de 8 metros cuadrados en Monterrey he comenzado una pequeña red social en NING. Aún no está terminada pero ya es mas o menos usable. Para visitarla solo den click en la captura de pantalla mostrada a continuación:

Y como de costumbre. ¿Que clase de beneficios obtendrá quien entre a esa red social? El primero es el de convivir, comunicarse e intercambiar información y códigos. Pues lo mas importante de una red social es su gente. Sin mencionar que los buenos programadores de Ensamblador son particularmente difíciles de encontrar. Y para que esta gente pueda comunicarse se dan los siguientes servicios:

Chat:

Platica en tiempo real y en grupo con todos los integrantes de la red social, entre los que destacan maestros, programadores independientes, alumnos y cualquiera que tenga algo que compartir. Parece que este chat tiene una función oculta que te permite buscar gente por su edad que aún no se como funciona. Así que si te saca plática alguien con un avatar de oso color café, di no, aléjate y cuéntaselo a quien mas confianza le tengas.

Foros de discusión:

¿Para qué discutir si podemos pelear? Participa en toda clase de discusiones relacionadas con la programación en Ensamblador, Gráficas por Computadora, Desarrollo de Videojuegos y por supuesto no podrían faltar las burlas a otros autodenominados “profesionales de la industria”. Si tienes algo que decir comienza una discusión. Aunque luego no te quejes si no puedes terminarla.

Grupos:

Para no perderse entre tanta información hay grupos interesados en un tema en particular. Ya hay uno para enseñar a los principiantes a programar en ASM y pienso hacer otros mas que se me ocurran. Si tienen alguna buena idea para un grupo no esperen y créenlo ustedes mismos.

Blogs:

Si lo que tienes que decir es demasiado para el chat y los foros de discusión, prueba el Blog. En este cualquiera que tenga la paciencia y las ideas puede escribir. Igual y puedes hasta escribir algún tipo de manual o entrada que valga la pena compartir con la comunidad.

Fotos y Videos:

Se supone que en esta sección van a ir algunos videotutoriales que aún no se me ocurre como hacer. Por favor denle buen uso a esta función y no nada mas suban imagenes del Goatse y videos de las borracheras con sus cuates.

Eventos:

Simples avisos de eventos que pueden ser usados de muchas formas, desde avisar de simples reuniones del grupo hasta dar fechas de exámenes o entrega de proyectos.

Pues que mas hay que decir. Que aunque esa red social fue pensada para los grupos de ensamblador y programación de videojuegos del ITZ cualquiera puede entrar. Leyeron bien. Cualquiera. Así que si tu que lees esto no perteneces al Instituto Tecnológico De Zitácuaro, Michoacán pero te interesa hacer programación gráfica y videojuegos en Lenguaje Ensamblador eres bienvenido.

Solo recuerda que antes de ser una comunidad ( mas ) de desarrollo de videojuegos o gráficas por computadora, se trata de una comunidad de Programación en Ensamblador. Así que si quieres hablar sobre game engines, software de diseño gráfico o, peor aún, cualquier otro lenguaje de programación que no sea Ensamblador (o C si de casualidad me encuentras ebrio o de muy pero muy buen humor) no esperes escapar con la dignidad intacta. Fuera de eso…

¡Bienvenido a la nueva comunidad virtual de Programación en Lenguaje Ensamblador!

 

Red Social Ensamblador Zitacuaro

Estoy construyendo una red social para aquellos interesados en la programacion en ensamblador, desarrollo de videojuegos (en ensamblador) y graficas por computadora. Y aunque fue hecha pensando en el Tec de Zitacuaro cualquiera que le interesen estos temas puede unirse.
En cuanto el sitio sea mas o menos usable les paso el enlace.

Háblame al Chile

–La Verdad sobre CASI Todas las Escuelas de Programación de Videojuegos–

La expresión “Háblame al Chile” se usa en México para pedirle a alguien que nos hable con la verdad , de manera directa y sin rodeos. Y de esa manera voy a hablar esta vez sobre uno de los temas que mas se prestan para hacer chistes crueles en este blog: Las “carreras profesionales” en las que te enseñan a hacer videojuegos.

Y si escribí CASI en el subtítulo fue porque aún no he acabado de investigar a TODAS las escuelas de programación de videojuegos a nivel mundial. Esto es únicamente lo que he encontrado en TODAS las escuelas que he investigado mas o menos de cerca.

Hace unas horas estaba hurgando otros post dedicados a la programación y los juegos de video cuando me encontré con una joyita. Se trata de un blog de ¡Una escuela de programación de Videojuegos! Específicamente de un cierto instituto cuyo nombre incluye la frase “Desarrollo de Videojuegos” Esta escuela es originaria de ese peculiar pais enclavado en el cono sur: ¡Chile! De ahí el peculiar nombre de esta entrada.

Como todos sabemos, los blogs que los maestros hacen para apoyar sus materias no son lo que se dice muy elaborados. No pasan de ser mas que un trozo de texto con fechas de exámenes, entrega de tareas y algunos enlaces a trabajos descargables (que en este caso van a ser objeto de mis burlas). Aunque pensándolo bien creo que no tendré que esforzarme demasiado, pues hay situaciones en que las burlas están de mas y lo único que hace falta es hacer que la gente voltee a ver a la víctima.

Al estar escribiendo esta entrada no puedo dejar de pensar en una de las notas mas divertidas de este blog titulada “El Circo de Pulgas” en la que unos autodenomidandos “programadores profesionales” quisieron hacer un clon de un juego y no pasaron de hacerse mierda entre ellos. De hecho la última vez que quise leer su foro de discusión ya no pude encontrarlo. Lo último que alcancé a leer fue de alguien que intentó deshonrar otra leyenda de los videojuegos de los ochentas usando las mismas técnicas de aficionados. Bueno, ahora que investigué un poco mas sobre esta escuela y di con el plan de estudios no pude aguantarme la risa. Pero solo para que se den una idea de la calidad de los profesionales de la industria, aquí va una comparativa entre el grupo mencionado en El Circo de Pulgas y este curso llamado “Programación Gráfica I”:

                        Circo de Pulgas		        Domadores de Pulgas

Lenguaje usado	        C++				C#

API			SDL				XNA

Hecho por:		Ingenieros titulados		Institución de educación superior

Acabó en:               Pelea entre ellos		Todavia falta lo mejor

Hay algo que no alcanzo a entender de estas carreras profesionales donde te enseñan a hacer videojuegos. Por un lado los 10 semestres que toma una de estas carreras me parecen demasiado tiempo y al mismo tiempo al ver el plan de estudios me parece que este es insuficiente. Si lo comparamos con los 3 años de confinamiento solitario como lo que en sus buenos tiempos se hacía en Digipen (una instalación en donde Nintendo entrenaba a una buena parte de sus ingenieros) una de estas carreras no es lo que se dice muy eficiente a la hora de entrenar ‘profesionales de la industria de los videojuegos’. Sin embargo, desde lo acontecido en la entrada “Esto no tiene nombre” me he encontrado con un sinfin de esta clase de cursos en escuelas de todos los niveles. Desde simples diplomados del tipo “Aprende el lenguaje X programando videojuegos” hasta carreras universitarias del tipo “Ingeniería en diseño y desarrollo de videojuegos, multimedia, artes digitales y animación” aunque a veces pienso que esto no es algo nuevo, pues desde hace ya algunos años había rumores de una escuela llamada “Full Sail”(aunque creo que mas bien debería de llamarse Full Sale) que tenía la mala reputación de cobrar cantidades estratosféricas a cambio de una preparación tan mala que muchas desarrolladoras serias como Electronic Arts simplemente rechazaban las solicitudes de empleo de sus egresados. Creo que este tema amerita un análisis mas serio; pero hasta ahora he notado cierto patrón en los planes de estudios de esta clase de “Carreras Profesionales”:

1.- Ninguna lleva tan siquiera una sola materia de matemáticas (vital para entender algoritmos gráficos)

2.- Solo hay uno o dos semestres de programación y apenas se alcanza a estudiar la sintaxis de algún lenguaje de moda

3.- La mayor parte de las herramientas tanto de programación como de diseño son propietarias.

4.- Hay una serie de materias con nombres tan ambiguos como “videojuegos 1, 2 y 3” o “arte” (aunque yo creo que es mas bien “Harte” con H) que no dejan claro que es lo que se estudia

5.- En las materias de programación mas avanzadas lo único que parecen hacer es aprender a hacer llamadas a bibliotecas (APIs, engines, frameworks o como quiera que les llamen) desde el lenguaje de moda.

6.- Las tareas son cosas tan ridículas como “investiga que motor gráfico” fue usado en la creación de X juego o alguna idiotez por el estilo. Las mejores tareas parecen mas notas de una revista de videojuegos que un trabajo de un auténtico desarrollador

7.- Los proyectos mas avanzados no superan ni en lo técnico ni en lo artístico a los juegos de mediados de los ochentas; pero necesitan una computadora de última genaración con una configuración especial para correr, eso en el caso de que funcionen.

8.- La única carrera de estas donde se menciona algo sobre la programación en Ensamblador ya saben cual es y el nivel que tiene.

Bueno, ya eché mucha agresión para una sola nota. Nada mas para rematar quiero mostrar una captura de pantalla de uno de los videojuegos hechos por el maestro que imparte la materia de Programación Gráfica I, en este demo se destacan sus sorprendentes gráficos pero mas que nada su jugabilidad:

Por cierto, si quien lee esta entrada es el mismo maestro que escribió el blog (o algún otro que se sienta aludido al leer esta entrada) le pido por favor que no se la jale y aprenda a programar de verdad. O por lo menos que descargue el SDK oficial de DirectX (pero el que es para C++ que es el bueno, no el de managed code) si no es capaz de programar una computadora como se debe que es en lenguaje de máquina.

Ahora que lo pienso, a lo mas que podrían aspirar los egresados de este tipo de carreras sería de redactores en alguna revista especializada en juegos de video o como empleados de una tienda de estos. Pues al menos estudian quien hizo tal o cual juego y que elementos contiene. La parte que no soporto es que existan escuelas que cobren cantidades estratosféricas por dar una “preparación” que en el fondo saben que no les va a servir para desarrollar un verdadero juego de última generación y que por otro lado existan empresas “Desarrolladoras” que no sean capaces de desarrollar su propia tecnología para sus juegos. A veces pienso que este tipo de empresas tienen mas que ver con una maquiladora o una franquiciataria del grupo que les licenció la tecnología para crear sus juegos. Y pensar que cuando me decidí a ser programador fue porque programar era una actividad muy barata; aunque parece que lo mas caro de pagar para las empresas actuales son precisamente los programadores.

De acuerdo, aquí se termina la nota. Y sin rencores, si algún maestro de alguna de esas carreras de desarrollo de videojuegos lee esto y quiere cambiar con gusto puede acercarse a este blog y aquí hablamos. Excepto si son de la Universidad de la que me expulsaron porque según mis cálculos no podré poner un pie ahí hasta bien entrado el año 2024. Es mejor que hagan algo con esos planes de estudio porque si no, al salir a “la industria” a sus egresados les van a dar puro Chile.