Programación en Lenguaje Ensamblador

-El Verdadero Lenguaje de las Máquinas-

¡No me gustan los engines ni las aceleradoras gráficas!

–O al menos no me gusta el uso que se les da–

En realidad no es que no me gusten los engines ni el hardware de aceleración grafica en si. Lo que desprecio es como pseudodesarrolladores creen que solo porque tienen acceso a estas tecnologias no necesitan saber programar. Pero antes de entrar a la trolleada en serio vamos a ver primero que es cada una de estas cosas.

Lo primero que hay que dejar en claro es que las computadoras (y las consolas de videojuegos técnicamente son computadoras) pueden construirse para poder hacer cualquier cosa medianamente bien que es lo que se llama propósito general o ser optimizadas para hacer lo mejor posible unas pocas tareas que es el caso de las de propósito específico. Las consolas de juegos y las tarjetas gráficas para computadoras cuentan como hardware de propósito específico. Y en el caso de la aceleración gráfica por hardware esta es tan vieja como los mas antiguos sistemas de Atari de finales de los setenta. El NES contaba con un circuito PPU (Picture Processing Unit) que le permitía hacer costosas operaciones de manejo de sprites independientemente de su modesto CPU 6502 de 8 bits. El primer Playstation contaba con un modesto coprocesador con capacidad Fixed Point y un decodificador de video independientes de su procesador principal y cualquier computadora actual con sistema de video independiente de la tarjeta principal tiene su propia capacidad para procesar datos de video y hacer cálculos vectoriales que ayudan mucho en los gráficos 3D. Este hardware de propósito específico permite bajar costos de fabricación de los equipos y reducir los tiempos de desarrollo y sin ellos las consolas de videojuegos hubieran sido tan costosas como las computadoras y no habría sido buen negocio venderlas.

Explicar lo que es un engine es bastante mas dificil. Lo que al principio eran unas pocas rutinas de código reutilizable se han convertido en enormes software de desarrollo comparable con los sistemas operativos. Cuando me preguntan lo que es un engine suelo decirles que es lo que queda de un videojuego cuando le quitas todo el arte, el diseño y dejas solo el código aburrido. Pero los modernos engines capaces de procesar scripts hechos en algún lenguaje interpretable han hecho que la frontera entre el código que conforma el engine y el código que es procesado por el engine se pierda. Para explicarme voy a contar mi teoría sobre el origen de los engines.

Programar es dificil, pesado y confuso. Una vez que un código funciona bien es mejor no solo conservarlo sino volverlo a usar tanto como podamos. Los programadores no teclean todo desde cero cada vez que van a comenzar un nuevo juego sino que llaman rutinas que crearon meses o incluso años atrás que están bien seguros de que les funcionan. Y cuando quieren implementar algo nuevo nunca incorporan el nuevo código a un juego sin antes asegurarse de que la mejora trabaja bien con todas sus antiguas rutinas.

Como dije hace mucho en la entrada “Códigos e Invocadores”, ese conjunto de rutinas de código que funcionan son el ejército del programador. Y como buen comandante de este ejército debe de saber darles órdenes en plena batalla. Y por esto se inventó el Script. Un script es un trozo de código interpretable que es procesado por esas rutinas de software. Y se dice que nació cuando un programador se fastidió de tener que hacerle cambios a sus programas todo el tiempo. Creó un sistema que en lugar de tener que ser reprogramado cada vez era capaz de seguir instrucciones sencillas dictadas en unas pocas lineas. Esta forma de programar se adaptó rapidamente al mundo del desarrollo de juegos de modo que un mismo conjunto de rutinas en combinación con un sistema para interpretar scripts pudo usarse en muchos títulos diferentes sin necesidad de recompilar nada. Bastaba con crear arte usable y teclear algunos scripts y ya teníamos un juego nuevo.

Con el tiempo, las empresas que lograron construir sus propios engines pudieron hacer juegos muy buenos y le dedicaron mas tiempo a crear historias y personajes elaborados y menos en leer libros de programación y matemáticas. Pero no había problemas porque el programador que había creado el engine trabajaba junto con ellos y podían ir a consultarlo cada que tenian alguna duda. Y como era de esperarse cuando otros les preguntaron sobre como hacian juegos tan buenos no faltaron millonarios que ofrecieron dinero a cambio de los derechos de uso de esos engines. Y así nacieron los sistemas de desarrollo que conocemos hoy.

La pregunta obligada antes de soltar al troll es ¿Porqué tanto desprecio a estas dos tecnologias sin cuya existencia los videojuegos no hubieran podido progresar? La respuesta es sencilla: ¡Hay desarrolladores ineptos que creen que estas tecnologias se crearon para que ellos no tuvieran que programar!

No es la flecha sino el indio…

Los que me conocen desde hace tiempo saben que he estado programando desde los tiempos en que se dio la transición de los 16 a los 32 bits en PC y que muchos de mis maestros (y no me refiero a los de la escuela) fueron programadores de sistemas de 8 bits. En esos tiempos si uno quería programar un juego no había otra que hacer la lógica principal con C/C++ y programar las rutinas gráficas mas avanzadas directo en ensamblador. En el caso de las consolas no había de otra que programar en ensamblador porque las memorias de los antiguos cartuchos eran demasiado caras. En ese tiempo ser programador de videojuegos era pertenecer a una casta superior que se hallaba muy por encima de cualquier otro trabajador de las computadoras. Pues si uno quería hacer juegos, sobre todo juegos 3D debía dominar no solo la programación a nivel muy avanzado sino también saber matemáticas mas avanzadas que las que se ven en cualquiera de las ingenierias a nivel universitario. Y por supuesto la única manera de que un juego 3D se viera bien en un 486 que corría con DOS era metiendo todo el código del juego en un EXE de apenas 100 o 200 kilobytes.

Pero un día llegaron las aceleradoras 3D. Artículos de lujo que muy pocos podían pagar y los programadores tuvieron que hacer juegos que si bien pudieran aprovechar este nuevo hardware si lo detectaban aún pudieran seguir corriendo en equipos que no lo tuvieran. Y eso fue hasta que salieron juegos infames que pedian este tipo de tarjetas como requerimiento mínimo para funcionar. Como era de esperarse hubo juegos que no vendieron lo esperado gracias a esto como fue el triste caso de Descent 3.

Y el asunto no terminó ahi, sino que como este hardware en sus inicios era cerrado no había manera de hacer rutinas propias para él y la única salida era recurrir a bibliotecas (por las que había que pagar derechos) para poder usar este tipo de hardware. Al mismo tiempo comenzaron a surgir bibliotecas cerradas de funciones que te permitian llamar a estos sistemas sin mas necesidad que meter un #include al inicio del código. La gente comenzó a creer que hacer juegos 3D era cosa de tener una computadora con un hardware determinado y no creian cuando se les decía que 3D en realidad eran algoritmos y matemáticas. Como prueba incontables empresas de videojuegos compraron costosas computadoras Silicon Graphics que nunca supieron como programar porque creian que tan solo por comprarlas iban a poder hacer juegos que se vieran como el Donkey Kong Country de Rare. ¡Hubieran podido hacer un juego con ese mismo nivel de gráficos conectando sus humildes PC en un cluster y sentando frente a estas a un programador que supiera un mínimo de Ensamblador x86 y Algebra Lineal!

Pasaron algunos años para que el hardware de aceleración gráfica se estandarizara lo suficiente para no tener que crear rutinas para cada tipo de tarjeta en el mercado pero todavía queda mucha gente que cree que las gráficas 3D las hace el hardware sin intervención del programador. Puede que tener una PC poderosa ayude a renderear video mas rápido o correr software de desarrollo mas avanzado pero si no sabes un mínimo de programación la computadora mas poderosa te resultará inutil.

Ahora vamos con los engines. Lo primero que hay que tomar en cuenta a la hora de intentar acortar los tiempos de desarrollo licenciando un engine es que es mucho mas dificil para un programador entender el código de escrito por otro programador que construir el suyo desde cero. Lo segundo es que hay diferentes tipos de licencias para estas cosas, unas van desde dar solo permiso para crear juegos usando herramientas visuales y un poco de scripting pero otras incluyen acceso al source code y derecho a usar partes de él en otros proyectos bajo estrictas limitaciones.

En si los engines son buenos si se saben usar. La trampa de los engines consiste en que muchísima de la gente que los licencia cree que no necesitan saber programar para usarlos cuando es todo lo contrario. Para que me entiendan usar un engine sin saber nada de programación gráfica es como comprar un barco y no saber navegar. Primero pueden sentirse muy poderosos por tener una pieza de equipo costosa y muy avanzada, pero pasado un tiempo de usarlo se van a perder en un mar de problemas que no van a saber como resolver y al final se irán a pique irremediablemente. No voy a mencionar gente que ha perdido dinero por pagar por estas cosas sin saberlas usar porque no es dificil encontrar estos casos en internet. Lo que si les voy a decir es que he visto una cantidad impresionante de quinceañeros que no saben siquiera lo que es un vector y que creen que van a poder hacer avanzadísimos juegos 3D sin tener que saber nada de programación. Esto es un espejismo.

Una cosa que sabe cualquiera que haya leido un libro de mantenimiento de sistemas es lo dificil que resulta entender un código escrito por otras personas, si a eso le sumamos que para entenderlo hay que saber conceptos matemáticos que no se ven en cualquier ingeniería y si a eso a la vez le sumamos que con el pretexto de la portabilidad estos engines pueden tener una misma rutina implementada de maneras muy diferentes y si todavía a eso le sumamos que le vamos a tener que “desensamblar” algunas partes tan solo para poder optimizarlo el resultado es que vamos a necesitar un modesto equipo formado por un experto en mantenimiento de sistemas, un maestro de matemáticas universitarias, un administrador de desarrollo de software y alguien que sepa hacer buena ingeniería inversa tan solo para USAR un engine a un nivel minimamente redituable. Pero lo que he visto en mi experiencia cercana es que quienes licencian un engine no solo no les interesa saber nada de programación sino que ni siquiera les interesa aprender sobre su funcionamiento. O como escuché a uno de estos decir en un foro que prefería pagar por un engine ya hecho en lugar de programarlo el mismo porque “eso le daba soporte y garantía”. ¿Tan poca confianza tienen en sus propios códigos?.

Otro error bastante nefasto que he visto cometer a muchos que juegan con dinero es que creen que porque otra empresa afamada al otro lado del planeta usó un engine X ellos van a poder hacer juegos igual de buenos si también lo licencian. Y el resultado es que no encuentan personal que pueda usarlos de manera confiable. El problema es que estas tecnologias por lo regular son software propietario al que muy pocos tienen acceso y cuando es libre o tiene una licencia menos restrictiva nada garantiza que quienes declaren manejarlo lo manejarán bien. Como ya dije he visto a muchos aficionados que no saben las cosas mas elementales de matemáticas creer que dominan un engine tan solo porque pudieron instalar la versión de prueba por 30 dias y lograron correr y medio modificar los ejemplos incluidos en el tutorial básico. Por cierto, quienes caen en esta categoría de seguro reconocen al ilustre personaje de la segunda imagen de esta entrada. De hecho si yo llego a licenciar un engine propio (el que lo voy a crear no está sujeto a discusión) incluiré en el costo de la licencia el salario de un especialista que asesore de manera presencial. Solo así podré garantizar al cliente que va a obtener aquello por lo que pagó y no tenga que traerse gente de esas regiones de nombres impronunciables donde se les hacen chiquitos del frio y que quién sabe si puedan o no con el trabajo, como uno cuyo perfil de linkedin me acabo de encontrar y al que no me aguanto las ganas de hacerlo víctima de mis mas infames tácticas de trolling.

Ya para terminar solo me queda darles dos consejos: El primero es que las aceleradoras gráficas son hardware y como hardware puede ser programado directamente en ensamblador o su lenguaje máquina equivalente. Así combinarán la velocidad del ASM con la mejora del hardware y que mejor que si aplican el algoritmo mas eficiente que encuentren. En cuanto a los engines no se olviden que no basta con ser capaz de correr los ejemplos y modificar los assets. Necesitan saber optimizar y para eso no basta con leer los manuales sino saber las matemáticas básicas tras las gráficas 3D y aspectos muy particulares de la plataforma en la que está corriendo. Y si se consideran a si mismos programadores mas les vale seguir estos dos consejos y dominar esas tecnologias antes de que esas tecnologias los dominen a ustedes.

octubre 1, 2012 - Posted by | Uncategorized | , , ,

4 comentarios »

  1. Mi pregunta. Como hacer graficos en windows sin usar DirecX ni OpenGL? Segun mis ultimas pruebas al final creo que siempre necesitare una tarjeta gráfica.

    Comentario por Oscar | octubre 1, 2012 | Responder

  2. coincido con Oscar… pero deduzco que el no sabe lo que es un API XD…

    y tambien coincido con el posteador con muchos de los conceptos que expresa aqui… no los encontre en ningun otro lugar en la web…

    Comentario por MatiasFPM | noviembre 1, 2012 | Responder

  3. Hablas con tanto desprecio hacia lo que ni has programado, criticas tanto a los desarrolladores cuando nadie, en el mundo hace juegos en ASM, desde cero (cada proyecto) y sin hacer uso de Hw de video. Creo que estas completamente cegado por lo que no conoces y lo criticas por el miedo y la negación de tener que conocerlo.

    Que existan shaders y el programador tenga acceso al hardware de video no significa que seamos unos flojos de inútiles que no saben lo que hacen, caray, en tal caso porqué no creas tu propio hw, tus propios drivers, tu propia arquitectura, ya que todo lo que hay no es aprobado por tí…

    Me comentas que usas una superficie de Dx y haces lock y unlock para acceder al buffer, pero todo lo que va antes, el llenar tu arreglo de unsigned chars con pixeles, lo haces por CPU, y por más que uses ASM, SIMD, etc.. jamás le ganarás a usar los stream processing units, que procesan en paralelo cada vértice, y posteriormente cada pixel. Es el modelo concurrente más existoso que existe, y no lo sabes usar, y hasta lo criticas.

    Dime, ¿haces la rasterización a mano? de ser así te reto a que pongas cómo lo haces, liberes el código y muestres aunque sea un vil cubo girando con iluminación por pixel, y además demuestres que es más rápido que hacerlo usando hw de video (shaders), para que demuestres, con toda razón tus puntos que tanto criticas.

    Por otro lado dudo que generes a mano bytecode para la tarjeta de video, ya que es depndiente del modelo, por ello hay drivers especiales para cada tarjeta y tienen extensiones especiales, las cuales supongo que también ignoras.

    Y por último, programar con shaders es basicamente matemáticas, álgebra lineal, transformaciones, pasando por interpolaciones y todo en espacio discreto, puedes interpolar un vector del vertex shader al pixel shader, o calcularlo en el pixel shader.

    Como te dijo bien Marcel, mejor infórmate más antes de criticar algo tan fuerte y donde claramente no eres experto.

    Comentario por Daniel Camus | noviembre 27, 2012 | Responder

    • Un comentario al que se le dedicó tanto tiempo merece una entrada completa como respuesta. Mantente pendiente del blog en estos dos dias

      Comentario por asm86 | noviembre 27, 2012 | Responder


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: