Bajo un océano de bits

Javier Albizu Vie, 05/01/2018 - 21:00

Bajo un océano de bits, mes I

Yo tenía un plan. Aunque erra un mal plan, era mío. Mirándolo en perspectiva, reconoceré que era un plan de mierda, un plan nada realista planteado desde una serie de asunciones erróneas. Un plan que, al final, no me habría servido para lo que quería.
Pero yo tenía un plan.

Antes de eso, mucho antes, yo tenía un deseo: Quería hacer un vídeo juego.
Quizás este deseo no se remonte tanto como para retrotraernos hasta el momento en el que contemplé las interioridades de una recreativa, o aquel día en el que mis manos se posaron sobre el primer Pong familiar que llegó a casa, o hasta mi primer y fallido contacto con Commodore¹.
Quizás tampoco llegue tan atrás como para vincularlo al Spectrum que sucedió a aquellas máquinas y que pereció esa misma noche², o con el MSX que siguió a este³.

Puestos a suponer, mis memoria podría tratar de ubicar el germen de este deseo con el regreso de la máquina de Jack Tramiel a mi vida y el advenimiento de SEGA⁴. Es probable que también ayudasen el paulatino descubrimiento de los lugares secretos de Pamplona⁵ y las primeras e inesperadas relaciones de amistad que surgieron en algunos de ellos⁶.
Pero yo tenía que hacer un juego de ordenador (y un libro, y un tebeo, y un juego de rol y…)

Así que pedí a mis padres que me apuntasen a clases de informática (fuese lo que fuese eso), y así lo hicieron… varias veces. Pero en los lugares en los que acababa sólo me enseñaban a hacer programas para sumar en BASIC, así que lo dejé… una y otra vez.

Cuando abandoné la enseñanza reglada el deseo seguía ahí. Oculto y acechante se hacía presente ante la aparición de nuevas recreativas y consolas. Así pues, una vez más pedí a mis padres algo para poder llevarlo a buen término. Era el noventa y poco y lo que llegó a casa fue un curso de BASIC de CEAC. La edición del año noventa de un curso de BASIC del ochenta y tres que anunciaban en el 93 como “Curso de informática” (sea lo que sea eso).

Tras ojearlo por encima y ver que era más de lo mismo no le hice ni caso. Ni a él ni a la pasta que les habían tangado a mis padres. Amor de hijo.

La siguiente intentona fue al año siguiente. En el noventa y cuatro salió en los kioskos el “Curso IBM de animación diseño gráfico y multimedia”. Un curso que la kioskera a la que le comprábamos la prensa (y que al mismo tiempo era uno de mis múltiples proveedores de tebeos) me reservó eficientemente durante un año.
Este curso incluía entre sus fascículos la versión reducida de otro coleccionable, el “Curso IBM de Programación en C++”.
Tras mirarlo y ver que no me enteraba de la misa la media también lo aparqué.

Hubo muchos más intentos (aunque no demasiado intensos) para llevar aquello hacia adelante. Libros prestados de Turbo Pascal y tomacos que hablaban de programación estructurada. La zona metafórica de mi cráneo está poblada por los chichones causados por mis cabezazos contra la programación, pero no había manera de que nada de aquello entrase en mi cabeza.

Habré leído las primeras cien páginas de más de dos docenas de manuales, cursos y tutoriales de programación, pero siempre ha llegado un momento en el que no entiendo nada de lo que me están diciendo. Es probable que en cada una de estas ocasiones haya avanzado un par de páginas más, pero la frustración siempre me ha hecho dejarlo.

Hasta aquí, me dije hace unos años. Tengo que elaborar un plan. Un plan realizable con un objetivo claro y perfectamente delimitado.
Y así lo hice. Cada día hice un plan. Un plan que era postergado, remodelado e invalidado con la llegada de cada nuevo amanecer.
Mientras tanto, con el paso de los años iba haciendo acopio de información⁷. Decenas de enlaces, cientos de libros y vídeos que me decía “esto puede venirme bien”. Material que nunca volvía a mirar.
Estos planes no abarcaban únicamente a la programática, sino que se extendían por todas las facetas creativas tocantes a mis aficiones.

Esto fue así hasta hace cuatro años. En 2014 decidí dejar de leer sobre las cosas que quería hacer y empezar a aprender a través de la práctica. Me planteé retos personales con una duración de dos años durante los que evaluaría mi evolución. No era la primera vez que me planteaba algo parecido pero, en las anteriores ocasiones, nunca me había establecido una fecha de fin. El objetivo no era alcanzar una meta sino el ver hasta dónde llegaba. Al menos esto fue así en el primero de estos retos.

Este consistió en hacer un dibujo diario durante esos dos años⁸. Mientras lo hacía me preguntaba “y después... ¿qué?”. Una pregunta que respondí durante los últimos meses de este primer “tour de force” conmigo mismo.
Al maltrato del papel le siguió otro de los objetivos de antaño; el crear un manual básico para Daegon⁹. La misión con la que os ido torturando (y me ha servido para mantener viva esta web) desde 2016.
En este caso el objetivo era más concreto y complejo que en el primero. Estaba dividido en varios sub-retos más pequeños que he ido ampliando a lo largo de su duración, en algunos de los cuales, pese a fracasar en el principal, he salido triunfante.

Al igual que sucedió con los anteriores, cuando se acercaba el final de esta fuente de frustración, volvía una y otra vez la pregunta; “Y después... ¿qué?”. Y esta vez la respuesta fue… darme de cabezazos una vez más contra la programación.

Y aquí estamos. Dos años para hacer un vídeo juego y descontando.
Mientras aún me encontraba en los que creía que eran los últimos estertores del anterior reto traté de preparar el terreno. Le dí un tiento a la obra de los padres del C¹⁰ sin erótico resultado. Poco parece haber cambiado en mis procesos mentales a ese respecto.

Buscando algo más accesible, leí a gente que recomendaba ganar algo de conocimiento sobre los más amistosos ofidios antes de pasar a temas más arcaicos y áridos¹¹. Así pues, me puse a aprender Python a las duras y avancé bastante en este asunto. Llegué a teclear treinta y ocho de los cincuenta y dos ejercicios de ese libro antes de decirme “Bah, tengo tiempo, ya lo finiquitaré cuando toque dedicarle toda mi atención”.

Y llegó la fecha. Como ya comentaba la semana pasada, todo se me descuadró un poco pero no iba a retrasar esto durante más tiempo. Pero tenía un pequeño problema de base.
Por más irregulares que sean las líneas, sé manejar un lápiz. Por más inconexas que sean las palabras resultantes, sé juntar letras. Pero sigo sin tener ni idea de cómo empezar a hacer un juego de ordenador.

Así pues, durante el primer mes me he dedicado a leer sobre el asunto. Ya sea desde el punto de vista de un escritor¹², o algo un poco más generalista¹³.
Tras la lectura tengo una idea aproximada de en qué debo centrarme. Temas que ya intuía se han confirmado, pero muchas de las dudas no han desaparecido.

Tengo claro que mi juego será un plataformas 2D de scrol lateral. Sé que estará ambientado en Daegon y que será software libre. Y hasta aquí puedo leer.
En primera instancia quería hacerlo con píxeles gordotes, pero ante mis limitaciones artísticas me he planteado el darle una estética de lápiz sin entintar.

Durante todo el proceso previo había decidido utilizar Godot como motor del juego. Iba mirando su evolución y me apunté a un par de cursos sobre él en Udemy, pero, se acercaba la llegada de la versión 3.0 y no sabía si lanzarme a comenzar el juego con la 2. Así pues, tanteé otro de los materiales que tenía por el disco duro. Grave error.
Tras comenzar a leer el primer libro de los disponibles por la Universidad de Ciudad Real me picó el gusanillo de hacerlo todo desde cero. Porque yo soy así y me gusta ponerme las cosas fáciles.

De cara a lanzarme a ello ese manual no me parecía el más adecuado, así que me acordé del curso de C++ del noventa y cuatro. Son once libretos de veinte páginas y me parecía algo más asequible para empezar que cuatro libracos de más de trescientas. Pero para el cuarto libreto la cosa empieza ya a hacerse confusa.

Hete tú aquí que, mientras me estoy pegando con esto, otro amigo me descubre al señor Casey Muratori y su Handmade Hero¹⁴.
Tras echarle un vistazo a la obra de este seños, me creé una hoja de cálculo con los datos de todos los capítulos que hasta el momento se encuentran disponibles de su curso.
Vaya, me dije. “Sólo” son 751 horas de vídeos. Si le dedico dos horas al día podría terminar con ellos más o menos en un año. La tentación (suicida) estaba ahí y no tardé en lanzarme con los brazos abiertos hacia ella.
Empecé bien. Las cosas que explicaba en los vídeos previos al propio curso me ayudaron a asentar alguna de las nociones difusas que me había dejado el curso de C++ pero,una vez más, llegó el punto en el que no me enteraba de qué me estaba hablando.

Y así estamos en estos momentos. Una vez que hemos superado la fase de “Hola Mundo” y el calcular el área de un cuadrado, estamos mirando documentación de SFML, OpenGL para crearnos una ventana en la que dibujar cosas. Leo cosas de las API del sistema y no sé por dónde me da el aire. Copio churros de código que hacen las cosas que se supone que tienen que hacer, pero no entiendo el funcionamiento de por qué lo hacen.
Y el tiempo sigue pasando.

Así pues, toca cambiar la planificación… una vez más.
Si para junio sigo sin aclararme volveré al plan original de Godot, pero por el momento voy a seguir dándome de cabezazos contra el C.
Y vosotros iréis sufriendo las consecuencias por aquí, vuestro agónico canal amigo.
Pero os aseguro que yo tenía un plan.

1. Los tiempos míticos
2. Primeras andanzas
3. A la tercera tampoco va la vencida
4. Y llegó el amor
5. El ataque de las magdalenas
6. La secuela del ataque de las magdalenas

7. Herramientas para crear juegos

- Gammemaker
- RpgMaker
- BennuGD
- Arcade Game Studio
- La Churrera
- La Churrera MK I
- La Churrera MK II
- CPCTelera
- CC65
- CBM .prg Studio
- Unity3D
- GameSalad
- Construct 2
- Godot
- NightMod
- Adventure Game Studio
- Garry Kitchen's GameMaker
- Arcade Game Construction Kit
- Adventure Construction Set
- Gaming App Construction Kit
- Openbor
- Tilengine
- Löve
- V-Play
- 8 Bits de poder
- Shoot Em Up Construction Kit I
- Shoot Em Up Construction Kit II
- Shoot Em Up Construction Kit III
- XNA I
- XNA II
- Compilador cruzado para BASIC de Spectrum
- Compilador cruzado de C para Spectrum

Recursos:
- 10 Free Game Development Tools And Other Resources
- The Big List Of Game Making Tools
- Video game development software
- The Game Creators
- Uptopdown
- Ragzouken.itch.io
- Foro Nintendoage

IDEs:
- Netbeans
- Code Blocks
- QT Projects
- Brackets
- PyCharm
- Ninja Ide
- Eclipse
- Visual Studio

Cursos Programación:
- Documentación Godot
- Games From Scratch
- Godot en Games From Scratch
- Más Games from Scratch
- Kids-Started-in-Game-Development.aspx
- Más Kids-Started-in-Game-Development.aspx
- Writing a Game Engine from Scratch I
- Writing a Game Engine from Scratch II
- Writing a Game Engine from Scratch III
- Writing a Game Engine from Scratch IV
- Making a Game Boy game in 2017: A "Sheep It Up!”
- An introduction to writing for computers I
- An introduction to writing for computers II
- Curso de Experto en Desarrollo de Videojuegos Escuela Superior de Informática de Ciudad Real
- Cómo escribir juegos para el ZX Spectrum
- Cómo crear un juego para Gameboy

Plataformas formación:
- Progate
- Codecademy
- Khanacademy
- Quickcode
- Arcademi.co
- Codingame

8. Álbumes de dibujo
- Dibujos de 2014
- Dibujos de 2015
- Dibujos de 2016
- Dibujos de 2017
- Dibujos de 2018

9. Daegon
10. El Lenguaje de Programacion C
11. Learn Python The Hard Way
12. The Ultimate Guide to Video Game Writing and Design
13. The Computer Game Design Course: Principles, Practices And Techniques For The Aspiring Game Designer
14. Handmade Hero/

Javier Albizu Mié, 07/02/2018 - 20:27

Bajo un océano de bits, mes II

Decía (o al menos se le atribuye a) Bernardo de Chartres que caminamos sobre los hombros de los gigantes que nos precedieron. Le expresión me parece evocadora aunque, tratando de formar una imagen mental, esa me parece una posición se me hace un tanto incómoda para moverse durante mucho rato.
Haciendo mía esa analogía, y adecuándola a cómo decidí bautizar a este reto, me gusta pensar que navegamos sobre mares de información. Unas aguas que recorremos en pos del conocimiento.
Realizamos este viaje a bordo de las naves construidas sobre las ideas de esos gigantes que mencionaba el amigo Bernardo. Unas embarcaciones imperfectas que, en gran medida, no tenemos ni idea de cómo funcionan.
Subidos en ellos nos enfrentándonos a oleada tras oleada de información de todo tipo. Información que en ocasiones confundimos con conocimiento, cuando en multitud de ocasiones ambos conceptos no tienen mucho que ver. Esta información puede ser cierta o falsa, parcial o completa, desinteresada, egoista o una mezcla de todos estos factores.
Así pues, de nosotros depende el discernir qué es verdad, qué es mera especulación o qué , simplemente,, es. De nosotros depende comprender o equivocarnos, seguir adelante con nuestros errores o aprender de ellos y rectificar.
Será que hoy me he levantado algo existencialista pero, yo qué sé, nunca he leído a Kierkegaard.

Siguiendo la tradición de todo lo que me atañe, cuando busco el conocimiento este siempre termina resultado algo esquivo. Pero no lo es porque esté escondido o porque me tenga manía, lo es porque gran parte de aquello que me interesa no se encuentra en el horizonte sino bajo nuestros pies.
Pero estoy divagando, algo intrínseco a mi ser y, detrás de cada nueva palabra viene implícito lo mismo que os comentaba el mes pasado: Yo tenía un plan.

Cada vez que me sumerjo en este océano de bits la información me golpea. Alguna la desecho, otra trato de asimilarla y otra, a pesar de tenerla presente me digo "esto para más adelante"... mientras no la dejo para más adelante.
Nos movemos sobre los hombros de gigantes (me repito). Gigantes que definieron el binario y el hexadecimal. Viajamos a lomos del legado de los Titanes que poblaron la era heroica. Quienes para escribir una línea de código tenían que diseñar la electrónica que transformaría la lógica en bits, y los bits en algo a ser presentada sobre una tarjeta perforada o un tubo de rayos catódicos. Eso cuando no tenían que desentrañar qué es la lógica.
Cuando más sé del pasado de esta afición más admiro a los precursores. Cuando más trato de avanzar en el conocimiento más me veo abrumado por lo que no sé o no entiendo. Cuanto más tiempo permanezco bajo estas aguas más me expongo a perderme y no avanzar, a perecer asfixiado por la sobredosis de datos. Cuando más sé, más me siento un impostor.
La historia de mi vida.

Y sí, yo tenía un plan. Yo tenía montones de planes.
Hace tiempo que tengo pendiente el escribir algo acerca de aquellos Titanes, aquellos Precursores, aquellos a quienes debo tanto. Algo que ya traté de plasmar hace años de manera torpe en la charla que di sobre este asunto en la Navarparty¹. Flaco favor que les hice.
Entre las notas de aquella charla aparecían los nombres de unos pocos de ellos, una lista que ha crecido desde entonces y que está cercana a alcanzar los doscientos nombres. Y siguen siendo pocos.
Muchas veces me pregunto qué puedo aportar yo. Qué puedo hacer para que este mundo sea un lugar un poco mejor y no, hacer un vídeo juego, un juego de rol, un libro o un tebeo no es la respuesta.
Lo único que se me ocurre que puedo hacer a ese respecto es hablar acerca de esas personas. En menor medida, también tengo pendiente el explicar por aquí el proceso y los productos de software libre gracias a los cuales esta web está disponible. Explicar las cosas que a diario aprendo en mi trabajo de una manera que puedan ser útiles para cualquiera. En definitiva, tratar de dar visibilidad a lo que han hecho otros más inteligentes que yo.
Porque ambas todas estas cosas están relacionadas. Hablar de lo segundo sin poner las cosas en su contexto me parecería una equivocación, más aún cuando mi objetivo es que esto vaya destinado a quienes carecen de una cierta base.

Hace un tiempo traté de sentar la base sobre la que construir esa narración. En aquel "Educando a los educadores"² trataba de despertar esa curiosidad pero, una vez más, fracasé (o lo dejé para "más adelante" demasiado pronto).
Pero la toalla no está aún en el suelo y algún día volveré a la carga. Sólo tengo que encontrar el momento y dar con la estructura y el tono correctos. Algún día lograré encontrar la manera de agradecer a esos gigantes que nos precedieron el hecho de en la actualidad se me pueda leer desde cualquier rincón del mundo y su extrarradio.
Aunque a alguno que otro este hecho les parece algo por lo que culparles.
Hasta entonces, trataré de hacer de estos textos algo lo más didáctico y accesible que me sea posible.

En fin.
Mes dos. ¿Cómo ha ido la cosa?
Lenta, pero el tema avanza. Aunque, hasta el momento, no he tirado ni una línea de código no he avanzado en el planteamiento del resultado que quiero para cuando finalice.

Y va lenta, en parte, por lo que comento ahí arriba. A causa de la razón por la utilizo software libre y por la que este reto ha tomado los derroteros que ha tomado. Y eso es algo que me parece bueno.
Porque quiero entender lo que hago para ser capaz de explicarlo con mis propias palabras. Porque quiero que lo que hago pueda resultarle de utilidad a otros y porque quiero todos aquellos de cuyos esfuerzos me he beneficiado tengan su reconocimiento.
En resumidas cuentas: Porque me parece que es lo correcto (y porque me lo puedo permitir).
Y no, nada de esto es sencillo. Es más, en algún momento cercano tendré que poner el límite de hasta dónde quiero profundizar. Puede que no hayamos venido aquí a hacer las cosas de una manera sencilla, pero tampoco es cuestión de perdernos en los preparativos.
La cosa es que, dependiendo de hasta dónde quieras bajar, algunos se empeñan en convertirlo en algo complicado de narices. Basta que encuentres algo que te gusta para que su licenciamiento te lo reviente (lo explico un poco más adelante).
Así pues, preparaos para otro alud de enlaces.

Pues sí, Érase una vez que quería hacer un juego y decidí complicarme la vida.
Con lo sencillo que habría sido decantarme por instalar Unity o GameMaker en un ordenador Windows y ponerte al asunto, dirá alguno. Y tendrían toda la razón de ser esto una queja, pero no. No lo es. Complicado no tiene porqué ser sinónimo de malo.

Hace años que dejé de utilizar Windows en casa. Primero fue por una cuestión legal, económica y de ética personal, y después... ha seguido siéndolo, aunque el peso de cada uno de estos factores ha ido cambiando de una manera drástica. El sistema operativo que tenía instalado en mis ordenadores hasta entonces siempre había sido pirata, y sabía que existía una opción legal y gratuita para poder utilizar aquellas máquinas. Así comenzó mi historia de amor (y odio) con Linux.
Porque la cosa es y está complicada. Mucho. Pero durante los primeros pasos siempre es mucho peor.
A finales de los noventa, cuando traté de pasarme al mundo libre, no sabía ni lo que era aquello. Para mi era el mundo gratis, un error de concepto comúnmente propagado. Pero tenía estaba cómodo con el parche en el ojo y el esfuerzo que me comenzaba a suponer aquello me hizo desistir. No hubo manera.
No sólo se trataba de la complejidad implícita del asunto sino que, añadido a esto, tenía mucho que desaprender en cuanto a lo que yo había deducido que era un sistema operativo (o un programa).
Después de aquello realicé alguna que otra intentona más, siempre con el mismo resultado. No fue hasta que decidí realizar el salto sin red, hasta que no me quedó otra opción que aprender o morir (porque retroceder nunca, rendirse jamás) que las cosas comenzaron a tener sentido en mi cabeza.
Había asistido a un curso de cincuenta hora en la hoy desaparecida FOREM y leído (siempre en diagonal) toneladas de documentación. Había instalado distintas distros en equipos secundarios y en máquinas virtuales pero, no fue hasta que decidí instalarlo en el equipo que usaba a diario que la cosa despegó.
Y esto no me sirvió sólo para aprender acerca de los sistemas operativos, sino que me abrió los ojos al aberrante mundo de las licencias de software. Pero ese es un tema a tratar con mayor detenimiento en otro lado (aunque si que dejaré un pequeño avance más adelante).

Volviendo al asunto de la programación, de la misma manera que yo he podido trabajar, aprender y divertirme gracias a las herramientas creadas y cedidas por otros de manera desinteresada, quiero que esto sea extensible a lo que hago. Es una cuestión de principios.
De utilizar herramientas que no son libres para este proyecto lo estaría desvirtuando. Como el lado oscuro, puede que sean más fáciles y atractivas, puede que sea el camino más fácil, quizás hasta el mejor de acuerdo a la lógica capitalista, pero no es el único.
Así pues, de la misma manera que el contenido de mis páginas se encuentra publicados bajo la licencia Creative Commons³, mi juego... o lo que termine saliendo de esto, lo hará bajo licencia GPL⁴.

Ciertamente para conseguir eso no es necesario que todas las herramientas sean libres pero, nuevamente, me parece el camino correcto.

¿Quiero decir con esto que el resto me parecen malos productos? ¿Que quienes no siguen este camino me parece que estén equivocados?
Nop. Simplemente este es el camino que he elegido yo.
Alguno de los tipos a cuya estela me encantaría acercarme⁵ no han compartido su código, y eso no disminuye mi fanboyismo por él y su obra.
Por la misma, y como ya comentaba antes, también estoy convencido de que de utilizar las herramientas que he mencionado antes mi trabajo mucho más sencillo. Y me parecen herramientas perfectamente válidas para quien “sólo” quiere hacer un juego y no quiere aprender a programar.
Otra gente⁶ sin las inquietudes (o sin el tiempo o las posibilidades) que me mueven a mi, sin necesidad de saber programación han creado gracias a estos motores proyectos de lo más interesante.

Pero, por más bonitos o atractivos que puedan ser, no tengo acceso a su código. No puedo aprender de ellos.
Por el contrario, sí que dispongo del código de todos estos otros⁷. Quizás no sean tan profesionales o tan bonitos, quizás no estén muy bien documentados. Quizás aún no haya sido capaz de compilar ninguno de ellos para que funcionen en mi ordenador, pero puedo mirar como se han devanado los sesos la gente que los ha creado, y ver cómo han solventado los problemas con los que me encontraré.
Y, ya que menciono a una de las bestias negras de la programación, voy a sacar a colación a los dos grandes misterios arcanos del desarrollo de software: Compilar⁸ y Buscar bichos⁹.

De cada programa cuyo código fuente me he descargado alguna vez, en primera instancia la compilación ha fallado en cerca de un noventa por ciento de ellos. Más adelante, en ocasiones gracias a la documentación que incluían, en ocasiones buscando en otras fuentes, he conseguido hacer funcionar a algunos de ellos... aunque sin terminar de entender lo que sucedía en segundo plano.
Uno (más) de mis objetivos para este resto es que esto no le pase a quien trate de compilar lo que yo haga. Digo esto desde la más completa ignorancia. A ver qué soy capaz de conseguir cuando termine.
El cuerpo me pide que empiece a explicar por aquí en qué consisten estas actividades, pero lo dejaré para alguna entrada posterior.

Por el momento, durante la última semana he estado probando distintos entornos de desarrollo¹⁰ sobre los que trabajar. Como en todo lo referente a casi cualquier terreno, en cuanto empiezas a bucear entre sus distintas especialidades, te encuentras en un nuevo mar en el que perderte, quedar paralizado o morir por sobredosis de datos.
Como podréis en los enlaces que acompañan a esto¹¹, los hay como para aburrir, y eso que sólo estoy poniendo los que están disponibles para Linux y tienen una licencia "amistosa" (no, aún no he llegado a esa parte de las licencias).

Mientras los investigaba iban saliendo nuevos misterios por resolver. Algunas como GCC, G++ o Make me sonaban, pero otras como Cmake, Clang, pese a haber leído con anterioridad sus nombres, no tenía idea acerca de su cometido.
Algo similar pasaba con la cacería de bichos, el "Debug". Por más que había leído este palabro con anterioridad, no tenía ni idea de lo que implicaba.
Habiendo trabajado hasta ahora con lenguajes de scripting¹² no había necesitado de ninguno de estos dos componentes y, como ya he comentado por ahí arriba, tengo la impresión de que van a ser mis bestias negras.

Así pues, en este punto en el que me encuentro prima entender cada paso que voy a dar. Ser consciente del flujo de los datos y en qué estado se encuentra en cada momento, algo para eso un IDE con un buen degugger es esencial.
Pero, por otro lado, estos IDEs me ocultan otra serie de procesos. Principalmente el de compilado, linkado y la transformación final del código en un binario ejecutable.
Como consecuencia de todo esto, los IDEs acostumbran a ser programas que consumen muchos recursos al ordenador en el que se ejecutan, algo que tiene todo el sentido del mundo. Lo que pasa es que yo soy muy maniático con esas cosas. La herramienta con la que trabaje tiene que hacer sólo lo que tiene que hacer. Si hay algo de lo que pueda ocuparme yo prefiero no delegarlo a otros procesos que no lo harán "como a mi me gusta".

Con esto en mente, la lucha estaba servida. El primero en caer fue CodeBlocks por su alta inestabilidad, y no tardaron en seguirle Eclipse y Netbeans, ambos hechos en Java y muy pesados.
La pelea quedaba pues entre Atom (un proyecto que sigo desde que estaba en fase Beta y al que tengo especial aprecio), Visual Studio Code, KDVelop y QT-Creator.
Los dos últimos son IDEs puros, mientras que los primeros son editores de textos modulares. Así pues, en un primer momento son más ligeros y versátiles pero, en cuanto empiezas a añadirles módulos empiezan a hacerse más lentos y pesados.
Me habría encantado centrarme en Vim o EMACS, porque son tanto o más ligeros, minimalista y versátiles que los otros editores, pero la curva de aprendizaje que requieren ha provocado que esto quede aparcado para más adelante.

Pero, cuando la cosa estaba casi decidida por Visual Studio Code (a Atom, probrecico mío, hasta le cuesta mover el documento que tengo con los enlaces para esta entrada), me dio por mirar su licencia... y no es ni libre ni abierta. Al menos no la de la versión que te puedes instalar desde los repositorios de Microsoft¹³. Gracias Microsoft. Vete a paseo Microsoft.

En estos momentos tengo la versión con licencia abierta compilada en mi equipo pero, a pesar de todo, me están entrando ganar de mandarlos a paseo. Algo que no descarto hacer cuando ya me encuentre más suelto en estas lides.

Aparte de todo esto, también me he sumergido algo más en el mundo de la programación. Me encuentro cerca de terminar “Beginning C++ Through Game Programming”¹⁴ que, si bien adolece de lo mismo que otros libros, al menos hace un esfuerzo por acercarse a los terrenos en los que me quiero mover. Aún así, las constantes, las variables constantes, los punteros constantes a variables dinámicas, y punteros dinámicos a funciones constantes me siguen provocando pesadillas.

Y he seguido bajando más aún, acercándome al mundo del ensamblador en su vertiente más viejuna. Ensamblador para el Z80 y Moss 6502¹⁵. Y, por más apasionante que sea (dicho esto sin ironía alguna) aún me duele la cabeza. Aunque volveré, ya lo creo que volveré.

Para hacerme una idea en cuanto a magnitud, también he sacado estadísticas de la cantidad de imágenes, líneas y palabras contenidas en el código de varios juegos que me he descargado. Que tampoco es que me digan gran cosa, pero me permiten hacerme una idea en cuanto a orden de magnitud general (y comenzar a asustarme).

uMario (Clon de Super Mario Bros con SDL)
20.949 líneas 122 archivos	417 assets	58.829 Palabras
SDLPoP (Clon de Prince of Persia con SDL)
24.888 líneas 38 archivos	1091 assets	88.685 Palabras
Mirror Magic (Clon de Deflektor)
27.760 líneas 46 archivos	201 assets	79.055 Palabras
Xarchon  (Clon de Archon)
24.008 líneas 81 archivos	519 assets	79.483 Palabras
Contra  (Clon de Contra, versión NES)
10.214 líneas 36 archivos	20 assets	28.565 Palabras
RickyD  (Clon de Rick Dangerous con SDL)
30.073 líneas 194 archivos	344 assets	80.202 Palabras
Xrick  (Otro clon de Rick Dangerous con SDL)
56.444(sources)+1.715 (includes) líneas 50+29 archivos  134.516 + 6.429 Palabras

Para recuperarme de estos traumas también me he dedicado a ver las charlas que han dado distintos autores de videojuegos en las charlas de la GDC¹⁶ y creo que por hoy ya vale.

Me he dejado en el tintero otro montón de cosas. Más sobre las librerías de funciones, cobre SDL, y SFML, sobre Bennugd y Allegro, PyGame y PySDL2, sobre ISTQB e ITIL (de las que ya pondré enlaces el mes que viene), pero ya toca dejaros. Tengo retos que retomar.

Enlaces:
1. Conferencias Navarparty 9 - Historia de la ínformática (Ver sólo si se cuenta con apoyo psicológico, que la di yo)
2. Educando a los educadores
- El pueblo (no) quiere saber
- ¡LOS ESTÁNDARES!
- ¡LAS LICENCIAS I (Glosando)
3. Creative Commons
4. GNU (General Public License)
5. Con ustedes: Brian Provinciano
Retro City Rampage
Entrevista a Brian Provnciano en Gamasutra
Port de Retro City Rampage para NES
AMA a Brian Provinciano en Reddit
Charla Brian Provinciano en GDC de 2016
6. Los otros
- Locomalito
- Diego Sanches
- Science Kombat
7. Juegos con código fuente
- Open Source Game Clones
- Listado de juegos en Github
- Super Mario en SDL2
- Código original de Prince of Persia para Apple II
- Prince of Persia con SDL
- Prince of Persia con JavaScript
- Prince of Persia con Roku Brightscript
- Xrick (Clon de Rick Dangerous)
- Xrick para XCode (Mac)
- RickD (Clon de Rick Dangerous)
- Contra (NES)
- Mirror Magic (Deflektor)
- XArchon
8. Compilar en Linux
- Compilar
- GCC / G++
- Make
- Cmake
- Clang
- Tutorial Cmake I
- Tutorial Cmake I
- Configurar Visual Studio para Torque 3d
9. Debug en Linux
- Safari binario
- The GNU Project Debugger (GDB)
- GDB Debugger Command Cheat Sheet
- GDB front ends and other tools
- DDD
- Valgrind
- Zerobugs
10. IDE (Integrated development environment)
11. IDEs para Linux
- Atom
- Codeblocks
- Eclipse
- EMACS
- Kdevelop
- Netbeans
- QT-Creator
- Visual Studio Code
- Vim
Comparativas IDEs / Debuggers para Linux
- I
- II
- III
Módulos para Visual Studio Code
- C++ en Visual Studio Code I
- C++ en Visual Studio Code II
- Creación de tareas en VSCode
- Proyectos en Visual Studio Code
- Code Runner para VSCode
- Ensamblador para C64 en Visual Studio Code
- Charla VSCode para programar C++ 1 (Video)
- Charla VSCode para programar C++ 2 (Video)
Módulos para Atom
- C y C++ para Atom
- Compilación de C y C++ en Atom
- Compilación y ejecución de C y C++ en Atom
- Lint
- Linter para GCC en Atom
- Depencia para Linter para GCC I (Intentions)
- Depencia para Linter para GCC II (linter UI default)
- Depencia para Linter para GCC I (linter)
- Compilación en Atom
- Herramientas de compilación para C++ en Atom
- CMake para Atom
- Proyectos en Atom
12. Scripting language
13. Licencias de Visual Studio Code
- Binarios oficiales
- Código sin compilar
14. Libro Beginning C++ Through Game Programming
15. El Ensamblador, ha llegado el Ensamblador
- El lenguaje ensamblador
Profesor Retroman
- Nivel 0 - Presentación (Videos)
- Nivel 1 - Teoría (Videos)
- Nivel 1 - Práctica (Videos)
- Nivel 2 - Teoría (Videos)
- Nivel 2 - Teoría (Videos)
- Nivel 2 - Práctica (Videos)
C64 assember programming
- Debugger para C64
- An x86 to 6502 Re-Assembler (Video)
- Part 1: How The Memory Map Worked (Video)
- Part 2: Intro to 6502 Machine Language (Video)
- Part 3: Intro to 6502 Assembly (Video)
- Pacman Clone for C64 (Vídeo)
16. Charlas GDC - Postmortem
- Prince of persia
- Another world
- Another world Director Commentary by Eric Chahi
- Marble Madness
- Pitfall
- Diablo
- Doom

Javier Albizu Mié, 07/03/2018 - 21:19

Bajo un océano de bits, mes III

¿Recuerdas que el mes pasado te dije que no quería meterme con Vim o Emacs por el tema de la curva de aprendizaje y tal?
… pues al final me he terminado metido con Vim y… bueno... no es para tanto¹ (dice mientras tensa la soga que cuelga del techo). Pero bueno, por el momento me sobran unos cuantos puntos de cordura. Además, ¿qué diablos? si uno quiere ir de tipo duro tiene que apechugar con lo que va asociado.
Y, oye, no te voy a mentir, aunque aún no les he echado un ojo a todos los módulos que aparecen listados por ahí abajo, meterme con eso ha sido una de las cosas más entretenidas que he hecho durante las últimas semanas (así que te puedes hacer una idea de cómo han sido el resto de cosas). Porque ha sido un mes durillo.
Era un tema que tenía pendiente desde hace mucho (los enlaces con el curso de Vim que dan comienzo a la retahíla de cosas relacionadas los tenía perdidos por el disco duro desde hace unos cuatro años) y me dije, hoy es un día tan bueno como cualquier otro para que me encierren. Una vez dicho eso los miré durante diez minutos, no les volví a hacer caso (aunque los sigo considerando material pendiente) y me dediqué a surfear por la red en busca de recomendaciones.

Más allá de eso la cosa no ha avanzado demasiado porque en marzo se han solapado aún más cosas de las habituales. Terminar con el puñetero libro que empecé el mes pasado ha sido un dolor y no me ha terminado de dejar las cosas todo lo claras que me habría gustado. Una parte muy importante de la culpa ha sido mía, pero la cabeza no me daba para más y por eso me ha dado por lanzarme a los brazos de Vim algo que, técnicamente, también encajaba como parte del reto.

¿Y qué ha tenido de complicado el mes? Preguntaréis.
Por un lago tocaba trabajar durante más horas y en jornada partida (algo cíclico y que ya sabía con antelación) pero, añadido a esto, y también por motivos laborales, me he sacado una certificación de ISTQB². Si sumamos el curso, el estudio para el examen, la jornada partida, los tres retos presentes, el quedar con la gente y el rato dedicado a hacer el vago mi tiempo se ha visto muy comprometido. Pero más allá del tema meramente organizativo tenía la cabeza a cada momento diciéndome lo que aún no había hecho.

Volviendo al tema de la certificación, y agarrándome a los detalles de matiz, en ocasiones he asumido que el tiempo que le dedicaba también contaban como parte de este reto. Quizás aún no vaya a dar uso a ese conocimiento, pero tengo claro que más adelante me puede venir bien. Porque, a pesar de tratarse del nivel de certificación más básica, el tiempo dedicado al curso no ha sido un desperdicio y me ha permitido abrir los ojos a otros temas también relacionados con esta labor; La toma de requisitos para un programa. Al mismo tiempo también me ha metido el miedo en el cuerpo descubriéndome conceptos como la “Complejidad ciclomática”, la “Explosión combinatoria” o el TDD (algo de lo que también he encontrado una charla por parte de Brian Provinciano) que también enlazo por ahí abajo.
Tengo intención de integrar todas las cosas que utilizo en el día dentro de la gestión de proyectos de software para este reto. Tengo claro que tanto ISTQB como ITIL³ están orientadas a la gestión de equipos de distintos tamaños, que sólo tengo la certificación más básica en ambas… y que estoy totalmente sólo en esto, pero eso no tiene que impedirme el ser metódico. Es más, uno de los grandes problemas que estoy teniendo con esto es que no tengo una manera de “cuantificar” mi avance. Con el dibujo o la escritura es muy sencillo pero con la programación aún estoy lejos de ver cualquier resultado.
Utilizando la jerga del trabajo, me voy a tener que ir cambiando de gorras cada dos por tres. Hacerme las preguntas que me tendrían difíciles que me tendrían que hacer los distintos gestores, porque aquí soy “Negocio”, “Gestor de proyecto”, “Analista”, “Tester”, Diseñador” y “Desarrollador”. La esquizofrenia está servida. Así pues, toda ayuda que puedan darme las herramientas o las técnicas de trabajo espero que aporten en aquellos aspectos en los que me encuentro más flojo.
Gracias al curso de ISTQB he descubierto una herramienta (que no deja de ser una hoja de cálculo glorificada) para la toma de requerimientos en un proyecto de software; Testlink (también en el mismo bloque de enlaces), y cuando yo como “Gestor” me pregunte a mí mismo como “Negocio” cada detalle de lo que luego, y ya como “Desarrollador” debo convertir en código espero que su estructura me ayude a ser lo más concreto posible.

De todas formas, la opción final por Vim no se ha debido en exclusiva a mi rebote con el tema del VSCode. Como ya decía, quiero montar mi entorno de desarrollo desde el nivel más bajo que pueda. Quiero quitar de mi cabeza el pensamiento mágico, el decir “seguro que hay un programa que hace esto” y tratar de profundizar en cada paso. Al final todo es código. Código escrito por otros.
Por supuesto, tengo que marcarme unos límites. Con mi nivel de conocimiento actual soy incapaz de comprender el 99,9% de las líneas de código que leo y soy consciente de que el montarme este entorno sólo me aporta una falsa sensación de control. Cuando tenga una mejor comprensión de todo seguramente haga el camino inverso y me pase algún IDE tocho pero, por el momento, con lo que tengo me basta y me sobra para continuar avanzando.

Aún no he empezado a hacerme las preguntas en serio acerca de los detalles técnicos o funcionales del juego, ni he elegido una biblioteca de funciones con las que implementarlos, pero es que de estoy último hay para aburrir⁴, y lo uno es algo dependiente de lo otro. Existe una infinidad de maneras de hacer cualquier cosa, y cada uno de los pasos que intervienen tienen su aquel⁵.

Una vez que terminé con el libro que tenía en curso la impresión acerca de lo que eran los objetos⁶ se confirmó pero, aún así, sigo sin tener clara en la cabeza cómo se estructuran, y eso es algo que me va a costar. Me da la impresión de que nunca voy a poder afirmar sin sentir que estoy mintiendo que “sé” programar. Porque para mí “saber” algo implica no depender de otros elementos. Implica no tener que consultar, y eso en la programación es algo imposible. Y no sólo eso, la cantidad de cosas a consultar para cualquier nimiedad es abrumadora.

Como decía, acabé el libro y tocaba decidir por dónde continuar. Al final opté los cursos de SDL de Lazyfoo porque… foo⁷(jijiji), y porque en una de sus lecciones se trata el tema de la creación de un editor de mapas. Y ahí seguimos… perdidísimos.
Para pintar una puñetera ventana en pantalla con una imagen de fondo y otra en primer plano con SDL usamos más de media docena de funciones y el archivito de marras ya ocupa casi doscientas cincuenta líneas. Pero ese es el menor de los problemas.
He tratado de mirar qué narices hacen esas funciones⁸ y no he sido capaz de acercarme a saber dónde narices estaban dentro del código de SDL. Sólo he llegado hasta los archivos de cabeceras (que tampoco he sabido interpretar), o a cómo se invocan dentro de sus APIs⁹. Pero bueno, no hay problema, tengo tiempo. A fin de cuentas SDL sólo tiene ¡¡¡QUINIENTAS TREINTA Y SEIS!!! de esas.
El tema de las APIs y los objetos ya lo he manejado en otros leguajes de scripting, pero nunca he tenido que crear cosas demasiado complejas y, en el caso concreto de Powershell, el entorno que proporciona Microsoft y la cantidad de información existente en la red facilita bastante la cosa, pero aquí, por más libros o webs que se hayan cruzado en mi camino, navego totalmente a ciegas.
A este paso dudo que para dentro de dos años sea capaz de hacer que nada se mueva en la pantalla. Porque esa es otra, todo el tema gráfico lo tengo abandonadísimo. Esta semana santa traté de recuperar el lápiz sin erótico resultado, tanto es así que terminé recurriendo a copiar… a medias lo que tenéis por aquí.

Sigo sin ser capaz de formar imágenes mentales. Para mí las formas no son imágenes sino descripciones verbales. Entiendo los conceptos de las formas, pero en mi cabeza sólo están sus definiciones. Sólo pienso con palabras, no con representaciones gráficas. Cuando leo un libro no soy capaz de formar algo visual en mi cabeza a partir de las descripciones, sólo son elementos sueltos. Tanto es así que, desde que supe de su existencia, en más de una ocasión me he preguntado si tengo afantasía⁹. No sé lo que quiero ver plasmado, sólo lo que quiero que sienta quien lo ve. No soy capaz de ver las líneas hasta que ya están en el papel e, incluso llegado ese momento, no soy capaz de concretar lo que falla o lo que quería dibujar. Sólo sé que está mal.
Y no quiero copiar, pero no sé dibujar algo que no sea genérico sin hacerlo. Parece que los del gusto y el olfato no son mis únicos sentidos atrofiados.
Cuando escribo me pasa algo similar. Sé todo lo que pasa por el interior de mis personajes, se lo que quiero contar con la historia, lo que me gustaría transmitir, pero no tengo ni idea de qué aspecto tienen, cómo les gusta vestirse o de qué tono es su piel.

Pero me estoy desviando. Estaba con mi evocador canto a la programación.
Mirando un poco por encima, SFML tiene menos objetos y estos no son funciones sino clases¹¹. Apenas llegan a cien… pero no tengo ni idea de si esto es bueno o malo. Si esto limita sus posibilidades o internamente cuántas funciones habrá definidas dentro de cada clase.
No sé si será más sencillo de aprender o más complicado. Lo que sí que sé es que he encontrado más libros en los que se habla de SFML que de SDL
Pero bueno, dejaré esa decisión para cuando termine con Lazyfoo.

Una idea que me lleva dando vueltas por la cabeza desde hace mucho es la de hacer un clon de mi añorado TRAZ¹² para ir calentando, pero aún estoy muy lejos de hacer siquiera un clon del Muro para Spectrum.
Encontrar cualquier información sobre desarrollo de juegos en Linux¹³ está complicado. O los recursos son demasiado genéricos, demasiado avanzados. Por el contrario, y aunque usen bibliotecas multi plataforma como SFML para Windows la cosa es bastante más asequible. Tanto es así que los libros que he comprado están todos centrados en Visual Studio y Windows.
Así pues, aunque dicen que “Hey, las bibliotecas también funcionan en Linux”, el código de los ejemplos peta porque el VS añade unas cabeceras para precompilar, y las rutas donde se encuentran los fuentes están configurados en el IDE y no en los propios archivos.
En fin, yo no desisto.

También he seguido viendo vídeos de las GDC¹⁴, un batiburrillo un tanto anárquico de temas muy interesantes… no siempre tan bien explicados como me gustaría, pero de lo que siempre se sacan ideas.
Y hablando de sacar ideas, también he conocido el canal de José Altozano (aka Dayo o DayoScript)¹⁵, quien ha venido a cubrir el hueco de mis añorados Bukku qui¹⁶ como mi crítico de vídeo juegos de cabecera.
El visionado de su canal ha consumido gran parte de mi tiempo de la semana santa y como sucediese con los Bukku, me estoy viendo todos los vídeos que ha subido de manera secuencial desde el principio. No coincido con gran parte de sus gustos, inquietudes y opiniones, pero me ha resultado una sorpresa de lo más agradable, ha conseguido que me plantee alguna que otra cosa para este proyecto, y su evolución a lo largo del tiempo es palpable.
Supongo que me ganó con su entrevista en el AMA de Vodafone, donde hablaba de temas que me resultan tan cercanos como la inseguridad y la autoría.

Y bueno, creo que eso viene a ser más o menos todo. Te dejo, que me quedan muchas cosas para hacer en lo que queda del día.

Enlaces:

2. ISTQB
- International Software Testing Qualifications Board (ISTQB)
- Testlink
- Complejidad ciclomática
- Explosiones combinatoria
- TDD (Test driven development)
Más de Brian Provinciano
- Su web
- Su charla sobre como diseñó sus pruebas
- El script con el que grababa y "rejugaba" las partidas de prueba
- Y la transcripción de la charla

3. ITIL

4. Bibliotecas de funciones
Bennugd
- Bennugd
- Getting Your Feet Wet in SDL, The Pong Clone!

SDL
- SDL
- Estructura y funciones de la API de SDL 2
- Libro Sdl Game Development
- Making A Game with C++ And SDL2 (Videos)
Lets Make a Game in C++ and SDL
- Lets Make a Game in C++ and SDL I (Video)
- Lets Make a Game in C++ and SDL II (Video)
- Lets Make a Game in C++ and SDL III (Video)
RPG con SDL
- RPG con SDL (Video)
- RPG con SDL
Desarrollando para SDL / Linux
- Steam Dev Days 2014 - Game Development with SDL 2.0 (Video)
- Steam Dev Days 2014 - Getting Started with Linux Game Development (Video)
LazyFoo SDL
- Tutorial LazyFoo SDL
- LazyFoo SDL Editor de mapas I
- LazyFoo SDL Editor de niveles

SFML
- SFML
- Tutoriales para SFML
- Estructura y funciones de la API de SFML
- SFML Game Development By Example
- Beginning C++ Game Programmingi
- Mastering SFML Game Development
- Game Physics Cookbook
- Gamecodeschool - Sfml-projects
- Gamecodeschool - Making games where do I start/
- Gamecodeschool - Building your first sfml game project
- Gamecodeschool - Building a simple game engine in C++/

OpenGL
- Opengl GLUT
- LazyFoo OpenGL
- Curso Udemy Modern OpenGL C++ 3D Game Tutorial Series & 3D Rendering

Xlib
- Xlib

Allegro Framework
- Web de Allegro
- Wiki de Allegro
- Allegro Wikipedia
- Buckys C++ Programming Tutorials
- Action Arcade Adventure Set (Libro 1994)

PyGame
- PyGame
- Wiki PyGame
- Invent Your Own Computer Games with Python
- Invent Your Own Computer Games with Python (PDF)

PySDL2
- PySDL2
- Documentación PySDL2
- Invent Your Own Computer Games with Python para PySDL2
- Invent Your Own Computer Games with Python para PySDL2 (Github)
- Hilo Reddit Python para crear juegos

Recursos para Python
- Awesome Python
- Awesome Python - Game Development
- Learning Python Application Development

5. Lo que cuesta pintar cualquier cosa en pantalla
6. Programación orientada a objetos
7. Foo
8. Funciones
9. Application programming interface (API)
10. Afantasía
11. Clases

12.Traz
- Ficha en Lemon64
- El único vídeo que he encontrado sin que nadie hable

13. Desarrollar juegos en Linux
- Desarrollo para SteamOS
- Video Game Programming - comprehensive foundations
- Curso de algoritmos en Khan Academy
- Creating a Basic Game Engine
- Game From Scratch C++ Edition
- Learning to game dev on linux resolutiion is a zelda like in the making

Crear el motor
- Crear editor de niveles
- Blog de Thimbleweed Park (254 entradas)/a>
- Planet X3 (8 Bit Guy)

Making a Game Boy game in 2017: A "Sheep It Up!"
- Parte I
- Parte II
- Y en castellano

14. Más charlas del GDC
- Math for Game Programmers: Building a Better Jump
- 8 Bit & '8 Bitish' Graphics-Outside the Box
- Tech Toolbox for Game Programmers
- Physics for Game Programmers: Understanding Constraints
- The GDC 2015 Live 2D Animation Demo

15. DayoScript (José Altozano)
- Dayo en Yutube
- En Eurogamer
- Entrevista en AMA (Ask me Anything) de Vodafone

16. Bukku qui

Javier Albizu Mié, 04/04/2018 - 20:00

Bajo un océano de bits, mes IV

Como no podría ser de otra manera, comienzo una entrada con una rectificación sobre algo relacionado con lo que afirmaba en la anterior.
El curso de LazyFoo no me sirvió. Lo tengo aparcado para más adelante (uno más), pero a través de sus explicaciones no conseguía avanzar. Así que tocó seguir buscando y desesperando, escudriñando la red de redes hasta que. parece que, esta vez sí, he ido a dar con algo que se asemeja mucho a lo que llevaba buscando desde el principio. Hasta el tutorial de SDL de Antonio García Alba¹.

No es perfecto, y entre los contras se encuentra que el tutorial no trata la versión 2 de SDL sino la primera, aunque claro, esto tiene todo el sentido del mundo. Está escrito en dos mil ocho, y por aquel entonces no había alternativa. Por lo demás, la materia en sí misma no deja de ser muy complicada para mi nivel de conocimiento, pero eso es algo totalmente ajeno a este tutorial en concreto.
Voy lento, y algunas cosas se me siguen escapando, pero el texto es bastante claro y baja hasta un nivel en el que creo que puedo llegar a entender lo que explica, algo que echaba en falta en el resto. Tengo intención de ponerme en contacto con este buen hombre cuando algún momento de estos para agradecerle su trabajo. Por lo pronto ya me he puesto en contacto con la gente de la Universidad de Cádiz para darles las gracias e indicarles alguna errata en el código de alguno de los ejemplos.

Aún así son casi setecientas páginas, por lo que a la cosa aún le queda para rato. Más aún cuando me estoy planteando hacerlo todo en SDL1, SDL2 y, quizás, SFML y OPENGL. Porque esto va de aprender.

Más allá de esto… no he avanzado mucho más. He visto más vídeos de las GDC², gracias a una de ellas descubrí la existencia de Box2d³, un motor de físicas para juegos en 2d de código abierto y escrito en C++, he hecho un dibujo para cubrir ese cupo del mes, aunque tampoco me sirva para nada en el juego, y he descubierto que en la página de Mozilla⁴ también tienen guías para la creación de juegos. Más deberes para cuando llegue el momento.

Bueno, y dudas. Montones de dudas y preguntas acerca de qué será o dejará de ser el juego. Si, a pesar de ser un plataformas en 2d, trataré de contar una historia a través suya o me limitaré a que las mecánicas sean su eje motor.
Porque claro, estará ambientado en Daegon (hasta que cambie de idea, y vuelva a cambiar de idea, y…) y tengo historias de sobra para contar ahí… aunque esto no deja de ser un problema.
Mi intención es el dar la posibilidad de que los jugadores puedan elegir entre personajes de distintos sexos, pero esto tendría que ser algo más que un mero cambio estético. Cada personaje, por más que recorra el mismo camino, debería tener y contar una historia propia, tener unas físicas diferentes, moverse de una manera distinta.

Para terminar de sabotearme, recientemente me golpeó otra verdad que, por más obvia que sea, no me había planteado hasta el momento. Escuchando un podcast en el que uno de sus colaboradores tiene una deficiencia visual severa, ante el comentario de alguno de sus contertulios acerca de cómo la tecnología nos hacía dependientes, pasó a describir la manera en la que le había cambiado la vida, y muy para bien, a él y a otros en situaciones aún más desfavorecidas. Cómo es su caso no era dependencia lo que implica todo esto sino todo lo contrario.
Y es que no es necesario estar ciego para no ver. Por más concienciado que creas estar, es muy sencillo obviar todo lo que no nos toca directamente. Porque cuando pienso que me gustaría que mi juego pudiera ser disfrutado por todo el mundo, el mundo en el que pienso es muy reducido.

Y me gustaría hacer un juego que pudiesen disfrutar lo ciegos o toda esa gente en cuyas situaciones no soy capaz de ponerme.
Va a ser un arcade, sí, y eso no deja de ser un factor limitante pero, pero este factor sólo debería impactar en cuando a los gustos y nada más.
Sé que existen dispositivos de entrada para que gente con movilidad reducida escriban o jueguen con el movimiento de sus pupilas, así que asumo que esa gente podría jugar (aunque tengo que asegurarme de que esto sea un hecho), pero no tengo la más mínima idea acerca de su un invidente puede jugar a un juego de este estilo, y apenas he encontrado información a este respecto.
Y me meto en estas disquisiciones cuando aún no tengo la más mínima idea dónde me estoy metiendo.

Pero bueno, la noche es joven y la red proverá.

Enlaces:

1. Tutorial de libSDL para la programación de videojuegos
- Supongo que es este zagal
- Formato Wiki
- Formato PDF
- Documentación de SDL 1

2. Más vídeos de las GDC
- Designing with Physics: Bend the Physics Engine to Your Will
- WHAT ARE "TIGHT" CONTROLS? - Movement in Games
- Rogue Legacy Design Postmortem: Budget Development
- Level Design in a Day: A Series of First Steps - Overcoming the Digital Blank Page
- Math for Game Programmers: Juicing Your Cameras With Math
- Math for Game Programmers: Fast and Funky 1D Nonlinear Transformations
- Concept Art is Dead
- 8 Bit & '8 Bitish' Graphics-Outside the Box

3. Box2d
- Su web
- Su repositorio en GitHub

4. Guías de Mozilla para hacer juegos

Javier Albizu Mié, 02/05/2018 - 21:36

Bajo un océano de bits, mes V

Cinco meses después seguimos sin haber picado una sola línea de código propio. Aun así, la cosa avanza.
Cuando no estoy pensando en que esto no me va a terminar de entrar en la cabeza en la vida, hasta logro emocionarme al lograr entender algo. Me reafirmo en el comentario del mes pasado en el que decía que el curso de SDL de Antonio García Alba era el mejor encuentro aleatorio que me podía haber salido en el camino.

Pero cuesta, vaya si cuesta.
Aunque... ¿qué diablos?. Si uno montón de chavales de quince años pudieron hacer juegos en ensamblador sólo con los medios disponibles hace más de tres décadas, esto no va a poder conmigo.
O al menos eso me repito una y otra vez.

Llevo ya más de cincuenta ejercicios del curso completados y he logrado hacerlos funcionar todos. Para algunos de ellos he necesitado tirar de la gran G, y ha sido de esos de los que más he aprendido, pero aún estoy muy lejos de ser autónomo o de verme capaz de entender y asimilar todo lo que estoy copiando.

Ando siempre a medio camino entre la versión Wiki del curso y el PDF. Por un lado, la wiki es más cómoda a la hora de copiar el código de los ejemplos pero, no sé si porque han hecho alguna conversión automática del texto de otro lado, o vete tú a saber porqué razón, me sigo encontrando con ejemplos que están mal transcritos.
El PDF me da una mejor visibilidad del avance, y además tiene algún ejemplo que no aparece en la wiki, pero cada vez que tengo que copiar uno de ellos la cosa es un poco infernal y tengo que andar quitando números de línea, puntos y comas a saco.
Debería escribirlos yo a mano en lugar de hacer un copia pega, pero… pereza.
Pero bueno, por el momento no me he tenido que saltar ninguno de ellos movido por la desesperación, y eso me parece todo un logro.
Eso sí, al menos ya le tengo pillado el truco al script de compilación.

Ya he terminado con las lecciones dedicadas a las bibliotecas principales y las auxiliares, y en estos momentos me encuentro animando sprites.
En la sesión de ayer logré que arrancasen dos de ellos, pero no hace caso a las órdenes que le doy desde el teclado, así que va a tocar investigar, y eso es algo que, aparte de ser un poco coñazo en ciertos momentos, me hace entender las cosas mejor, lo que es bien.
Puede que no avance demasiado rápido en este curso y por momentos eso resulta frustrante, pero no estoy dispuesto a dejar pasar ningún un ejercicio sin hacerlo funcionar.

Por otro lado, a cada paso que doy se me abre otro nuevo frente. Más detalles cuya existencia ni me había planteado y que lo hacen todo aún más complejo, pero esta ha sido mi elección.
Mi elección, mi funeral, que diría el amigo Logan, pero es lo que hay y esa decisión se sigue manteniendo firme.

También he conseguido compilar las versiones SDL de Prince of Persia, Rick Dangerous y Super Mario Bros. Eso sí, cada vez que me pongo a leer su código no tengo la más mínima idea de por dónde seguir (y en algunos casos ni siquiera sé por dónde empezar a mirar).
Y sin embargo se mueve(n).

En el resto de embolados en los que me voy metiendo la cosa tampoco ha estado parada.
Por un lado, el tema de la accesibilidad está aún muy verde, y no sólo por mi lado. Apenas hay información pero por lo menos una de las grandes (EA), ya ha comenzado una iniciativa a ese respecto. Claro, EA (bueno, uno de ellos) es el mal y esta iniciativa no ha sido algo impulsado desde las altas instancias. Todo ha venido instigada por una desarrolladora sorda que tienen en plantilla¹, y no sé cuánto tiempo, dinero y esfuerzo le van a dedicar, pero es un comienzo.

Ha dado también a casualidad de que, otra de las grandes, Microsoft en este caso, ha sacado durante este mes un nuevo mando para la X-Box orientado a la accesibilidad². No sé cuál será su utilidad real, si será algo de largo recorrido o un mero ejercicio de márketing, pero es más que nada.

Por el momento lo único que tengo claro es que voy a tener que dedicarle más tiempo del previsto al tema del sonido, los menús y la vibración del PAD. Tengo ideas pero, para no variar, el esfuerzo que me puede llegar a implicar es una incógnita. Y ya van...
Igual cuando la cosa avance (otra incógnita más), trato de buscar por las redes a gente con distintas discapacidades para ir ganando esas perspectivas, pero tiempo al tiempo.

Cambiando de ámbito, también ha aparecido por el horizonte una herramienta más; en proyecto español diseñado para analizar el código fuente de otros juegos llamado ViGaSoCo (Visual Game Source Code)³.

En su “léeme” se puede… leer lo siguiente:

VIGASOCO es un framework diseñado para entender como funcionaban algunos juegos clásicos.
Su propósito principal es ser un instrumento de aprendizaje para comprender el funcionamiento interno de los juegos.

Los juegos soportados por VIGASOCO son conversiones "funcionalmente equivalentes" de los juegos, escritas en C/C++ y obtenidas mediante reingeniería inversa del código original del juego.

Por el momento, y por lo que he logrado sacar en claro, sólo está para Windows pero existe un proyecto para portarlo a SDL y, por lo tanto, hacer que pueda correr en otras plataformas. Lleva parado un par de años y, por el momento, al utilizar algunas de las APIs de Windows, no compila en Linux (o al menos yo no he sido capaz de hacerlo).

Aún me pierdo mucho con los vaivenes de este proyecto pero, por lo que me ha parecido entender, nació para analizar el funcionamiento de la Abadía del Crimen (aunque también mencionan por algún que otro lado al Pac-Man).
A priori no se adapta al proyecto que tengo en mente, pero sí que tengo curiosidad por ver cómo está armado un juego en perspectiva isométrica (aunque me temo que habrá por en medio mucha matemática de la que no me enteraré).

¿Hemos acabado?
No. Aún queda más.

Este mes también han tenido lugar dos eventos retro.
Sólo he podido ir a uno de ellos, RetroMadrid, más por la gente la que iba a ver fuera de la feria que por la feria en sí misma, pero ha tenido cosas interesantes que ya están disponibles en el Tutubo⁴ y de las cuales aún me queda alguna por ver.

La otra feria, Explora Commodore⁵, ha tenido lugar en la zona más conflictiva de la ¡¡¡España!!! actual; Barcelona. No he podido ir con gran dolor para mi corazón Commodoriano, pero estoy tratando de hacer un seguimiento a las cosas que se han presentado por ahí. Algún día llegará Daegon para el C64, recordadlo.

Dentro del terreno retro también he hecho un descubrimiento esta última semana; The New 8-bit Heroes⁶, un proyecto de documental sobre la gente que hace juegos para 8 bits en la actualidad, y un curso para quienes quieren lanzarse a ello.
Algún día…

Y eso es más o menos todo por hoy. Por supuesto han habido más cosas. Más vídeos de la GDC⁸, he mirado un poco más acerca de Vulkan⁹, quien vaticinan que será el sucesor de OpenGL, y también ha caído algún que otro artículo interesante¹⁰.

Y la rueda no para. (Quizás) El mes que viene más.

Enlaces:

1. Sobre la accesibilidad en los vídeo juegos
- AAA Gaming While Blind
- Karen Stevens
- Portal de accesibilidad de EA

2. El nuevo mandaco de X-Box

3. VigasocoSDL (VIdeo GAmes SOurce COde)
- Proyecto original
- Sitio original
- Repsitorio en GitHub
- En ensamblador
- Cuenta de Tuister
- Y aquí algo parecido a una cronología del asunto

4. Charlas Retro Madrid
- Entrevista a Jon Ritman
- Programando videojuegos pseudo-3D con 8BP
- Lo que siempre quisiste saber del Apple II
- HispaMSX BBS
- Cómo desarrollar videojuegos retro y no morir en el intento

5. Explora Commodore 2018
- Página del proyecto
- Reportaje sobre la edición de este año

6. The New 8-bit Heroes
- The New 8-bit Heroes, Trailer
- NESmakers - Episode 1
- Vídeos del canal

8. La GDC nunca para
- Building Games That Can Be Understood at a Glance
- Level Design Workshop: Architecture in Level Design
- Practical Procedural Generation for Everyone
- The Art of The Witness
- Manifold Garden: Level Design in Impossible Geometry
- Temporal Reprojection Anti-Aliasing in INSIDE
- Designing Journey
- How Cameras in Side-Scrollers Work
- Animation Bootcamp: 2018 Tricks of the Trade
- Ebb and Flow - Conversations on the recent momentum of Japanese games
- My To-Do List: Organizing a Producer's Work
- Classic Game Postmortem: Sonic the Hedgehog
- Animation Bootcamp: Animation Prototyping for Games
- Fizzy Brushstrokes: The Art of Knights and Bikes
- Level Design Workshop: Designing Celeste

9. Vulkan
- Wikipedia
- Página de Khronos Group
- Guía de portabilidad para Vulkan
- Godot adopta Vulkan
- Vulkan y el OpenSource

10. Y lo demás
- Sonic the Hedgehog – Developer Interview Collection
- Código fuente de Aladdin
- Five Productivity Tips for Solo Devs
- A Study Into Replayability - Defining Variance

Javier Albizu Mié, 30/05/2018 - 20:29

Bajo un océano de bits, mes VI

Llegó el momento de lanzarse a la piscina; ergo he empezado a tirar líneas de código.
No es que me sienta especialmente preparado para ello, pero tengo la impresión de que leyendo sin más no voy a lograr llegar mucho más adelante. Cosas mías.

Tras continuar con mis búsquedas, por fin logré dar con los materiales completos del curso de Antonio García Alba¹ detrás de los que andaba el mes pasado. El enlace a ellos que aparecía en la primera versión de la wiki que encontré (OSL2) estaba mal, pero no fue muy complicado adivinar cuál podía ser la url correcta.
Aun así, y mientras buscaba más información acerca del autor, a través del repositorio de proyectos de fin de carrera de su universidad llegué hasta otra wiki con ese mismo material. Vista la fuente, a partir de ese momento asumí que esa era la web oficial y con la que continué.

Pero la cosa no ha terminado muy bien. Una vez finiquitada la parte más descriptiva del libro, las últimas ciento y pico páginas están dedicadas a un caso práctico, lo cual está muy bien, pero...

Esta sección está centrada en explicar el proceso de creación de un juego de principio a fin, empezando con la parte más organizativa y terminando con el código completo. La primera parte, a pesar de ser un tanto pesada era comprensible, la teoría es lo que tiene, lo aguanta todo, pero una vez superada esta llegó el batacazo.

Porque, a pesar de tener el código, de ser capaz de compilarlo, y de lograr que me desaparecieran algunas advertencias debidas a métodos obsoletos de C++ que usaba (no olvidemos que el curso es de 2008), no he sido capaz de “leer” el flujo interno de cada una de las clases y objetos que creó. Y esto es un problema.

En la sección ligada a código del juego el foco está centrado en tratar de explicar algunas de las decisiones de diseño que se han tomado... y son decisiones que no acabo de entender. No se trata de que yo las habría afrontado de otra manera (que sin duda será lo que haré), sino que la forma de abstracción que ha elegido es demasiado… abstracta para mi.
Al final la programación consiste en eso, en realizar abstracciones. En buscar otra manera de observar el mundo real y modelar un caso de forma que lo entendáis tanto tú como el ordenador. Y la manera en la que ha planteado el juego el autor se me hace muy difícil de seguir. No se trata únicamente de que los mecanismos lógicos por los que ha optado me resulten demasiado abstractos, sino que tampoco soy capaz de aterrizar lo que explica a través de la lectura del propio código.

Me falta una base muy seria en cuanto a la programación estructurada en general, y la programación orientada a objetos en particular (por no hablar de C++).
Comencé mirando cada comando, cada “include” y cada función en la web², pero esto no me hacía entender el conjunto. Demasiados detalles entrelazados, demasiadas cosas por probar y entender sin tener claro el contexto para el que han sido creadas.

Así pues, toca ignorar el vértigo, empezar a ensuciarse las manos y equivocarse mucho. Toca hacer, que es la única manera que sé de entender.

Pensando sobre el asunto me ha dado por darle vuelta a la expresión de "tirar" líneas. No sé si la primera persona que lo utilizó quería decir "arrojarlas" sobre la pantalla o la CPU o, como lo hago yo, tirar línea tras línea a la papelera de lo inservible.
Vaya, como en Daegon.
En fin.

Porque sí, apenas he empezado y con cada revisión se va mucho más de lo que había en origen.

Claro está, es muy probable que mi nivel de madurez programática tenga mucho que ver en esto. Que estoy muy verde.
Al menos eso espero.
Me queda año y medio para descubrirlo.

Haciendo caso a una de las alternativas que me planteé en los comienzos de este reto, no voy a lanzarme directamente a por "mi" juego, sino que empezaré rehaciendo desde cero uno que ya existe. A escribirlo utilizando mis propias palabras.

Con esto espero no desviarme de la parte pura del aprendizaje con temas de diseño. Conociéndome como me conozco, sé que me iba a empezar a centrar en los asuntos que me resultan más interesantes o cómodos y lo otro iba a quedar en un segundo plano. Ya habrá tiempo para eso. Por ahora empezaremos analizando otro. Teniendo un objetivo concreto que reflejar.

Así pues, voy a empezar con un clon del Traz de Commodore 64, que no deja de ser una evolución del Arkanoid, que no deja de ser una evolución del Breakout de Wozniak (que no Jobs) para Atari, que no deja de ser una evolución del Pong, que no deja de ser una copia del Tennis de la Magnavox, que no deja de ser una evolución del Tennis for two “programado” en un osciloscopio en el 58³.
Y hago esto porque es un juego que siempre me gustó, porque parece una idea en apariencia sencilla y asequible, porque tiene un editor de niveles y porque... viejunismo.

En paralelo a todo esto también he comenzado a buscar a las personas que desarrollaron el juego original para pedir su beneplácito a la hora de usar las ideas, gráficos y música que ellos crearon, pero la cosa está complicada.

Por lo pronto he empezado a extraer los gráficos a partir de un emulador de Commodore. Esto no se limita a los "Tiles" en sí mismos, sino también a cada uno de los frames de animación. Un coñazo, pero algo mucho más sencillo y rápido que hacerlos yo desde cero.
Tengo pendiente mandar correos a la gente que anda metida en el desarrollo retro para indagar acerca de la posibilidad de extraer esta información desde el binario de la versión original, pero no tengo muchas esperanzas sobre ello. Lo máximo que he logrado por el momento ha sido sacar un volcado en ensamblador y hexadecimal del archivo "prg" gracias a Droid D64⁴, pero tener eso es lo mismo que no tener nada.

Ya que estábamos, también he buscado varias implementaciones de Arkanoid hechas con SDL⁵ para ver si saco ideas pero, como de costumbre, queda mucho para que sea capaz de entender la totalidad de su código.

Pero dejémonos de dar vueltas, y vayamos a lo concreto. Despiecemos esta cosa y vayamos por partes.

Objetivo inicial:
Crear cuatro versiones del juego cada una de ellas con una biblioteca de funciones distinta.
Estas bibliotecas serán:

SDL 1.2
SDL 2
SFML
OpenGL (… ya veremos)

Como no quiero limitarme a aprender a utilizar una API, me lanzo a lo bruto. La parte puramente programática será común, pero la forma en la que se pintan los gráficos, se utiliza la música o se interactúa con los los dispositivos de entrada me las tendré que currar con cada una de ellas.

A grandes rasgos, el programa completo tendrá tres bucles:

1. Menú de selección.
2. Editor de niveles.
3. Juego.

Ahora mismo me estoy centrando en el primero de esos bucles el cual, a su vez, está dividido en otros tres bucles menores.

Casos de uso del Menú.

- Primer bucle

Al arrancar el programa suceden dos cosas:
Se muestra una pantalla con el menú.
Suena una canción.

Gráficamente el menú consiste en tres bloques:
El fondo.
Centrado en la parte superior tenemos el logo, que tiene una animación propia (39 pasos distintos de animación, de los cuales no sé cuántos frames debería ocupar cada uno).
Centrado en una franja marrón de la parte inferior tenemos una rotación de textos (Programador, grafista, músicos, y TOP 10 jugadores)

- Segundo bucle

Cuando se pulsa cualquier tecla la parte inferior da inicio el segundo bucle, y cambian dos cosas:
El ciclo de textos se detiene para ser sustituido por el menú de selección.
Se puede interactuar con él.

En esta interacción se puede seleccionar entre las 3 opciones que da el menú:

- Un jugador
- Dos jugadores
- Editor de niveles.

- Tercer bucle

Una vez que se ha terminado una partida se vuelve al menú.
El programa te dice que has logrado una puntuación digna de estar dentro del Top 10.
Se muestra un cursor para que el jugador introduzca su nombre. Este cursor aparece en la franja inferior, pero el color de esta franja no es marrón sino azul.
Se actualiza el Top 10 que se muestra en el primer bucle con ese valor.
Se vuelve al primer bucle.

Y hasta aquí puedo leer por el momento. Una vez que consiga hacer funcionar esto, "lo fácil", me pondré con el siguiente bucle (aunque sí que tengo una idea general de lo que me espera).

De todo lo descrito por ahí arriba, por ahora sólo he conseguido pintar un rectángulo sobre la pantalla y que esta muestre una imagen estática que tengo almacenada en el disco duro.
A partir de ahí comienzan los problemas.

Porque quiero que ese rectángulo sea escalable.
Con SDL 1.2⁶ he conseguido que el rectángulo pueda cambiar de tamaño, pero no que la imagen que se encuentre en interior le acompañe.
Aparte de esto, esta librería me ha dado un problema adicional: Si no controlas los tiempos de refresco de pantalla se zampa todos los recursos de la máquina.
He conseguido paliar esto parcialmente, pero aún me queda para terminar de entender todo el proceso.

Por si con esto no fuese sucifiente, a la hora de cambiar el tamaño de la ventana también me hace cosas raras. En fin, es una biblioteca de funciones algo vieja, pero se han hecho cosas interesantes con ella, así que yo no seré menos.
Por más que me requiera más trabajo también me resulta la más interesante. Por un lado es en la que está basado el curso que he leído y, por otro, al ser más básica también “ofusca” menos cosas que las demás. Tengo que entender mejor lo que estoy haciendo, así que me quedo con ella.

Con SDL 2⁷ he conseguido que, si defino un multiplicador al tamaño inicial del rectángulo, este también se aplique a la imagen, pero si cambio el tamaño de la ventana de manera manual tengo el mismo resultado que con la versión previa (pero sin los raros).
Espero que cuando termine de entender el segundo enlace pueda finiquitar esta parte.

Con SFML⁸ he conseguido que haga ambas cosas y es con la que menos código he usado. Por un lado, guay, por otro, casi todo es totalmente opaco.
Quizás cuando entienda todo lo que sucede por detrás me decante por ella, a fin de cuentas es la biblioteca más nueva, sobre la que más documentación y libros he encontrado, y la que parece más sencilla de usar.

Con OpenGL⁹, tras mucho buscar, también he conseguido que lo haga todo... aunque ha sido "tuneando" uno de los ejemplos de Lazyfoo. Un ejemplo bastante complejo cuya lógica aún no he terminado de pillar que, de premio, me da un warning al compilar.
Funciona, sí, pero tengo que entender el por qué y arreglar ese mensaje de alerta.
Antes de llegar hasta este punto había conseguido crear el rectángulo escalable con facilidad, pero no hubo manera de lograr que pintase nada en su interior.

OpenGL es con mucho la más clásica de las bibliotecas que he usado, pero su filosofía no tiene nada que ver con la de las otras tres. Tira mucho de otras bibliotecas externas para otras funcionas auxiliares como la carga de gráficos (de las que probé con libpng, SOIL y STB) y todo se vuelve un poco cristo.
Al final la cosa ha quedado funcionando con DevIL, la que se usaba en el ejemplo, pero tengo la impresión de que esto va a ser lo que más me retrase, así que no sé si llegaré a mandarla a paseo antes de terminar.

Y creo que ya vale por hoy. Como broche final diré que la Fundeu acepta el vocablo “Renderizar”¹⁰, lo que me ha dejado un poco loquer, pero bueno, hay que modernizarse. Igual cualquier día de esto aparece en uno de esos diccionarios de la RAE que están regalando.

Enlaces:

1. Repositorios de la Universidad de Cadiz
- Proyectos de fin de carrera
- Wikis – UCA: Ejemplo de la creación de un videojuego
- Wikis – UCA: Ejercicios del curso
- OSL2 – UCA: Ejemplo de la creación de un videojuego
- OSL2 – UCA: Ejercicios del curso

2. La C con el ++
- la STL - Standard Template Library
- Programación en C++ - Objetos y Clases
- Repaso a la stl, introduccion a los contenedores
- C++ Punteros y referencias
- C++ Map
- Headers and Includes: Why and How

3. Tennis for Two y sus clones
- El original
- La Magna disputa
- La causa de la disputa
- La historia del Breakout de Atari
- Y las secuelas

4. Droid D64, tú y yo tenemos que conocernos mejor

5. Clones de Arkanoid con SDL
- Breakout
- SDL-ball
- Breaker 10
- Breaker 10 dentro de una suite de emuladores para la consola Coolbaby RS-97
- Breaker 10 dentro de una suite de emuladores para Dingux (consola Dingoo) ya no disponible

6. SDL
- Resizable Windows
- SDL - Regulating Frame Rate
- Resizable Windows and Window Events

7. SDL2
- Draw an Image with SDL2
- SDL Scale Surface

8. SFML
- SFML and Linux
- SFML - Sprites and textures

9. OpenGL
- Libpng
- STB
- DevIL - A full featured cross-platform Image Library
- SOIL - Simple OpenGL Image Library
- OpenGL Window Reshaping
- OpenGL - Lesson 06 Texturing Update
- OpenGL - Loading a Texture

10. Renderizar en Fundéu

Javier Albizu Mié, 11/07/2018 - 19:30

Bajo un océano de bits, mes VII

Lentamente pero con paso firme (y frases hechas) continuamos avanzando y extendiendo esto. Porque al ponerme a picar código se me había olvidado que tenía por ahí la idea de no limitarme a C++ y hacer también algo con Python¹ (para quien también está disponible SDL).
Dicho y hecho, ya logré crear mi ventanita con un gráfico en SDL1, SDL2, SFML, OpenGL y PySDL.
Una vez conseguido eso, tocaba pensar en los siguientes pasos. Más concretamente dos de ellos; Las animaciones y la estructura /claridad /reutilización del código.

Hasta el momento estaba trabajando con un único archivo pero, sólo con lo que llevaba, ya estaba empezando a ocupar mucho. Cada vez que tocaba algo para hacer una prueba era un tanto complejo el acotar dónde empezaba una cosa y terminaba otra.

Así pues, y volviendo a curso de SDL como referencia, he tratado de definir las clases que me puedan ser necesarias. Esto es, analizar con un poco más de experiencia sobre mis hombros lo que aparecía en el juego de ejemplo, y comenzar a escribir con mis propias palabras y estructura mental las agrupaciones de funciones.

Por el momento tengo dos clases: Pantalla y Controles, pero Pantalla ya ha crecido y voy a ir dividiéndola en otras subclases como puedan ser las generación de imágenes o fuentes. Para terminar con el bucle del menú también tengo que crear otra clase para los sonidos, pero esto no cae dentro del paraguas de “lo que se muestra en el monitor”.

Ya he conseguido recrear la animación del logo del Traz con SDL. Lo he hecho de tres maneras distintas, lo que me ha ayudado a entender algunas de las estructuras gráficas de esta biblioteca²; las superficies, los rectángulos y el “blit”. Cosas que no terminaba de entender sólo con su lectura.

Entre tanto, también he dado con una herramienta que me permita extraer los gráficos de un disco virtual de Commodore³, aunque aún me quedan cosas por terminar de centrar. No he logrado encontrar la ubicación de todos los gráficos y las fuentes o el logo no las he visto por ningún lado, así que para lo que he hecho he seguido utilizando los pantallazos que saqué el mes pasado. Las fuentes me las tendré que hacer también desde cero.

Por otro lado, de los gráficos que sí que he extraído no todos ellos parecen tener la proporción que se muestra en el juego, así que asumo que utilizaron algún truco de código para cambiar esa proporción. Pero al menos sí que tengo a mi disposición las animaciones de los enemigos.
Tampoco he visto dónde se encuentran los sonidos, pero eso no será demasiado difícil de sacar del emulador, ya que permite grabar el audio de las partidas a mp3.

Para llegar hasta este punto he vuelto a retomar la lectura de cosas relacionadas con el Commodore⁴, algo sobre lo que hay todo un mundo ahí fuera. También he encontrado que hay diferentes versiones volcadas del Traz volcadas por la red⁵, una de las cuales incluye la imagen de carga del juego. Otra cosa más a incluir.

Como el Pisuerga pasa por Valladolid, también he llegado hasta lugares sin relación aparente con el tema, pero igualmente interesantes. Lugares como estos en los que te presentan el proceso de creación de un emulador de GameBoy⁶. Web a las que igual vuelvo dentro de un tiempo.

Y han llegado las vacaciones. El asueto del trabajo remunerado pero no de los deberes autoimpuestos.
Durante estos días he continuado con todos los retos que tengo activos, aunque he de reconocer que con un ritmo un poco menor. En tirar de los datos del móvil ha hecho que racione un poco la búsqueda de soluciones a los problemas con los que me he ido encontrando, pero he ido derivando parte del tiempo a la lectura de temas relacionados. Materias como pueda ser el funcionamiento de la propia máquina⁷.

Porque este es un tema muy importante. Algo que me debería ayudar a ganar perspectiva y que, como de costumbre, provoca que quiera profundizar más. Otra cosa que también consiguen estos viajes al pasado es confirmar lo que sólo asumes. Ratificar esa gran verdad que afirma que todos los conceptos que los “visionarios” afirman “inventar” o “descubrir” en la actualidad ya estaban ahí desde hace mucho.
Quizás su presencia adopte formas más toscas y complejas, quizás los hombros de los gigantes sobre los que viajamos sean tan anchos que a veces no somos capaces de ver dónde terminan, pero desde la posición adecuada puedes ver todo el panorama.

Y más o menos esto será todo por hoy. Aún tengo pendiente el tema del escalado de los gráficos con SDL1, pero parece que puede haber una vía⁸. La probaré cuando tenga ya listos todos los elementos de la pantalla de inicio.

Enlaces:

1. PySDL2
- Crear una ventana con PySDL
- Sprite, texture and pixel surface routines

2. SDL y los gráficos
- SDL_Surface
- SDL_Rect
- SDL_BlitSurface

3. Extrayendo gráficos de un Snapshot de C64
- SpritePad
- Exporting sprites via vice and spritepad

4. Leyendo sobre el Commodore
- Ripping sidtunes
- N0STALGIA C64 TOOLS
- Working with Maps, Tiles, Chars and Compression
- C64 Sprite / Charset Ripper
- Graphics Extractor and Inserter
- Spritemate - browser based sprite editor for the Commodore 64
- Spritemate - browser based sprite editor for the Commodore 64
- C64 Sprites
- How "oldschool" graphics worked Part 1 - Commodore and Nintendo
- How "oldschool" graphics worked Part 2 - Atari and Apple
- CGA Graphics - Not as bad as you thought!

5. Traz en CSDB
- Búsqueda general
- Ficha general
- TRAZ +7DH

6. Emulando Gameboys
- Writing a Game Boy emulator, Cinoop
- BGB (GameBoy emulator/debugger)

7. Libros y más cosas sobre el Commodore
- Anatomy of the Commodore 64
- Supermon
- Entrevista a Jim Butterfield
- Supermon en Github

8. Escalando gráficos
SDL - Pixel Access
SDL - Scale Surface

Javier Albizu Mié, 08/08/2018 - 14:25

Bajo un océano de bits, mes VIII

Lo que empezó siendo un único archivo de código, y el mes pasado se convirtió en tres, a día de hoy son ya más de media docena. Todo para conseguir hacer un poco menos de lo que hacía el primero.

Y, aun así, pese a seguir más o menos en las mismas, cada vez vamos logrando que sea un poco “más” que “menos” que el mes pasado.

La sensación general es la de que no hay avance. Seguimos tratando de terminar de pintar el menú, sólo que ahora con clases, constructores y objetos diversos. Pero sí que los hay. Es lo que tiene la perspectiva. Si miramos los resultados desde fuera, pueden parecen retrocesos, pero poquito a poco van las piezas van encajando. Hace falta tener al mismo tiempo la visión global y la de detalles para ver cómo ha cambiado todo.
Por supuesto, esto no evita que siga dando bandazos.

Voy avanzando en el análisis, comprensión y reescritura del código del juego de Antonio García Alba. Cogiendo pequeños pedazos de su código, adaptándolos a lo que busco de acuerdo a lo que entiendo de él, y dándome de cabezazos una y otra vez contra el muro de mi ignorancia.
Mas no importa¹.

Sigo buscando webs y libros que me ayuden a aclarar los conceptos más básicos que me faltan². Desde el tour llegué hasta el libro de Bjarne Stroustrup, el papi del C++, y empecé con él. Pero no era lo más adecuado para mí.
De ahí iba a pasar a los “Piensa en C++”, pero aparecieron en mi camino los textos de “Aprende como si estuvieses en primero” de la Universidad (Privada) de Navarra, que son con los que estoy ahora.

Una versión previa de estos textos ya me habían aparecido por otras partes, y están bastante extendidas, pero he preferido dejar el enlace a los últimos (que tampoco es que sean lo más moderno del mundo). Ambos tienen una marca de agua de su facultad, pero al César lo que es del César. La atribución se le tiene que hacer a quien corresponde.

Por supuesto esto no es lo único que he hecho durante este último mes a este respecto y sigo buscando información acerca de cómo integrar Git y GDB con VIM. Más adelante me meteré también con Make.

He encontrado un par de cosas a este respecto³ que aún no he probado, pero en algún momento me tendré que poner a ello. Cuanto más crezca el código más necesidad tendré de una herramienta para poder cazar bichos y errores. Por un lado, la opción de ponerme a insertar “std::cout” tras cada línea no es muy óptima para saber en qué momento está petando la cosa. Por otro, me dedico a mantener código comentado por todos lados para conservar las cosas que funcionaban antes de ponerme a separar las funciones, lo que no deja de ser otra guarrada que manda a paseo la legibilidad del código.

Pero si me meto con esto tengo claro que perderé mucho tiempo cacharreando. La investigación para hacerlo funcionar por primera vez es divertida pero, una vez superada esa fase, cada nuevo paso requiere de mucho más tiempo para entender realmente lo que estoy haciendo. No es que sea menos divertido, todo lo contrario, pero mientras dedico tiempo a eso (lo divertido) mi casi nulo avance se ralentiza aún más (porque el poder de la frustración es poderoso).

Supongo que me pondré a ello cuando termine con el menú, pero no voy a ponerme a hacer predicciones acerca de cuándo llegará ese momento, porque siempre he sido nefasto en esos menesteres.

También ha habido vida más allá del código. Pequeños momentos de ver cómo les ha ido esto a otros.
Cómo no, hemos tenido charlas de la GDC⁴ y ha aparecido algún que otro pequeño atisbo de desarrollo orientado a la accesibilidad⁵. No sé muy bien a través de quién (quizás gracias a las recomendaciones de mi página principal) llegué como por arte de magia hasta el canal de Youtube de Dan Root⁶ del que puedo sacar ideas para cuando llegue el momento de “mi” juego.
También sigo buscando cosas acerca de Hyper Light Drifter y Transistor⁷. Dos juegos que, si bien no encajan con lo que quiero que sea el mío, me parecen auténticas bellezas y obras de las que sí que puedo extraer lecciones acerca de narrativa dentro del juego.

Como no podía ser de otra manera, también he realizado infinidad de visitas a Stack-Overflow y otros foros similares, pero no veo que aporte demasiado el listar por aquí todas las indicaciones que me han ayudado a solventar problemas concretos que me van ido saliendo a lo largo del camino.

Y… no hay mucho más que contar.
Nos leemos de nuevo en cuatro semanas.

Enlaces:

1. Shen Comix me sigue representando (a veces)
- Hablando del Diablo
- Actitud positiva I
- Actitud positiva II
- El muro

2. El camino de C++ es complejo
- A Tour of C++
- Bjarne Stroustrup
- The C++ Programming Language
- Thinking in C++, Volume One: Introduction to Standard C++
- Thinking in C++, Vol. 2: Practical Programming
- Aprenda c++ como si estuviera en primero
- Básico
- Avanzado

3. Más cosas para Vim
- vim-fugitive
- Conque-GDB

4. GDC
- Tech Toolbox for Game Programmers
- Learning from Our Mistakes: A Postmortem of Guacamelee!
- Empowering the Player: Level Design in N++
- How We Created Mark of the Ninja Without (Totally) Losing Our Minds
- Cuphead's Animation Process and Philosophy
- Owlboy: The Evolving Art of a 10 Year Project
- Game a Week: Teaching Students to Prototype

5. La accesibilidad
- Serie de vídeos con consejos de diseño sobre accesibilidad en videojuegos
- Game Maker's Toolkit explores how devs can design for colorblindness

6. Dan Root
- Su canal
- The Importance of Key Frames // Run Cycles
- The Animation of Wonderboy: The Dragon's Trap
- Fez's Animated Environments

7. Hyper Light Drifter y Transistor
- Hyper Light Drifter - Trailer
- Hyper Light Drifter - Applying 3D Level Design Skills to a 2D World
- Hyper Light Drifter - From Kickstarter to Release
- Hyper Light Drifter - The Sound of
- Hyper Light Drifter - The Sound and Music
- Transistor - Launch Trailer
- Transistor - Reveal Trailer
- Jen Zee en DeviantArt
- Galería de imágenes de Transistor

Javier Albizu Mié, 05/09/2018 - 20:31

Bajo un océano de bits, mes IX

Y sin embargo se mueve...

Pues sí, tras cerca de tres meses de no ver por dónde me venían los golpes, parece que comienzo a ver la luz. Por supuesto, aún me queda mucho camino por recorrer, pero la salida de este túnel en concreto parece más cercana.

Ya tengo la animación del menú en funcionamiento, he logrado pintar un texto sobre una parte concreta de la pantalla y he conseguido cambiar el color de fondo de ese rectángulo cuando pulso una par de teclas concretas.

Lo sé, todo eso ya os suena, pero la novedad es que ese proceso ya no se come toda la memoria de mi máquina en cuanto lo arranco.

Desde el principio la parte de los constructores de clases se me habían atragantado, y tampoco terminaba de ubicar el estado de cada uno de sus miembros, pero esto es algo a lo que (creo que) ya les he pillado el punto.

Al final y, como de costumbre, contradiciendo a mis vaticinios del mes pasado me puse a mirar cómo se "debugea". Gracias a esto (y a Insight¹) logré dar con la parte concreta del bucle en el que la memoria se me iba de madre.

Cómo no, aún estoy muy verde como para ser capaz de interpretar en su totalidad la información que me muestra el debugger, pero tiempo al tiempo.

Por otro lado, el solucionar el tema de la memoria no solventó otra clase de problemas que también estaban teniendo lugar en un segundo plano. Tras corregir esa parte el menú se me autoinmolaba cuando el bucle se repetía por vez número 1019.
La razón exacta detrás de este comportamiento concreto (el por qué funcionaba hasta ese momento) sigo sin saberla, pero sí que localicé el punto en el que se producía el error y lo corregí.

Gracias a los libros de “Aprende como si estuvieses en primero” he conseguido centrar algún que otro concepto que tenía difuso, y ha sido gracias a leerme cosa de cuatro veces la parte dedicada a los constructores que he obtenido la sensación de que voy entendiendo su función y funcionamiento.
Para tratar de confirmar mis teorías he dividido el programa aún en más archivos, cambiando de sitio objetos, punteros y funciones, y todo parece indicar que sí. Que sí que lo tengo.
Bien por mi.

Ahora ando dándole vuelas al pensamiento desacoplado y los patrones de programación. Esto es algo acerca de lo que supe hace tiempo en alguno de los vídeos las clases de programación en C++ del Profesor Retromán² y que creo que ha llegado el momento de afrontar.
Gracias a esos vídeos también supe que puedo compilar una aplicación para Windows desde Linux^{3. Una cosa más sobre la que tengo que mirar, y otra capacidad más hacia la que evolucionar mi script de compilación.}

Más allá de la teoría pura acerca de los patrones que puedes encontrar en Wikipedia⁴ hay bastante literatura a este respecto por ahí⁵, pero aún tengo que terminar decidirme por una lectura básica en concreto por la que comenzar.

Otra predicción incumplida fue la de Git. Ya tengo integrado Vim con el control de versiones, y también he logrado descifrar cómo configurar la parte servidora (algo con lo que comencé a pelearme hace mucho). No es que lo haya usado para gran cosa, pero es una cosa menos que tengo pendiente.

Por supuesto, este mes también he visto unas cuantas charlas de la GDC⁶, por donde han aparecido una conferencia que dio la gente detrás del Ultima Online (incluido Richard Garriott con su corona) contando un poco de su intrahistoria.

Tengo un poco abandonado el tema de la accesibilidad, y tampoco ha aparecido por mis blogs habituales nada relevante a este respecto. Menos mal que tengo amigas que se acuerdan de mi cuando leen sobre estas cosas. Si cuando leí sobre el mando adaptativo de X-box no terminaba de ver muy claro su valor, parece que hay gente que lo entendió bastante mejor que yo⁷.

Más sobre lo que leer, más sobre lo que investigar. Pero eso ya para la próxima entrada.

Enlaces:

1. insight
- Insight
- Insight FAQ
- Script para instalar Insight
- GCC - Options for Debugging Your Program
- Working with Insight, the Debugger Interface
- Cgdb

2. Clases de Programación en C++

3. Compilación en/para Winows
- MinGW: A native Windows port of the GNU Compiler Collection (GCC)
- GCC Mingw

4. Patrones de diseño
- Design pattern
- Abstraction layers
- Facade (fachada)
- Abstract factory
- Singleton
- RAII (Resource acquisition is initialization)

5. C++ Programming (Wikibooks)
- Versión Wiki
- Versión PDF
- C++ Programming: Code patterns design
- Repaso a C++11 en Genbeta
- L-Values y R-Values
- Referencias a un R-Value
- Moviendo objetos no copiables
- Tipos automáticos
- El principio RAII y los cuatro miembros implícitos

6. GDC
- How to Find and Engage a Great Artist: A Non-Artist Primer
- Designers Are from Saturn, Programmers Are from Uranus
- Classic Game Postmortem: Ultima Online

7. El controlador de X-box en acción

Javier Albizu Mié, 03/10/2018 - 20:04

Bajo un océano de bits, mes X

Seguimos avanzando sin movernos del mismo lugar, cambiándolo todo sin que sea apreciable desde el exterior.

Datos. Necesito datos¹.

Durante este mes me he centrado en sacar todos los valores que puedan ser utilizados en mas de un lugar fuera del código. Aparte de eso, el “contenedor maestro” que había creado para abarcar a todos los objetos se ha visto separado en cinco. Todo eso y poco más en esta edición de “Bajo un océano de bits” en su entrada más ¿técnica?.

Aún estoy dando pasos de bebé en esto de la programación en general, y el C++ en particular, pero estoy comenzando a “entender” estos lenguajes. Me estoy dedicando a jugar con ellos. Porque, por mayor que sea el misticismo que le queramos dar, la programación no deja de ser eso, otro idioma que tenemos que aprender a hablar, leer y escribir. Otra manera de describir las cosas.

Cuanto más profundizo, más claro tengo que es una cuestión de tiempo, práctica, paciencia, inventiva y objetivos acotables. Cuanto más básico es el nivel del código que leo, más me doy cuenta de que… tiene sentido. Que “eso habría sabido hacerlo yo”.
Si con el dibujo los engranajes de mi cabeza aún no han hecho “click”, parece que estos sí que van cogiendo velocidad.

Y es entonces cuando pienso que me estoy perdiendo algo. Que no puede ser tan sencillo. La historia de mi vida.

Pero la cosa es que muevo y reescribo, retuerzo las líneas en otro sitio y siguen funcionando. Que siguen haciendo lo que tenían que hacer (o al menos lo mismo que hacían cuando las describí de otra manera). Y eso hace que me sienta bien.

No dudo de que, hasta cierto punto, este no-avanzar de los últimos meses se debe a que he encontrado algo similar a una zona de confort, pero creo que lo que estoy haciendo tiene sentido. Tardaré más en ver resultados en la pantalla, pero tengo claro que los pasos llevan la dirección correcta.

Y claro, luego me pongo a leer más cosas y me doy cuenta de que, si quiero hacer las cosas bien desde el principio, voy a tener que esperar mucho más hasta que lleguen esos resultados y sean “visibles” (o jugables). No quiero empezar con pasos apresurados y darme cuenta a medio camino de que tenía que haber hecho algo distinto desde el principio.
No sé cuántas veces me han dicho que estoy tomando el camino difícil, pero yo no he venido hasta aquí a hacer sólo las cosas fáciles.

Quizás por deformación de mi trabajo en el día a día, sigo pensando en la arquitectura del programa a alto nivel. En tratar de desglosar los componentes de la forma más general, abstracta y óptima posible. De decidir a qué capa correspondería cada uno de ellos. En que todo lo que haga ahora sea reutilizable para cualquier cosa que pueda hacer después.

Dentro del nivel más básico de esta arquitectura que voy improvisando con cada nueva revisión, he situado los datos en crudo; lo que quiero que esté fuera del código. Un contenedor al que, en un alarde de originalidad, he dado en llamar “Datos”.

Para ello he creado una clase central a la que he llamado (redoble de tambores) “Acceso_datos”. Una clase que se basa en archivos de texto plano en el que iré insertando los valores que usará el programa y para cuya estructura he decidido utilizar JSON²

Por el momento Acceso_datos sólo tiene una función llamada “Leer”, que me devuelve los valores guardados en los archivos y los convierte en variables a utilizar por el código. Cosas de un amplio espectro que abarcan desde el idioma hasta la anchura de un rectángulo en el que voy a dibujar un sprite o la clasificación de los jugadores. Más adelante tendré que crear los métodos “Actualizar”, “Crear” y “Reiniciar”.

Nada más arrancar el programa, lo primero que hace es inicializar este contenedor, con lo que leerá cuatro archivos JSON con nombres tan genéricos como “datos_globales”, “datos_recursos”, “datos_controles” y “datos_clasificacion”.

Tras la creación de “Datos” le llega el turno al segundo elemento central que he creado. Algo que, en un nuevo alarde de originalidad, he bautizado como “Sistemas”. Este contenedor se encarga de albergar los objetos que hablan con los dispositivos de entrada y salida. Por el momento, dentro de “Sistemas” se instancian los objetos de otras dos clases; Pantalla y Controles.

Como ya digo, es el segundo objeto que se crea en el arranque del programa y, tras leer los valores que le proporciona “Datos”, inicializa los objetos “pantalla_principal” y “controles”.

Una vez hecho esto, procedemos a pasar al tercer gran contenedor; “Recursos”. En él, en estos momentos, sólo se inicializa el objeto “LOGO” de la clase “Imagen”, pero más adelante (cuando existan) será el encargado de albergar objetos de las clases “Fuentes”, “Sonidos”, “Música”.

Cada uno de estos objetos estará almacenado en vectores³ que se crearán dinámicamente a partir de la información del archivo “datos_recursos.json”. Con esto, una vez que tenga creadas todas las clases que aglutina, para meter un nuevo “recurso” no tendré que tocar para nada el código de este contenedor.

Para terminar tenemos el contenedor “Modos” (al que igual termino llamando “Presentacion” para que suene más parecido a la capa OSI que sería su homóloga). Los miembros de este contenedor utilizarán los objetos instanciados en los anteriores y, a su vez, instanciarán objetos de las clases “Presentacion”, ”Menu”, “Juego”, “Editor” y “Configuracion”.

De las clases que debe albergar “Modos” por ahora sólo existe “Menu” y aún se encuentra en un estado casi embrionario. Cuando cree la clase “Juego” también tendré que crear otra clase hijo a la que llamaré “Nivel”, pero aún no sé en que consistirá ninguna de las dos, así que tiempo al tiempo.

Aún me queda por definir el último contenedor que se debería crear. El que he dado en llamar “Motor” y que se ocupará de cosas como las físicas, detección de colisiones, animación (y otro montón de cosas con las que me pegaré cuanto toque).

Todo un berenjenal.

Últimamente tengo abiertos todos los archivos pertenecientes a las clases mencionadas y los archivos de datos que les corresponden. Esto significa que mis editores tienen abiertos de manera permanente cerca de treinta archivos entre los que navego. Cada vez que toco uno de ellos tengo que andar modificando alguno de alguno de los restantes, así que hay momentos en los que hago sufrir mucho al compilador con mis descuidos.

Hasta este mes no existía la parte de acceso a datos, y todos los demás contenedores se encontraban apretados dentro de uno que había denominado “Nucleo”. A priori esto resulta más sencillo, sólo tendría que tocar un archivo tocho, pero he preferido separarlos para que su estructura se parezca a algo que tenga un poco más de orden, sentido y estructura en mi cabeza. Hoy “Nucleo” era manejable, de aquí a un tiempo se habría convertido en un infierno (y en algo menos reutilizable).

El sacar los datos a los archivos JSON también me ha supuesto algún que otro problema adicional. En los archivos de cabecera podía definir los datos con el tipo que me de la gana, pero al importarlos desde fuera todos son cadenas de texto. Con ciertos valores, como las opciones de inicialización de la ventana la cosa se complica. Este valor, que en código puede ser una cadena de texto, por detrás hacía una conversión a hexadecimal, algo que no se puede (o no he conseguido) hacer directamente.
Tras analizar un poco el código de SDL he visto que donde yo ponía “SDL_HWSURFACE | SDL_RESIZABLE | SDL_DOUBLEBUF”, él hacía tres sustituciones:

#define SDL_HWSURFACE 0x00000001 /** Surface is in video memory */

#define SDL_RESIZABLE 0x00000010 /** This video mode may be resized */

#define SDL_DOUBLEBUF 0x40000000 /** Set up double-buffered video mode */

Así pues, al final la cosa se quedaba como la suma de esos tres valores, ergo: 0x40000011 (que es el valor que ha quedado en el archivo de configuración).
A saber con cuántas más de estas me voy a encontrar.

Otra parte que me ha consumido bastante tiempo ha sido la generación dinámica de los vectores de “Recursos”. Algo que, si bien no era un requerimiento ahora mismo, sí que me facilitarás las cosas de cara a futuro.

Por otro lado, la parte de una posible traducción de los textos que aparezcan en pantalla, por el contrario, ha sido una de las más sencillas de implementar. Ahora sólo falta que no me olvide de poner los valores correctos donde toca en cada nueva clase.

Una vez conseguido todo esto, se me abren varios caminos. Podría plantearme el meterme en serio con las fuentes de creación propia⁴ o que empiece a mirar maneras ágiles de probar las cosas que hago⁵.
Cualquiera de las dos cosas me va a llevar bastante tiempo. Aunque creo que la primera será más rápida de solventar, la segunda me va a a aportar más en el largo recorrido y este es un buen momento para ponerme a ello.

No sé. Mañana me podré con ello.

Enlaces:

1. Más datos

2. JSON
- JSON en la Wikipedia
- Jsoncpp en Github
- Jsoncpp en WikiBooks
- Json Parser 1
- Json Parser 2

3. Vector

4. Dibujando texto y fuentes
- Text Imput
- Getting String Input (SDL1)
- Introducción de texto con SDL (SDL2)
- Text Input And Clipboard Handling (SDL2)
- SDL_ttf
- Ejemplo de implementación de SDL_ttf
- Bitmap Font Generator
- Bitfont Maker 2
- Unicode

5. Probando que es gerundio
- Test-driven development and unit testing with examples in C++
- Ten C++ Testing Tools for Developers to Consider
- CppUnit
- Google Test
- Boost.Test
- Catch2
- Bandit
- Cpputest
- TUT (C++ Template Unit Test Framework)

Javier Albizu Mié, 31/10/2018 - 23:30

Bajo un océano de bits, mes XI

El mes pasado dejábamos esto con una duda: ¿fuentes o testing?.
Y, la respuesta a esta pregunta es, como de costumbre, ninguna de las anteriores.

En su lugar me puse a mirar patrones de programación en C++ orientados a la creación de vídeo juegos.

Regresando a una de esas entradas que tenía empezadas desde hace años¹ llegué hasta otros textos. Más concretamente hasta un libro² que puedes comprar, leer online, o descargarte desde GitHub.

El libro está escrito en un tono desenfadado pero tengo con él el mismo problema que con otros tantos: No soy capaz de entender por completo los ejemplos de código que muestra.
Los textos que preceden a los ejemplos son interesantes, y puede entrever más o menos lo que se pretende con las muestras, pero no veo cómo integrarlos en mi código. Aparte de esto, no sólo se dedican a defender a lo suyo, sino que también hablan de las filias y fobias de su autor, algo que he visto que es muy común también en las entradas dedicadas a este tipo de temas en Wikipedia. Dependiendo de a quién leas cualquier cosa es buena o es una mierda.

Tras terminar con el tercero de los patrones que mencionaba este libro decidí seguir buscando más lectura acerca de aquel asunto fuera del este texto. Por un lado, el tema del encolado de eventos era algo sobre lo que ya había leído un poco, aunque de buenas a primeras se me hacía un tanto complejo de hacer con mi nivel actual. Por otro, creo que va a ser lo que me va a hacer falta a la hora de actualizar ciertas variables cuando implemente la pantalla de configuración, o a la hora de actualizar los datos de la clasificación de jugadores.

El concepto del Sujeto/Observadores se me hacía algo más sencillo que las colas de eventos, así que decidí profundizar un poco más… en ambos³.

Porque sólo con los ejemplos del libro se me veía capaz de terminar de entenderlo. Así pues, me puse a buscar otras implementaciones… sin erótico resultado. Aún estoy muy verde en esto.

Casi todas entradas hablan acerca de las bondades del polimorfismo y las clases virtuales⁴. Temas de C++ en los que aún no he profundizado y que me hacen pensar si debería retomar el libro de Stroustrup sobre la última versión de este lenguje.

Al final la decisión fue… lo habéis adivinado: No hacer ninguna de estas cosas.
Quizás cuando termine con el menú. Algo para lo que me queda ¿poco?.
No. No me queda poco.

Las últimas dos semanas me he dedicado a crear la clase que dibujará los textos en pantalla. Algo que parecía ser sencillo pero que no lo es. Creía tenerlo cuando me encontré con ciertas particularidades de las variables estáticas dentro de las clases a la hora de trabajar con Superficies de SDL (o, al menos, con SDL 1.2).

Si declaro la superficie de origen (donde “cargo” el texto antes de que sea pintado en pantalla) como estática, no se actualiza aunque el en el siguiente ciclo le envíe un texto distinto. Si no la declaro como estática el programa se autoinmola al rato como ya me hacía en su momento la animación del menú. La misma característica que me salvó en un caso me putea en el otro.
Una vez con esto claro, tengo que replantearme la manera en la que iba a almacenar el texto dentro de mis archivos JSON. De ser líneas independientes tengo que planteármelas como si todo el texto que va a ir rotando en pantalla fuese una única imagen. Un mural del que voy ir mostrando a recuadro a recuadro. Esto, claro está, siempre que no utilice otra biblioteca de funciones que no sea SDL⁶ para el pintado del texto.
Pero esto es algo que, por el momento, quiero evitar. Vamos a la vía dura.

Así pues, la cosa sigue más o menos como el mes pasado. Bueno, miento.

Ya he creado la pequeña clase que se encargará de pintar la pantalla de presentación previa al menú, la que se dedica a gestionar en qué modo de juego nos encontramos, y la dedicada a gestionar la reproducir de la música.
Estas tres clases no me costó demasiado hacerlas y todas ellas funcionan correctamente, aunque aún tengo que conseguir que se pase desde la presentación hasta el menú cuando se pulse cualquier tecla, botón del pad, o se mueva el ratón.

A pesar de que en las últimas entradas no he puesto nada a este respecto, también he seguido viendo vídeos de las GDC⁷, al igual que alguna que otra charla curiosa⁸ (que siguen haciendo que quiera ponerme a aprender ensamblador).

Esta semana también ha salido otro uso para el controlador de Microsoft para gente con discapacidades. En este caso para usarlo en la Switch⁹. Parece que aunque los grandes no se mueven demasiado se puede confiar en la comunidad.

Y más o menos esto es todo. A ver por qué derroteros me estoy moviendo cuando llegue la última entrada de este primer año para el reto computacional.

Enlaces:

1. Writing a Game Engine from Scratch I

2. Game Programming Patterns
- La web del libro
- Su ficha en goodreads
- Y su Github

3. Observador o colas de mensajes
- El observador (no confundir con el personaje de mis relatos)
- En Wikipedia
- Powerful C messaging/
- How to implement and use a message queue in your game
- Game programming tutorial messaging systems in C
- Publish–subscribe pattern
- Understanding and Implementing Observer Pattern
- Setting up msysmingw build system for compiling sdlopengl applications

4. Más cosas de C++
- Polymorphism
- https://en.wikipedia.org/wiki/Virtual_class>Clases virtuales

5. Estatismo del malo

6. GUI Without Extravagant Nonsense

7. GDC
- GDC 2018: Classic Game Postmortem: 'The Bard's Tale I and II'
- Classic Game Postmortem: Gauntlet
- GDC Classic Postmortem: Warren Robinett's Adventure
- The Journey to Creating SHANK
- Yars' Revenge: Classic Game Postmortem
- The Shapes in Your Story: Narrative Mapping Frameworks
- Girl Games of the 1990s: A Retrospective
- Classic Game Postmortem: Alone in the Dark
- Classic Game Postmortem - Raid On Bungeling Bay

8. Y amigos
- Renderizando tilemaps con scroll por software [GameDev asm Z80][5.4][2018]
- How we fit an NES game into 40 Kilobytes

9. Nintendo joins the limited-mobility club with Xbox Adaptive Controller (unofficially)

Javier Albizu Mié, 28/11/2018 - 22:34

Bajo un océano de bits, mes XII

Cuando estamos apunto de llegar al ecuador de esto, la cosa sigue sin avanzar demasiado.

La parte de mostrar texto en pantalla ya está casi finiquitada. Si alguien me llega a preguntar hace un año acerca de lo que creía que me iba a costar más, esta respuesta habría sido la última que me habría venido a la cabeza. Por supuesto, técnicamente apenas he empezado aún con esto, así que a ver cuánto me cuesta el editor en el momento en el que me ponga con él.

El mes pasado comentaba por aquí que había comenzado a leer el “Game Programming Patterns”, pues bien, ese libro también ha quedado en suspenso para mejor ocasión.
De la misma manera que llegué hasta él mientras leía los artículos de “Writing a Game Engine from Scratch”, su lectura me llevó hasta otro libro más; “Programming: Principles and Practice Using C++”¹.
Otro libro más cuya lectura he dejado aparcada… por el momento.

Cada vez que hago una jugada de estas me invade el deja vu. Empezar a leer y tener miedo de no entender lo que he escrito cuando vuelva en “x” tiempo. No falla, cuando me encuentro con un problema no dejo de tener la sensación de que estoy remoloneando. De que en cuanto se cruz en mi camino algo que no soy capaz de solucionar de cabeza dejo que me gane la inseguridad y siento la necesidad de llenar huecos que muy probablemente no estén ahí. De buscar fuera soluciones que es muy posible que ya tenga.

Porque, al final del día, la cosa es que la idea para solucionar este caso en concreto (y otros tantos problemas indeterminados) estaba ahí. Lo podía ver vagando por los sectores periféricos de mi cabeza, pero cada vez que pensaba sobre él no veía la forma de aterrizarlo. No era capaz de encontrar el momento de ánimo necesario para concretarlo. De pillar papel y boli para plasmar el problema de una forma visual y trazar las posibles soluciones.

Aunque también puede ser que me encuentre cómodo con esto. Jugueteando una y otra vez con cosas cuya resolución sí que me veo capaz de llevar a cabo. Refinando y perfeccionando lo que ya tengo para que cumpla un ideal que no tiene demasiado sentido.
Seguramente será una suma de todo eso, no lo sé.
¿Dónde termina la pereza y empieza la inseguridad?, ¿Donde se traza la línea entre la depuración y el TOC?

Lo que tengo claro es que no me gusta cómo se “lee” mi código. Líneas muy largas para terminar escribiendo cuatro variables. Vueltas que se me hacen muy rocambolescas para hacer cosas que en mi cabeza parecen sencillas. La forma en la que estructuro mi modelo de datos hace que el acceso a ellos sea un poco ortopédico, pero si simplifico una parte la otra se vuelve más confusa.
Igual es así como “tiene que ser”, pero me cuesta horrores llegar a un consenso conmigo mismo y conseguir decidir cuál de mis partes es la que tiene que ceder. La historia de mi vida.

En fin. Como empezaba diciendo, la clase que dibuja el texto ya (casi) está. Y digo casi porque ya está la parte dedicada “renderizarlo” ajustado a izquierda, derecha y centrado en la pantalla, pero no la que se encargaría de centrar el texto en algún recuadro concreto que no ocupe todo el ancho. Algo que por ahora no necesito, pero que quiero tener listo.

Aparte de esto, también tengo que extraer de ella (y de la que se encarga de pintar los gráficos) el componente que se encarga de controlar el ciclo de rotación de los textos y sprites; la “animación estática”. Un código que ahora mismo tengo en ambas clases, ergo, está duplicado, por lo que se puede (y debe) sacar de ahí.

Y básicamente para esto es para lo que ha dado este mes.
Por supuesto, también ha habido unos cuantos GDCs², ha salido esa preciosidad de los barceloneses Nomada Studio que es Gris³, el señor Benjamin Heckendorn ha desmontado el mando “adaptativo” de Microsoft⁴, la gente de Casual Bits ha sacado con un año de retraso su Battle Princess Madelyn⁵ y yo los odio a todos muy fuerte

Enlaces:

1. Programming: Principles and Practice Using C++

2. Los GeDeCes del mes
- What Wikipedia Doesn't Know Can Hurt You: Writer Research Skills
- Classic Game Postmortem: Sid Meier's Civilization
- Classic Studio Postmortem: Lucasfilm Games
- Classic Game Postmortem: LucasFilm Games' Loom
- The Living World of The Witcher 3: The Wild Hunt
- Classic Game Postmortem: Deus Ex

3. Gris
- Nomada Studio
- GRIS - Launch Trailer
- The Animation of Gris

4. What's Inside the Microsoft Adaptive Controller

5. Battle Princess Madelyn

Javier Albizu Mié, 26/12/2018 - 20:35

Bajo un océano de bits, mes XIII

Podría decirse que hemos empezado bien el año en lo referente al C++.
Podríamos decirlo, claro, pero, de hecho, mentiríamos (al menos parcialmente).

Porque el año, en sí mismo, empezó regulero.

Habíamos dejado este tema, como de costumbre, con una mezcla de esperanza y frustración sumada a las dudas habituales. Con la lectura de un libro, Programming - Princples and Practice Using C++, que sigue ahí comienzo polvo virtual en su página doscientos (de 1312).

Terminé el año pasado con la moral a media asta y con la sensación de que “todo mal”, el reto, el código, mi comprensión lectora y mi capacidad para llevar esto hasta algún punto al que merezca la pena llegar. Pero bueno, el reto no era llegar hasta ningún lado concreto sino ver hasta dónde conseguimos llegar, así que… veamos.

Este último mes ha seguido la misma tónica que los anteriores; una sucesión de pequeñas alegrías, hostiazos de realidad y, con suerte, algo de aprendizaje y recapacitación.

Comencé consiguiendo hacer algo que había estado persiguiendo desde hace tiempo, una función que me permitiese invocar a los objetos almacenados en los vectores de recursos por su nombre y no por su identificador.
A la hora de determinar el funcionamiento de la aplicación no supone nada. Es más, probablemente suponga un pequeño incremento en el consumo de recursos del ordenador, pero tanto a mi como a cualquier hipotético usuario que pudiese haber de este “motor” que estoy haciendo, nos haría las cosa un poco más sencillas a la hora de invocar a esos recursos.
Tenía la solución en la periferia de mis neuronas desde hace meses pero no ha sido hasta hace un par de semanas que por fin logré agarrarla.
En el código de la aplicación en la que me estoy basando esto estaba solucionado con un enumerador¹, pero esta solución no me servía si quería que la clase que se dedica a gestionar de los recursos fuese dinámica (o lo que es lo mismo, no tener que tocarla ni recompilarla cada vez que añado un recurso adicional).

Tras jugar con vectores que contuviesen objetos “mixtos” (conjuntos de datos de tipo cadena texto y objetos del tipo de objeto que quería devolver) juntados en un "struct"², al final opté por tener dos vectores por por cada tipo de objeto; uno para los nombres y otro para los objetos en sí mismos.

Con esto puedo tener una única función consultora a la que invocan aquellas que devuelven el tipo de objeto concreto (Imagen, Color, Fuente, Sonido, Canción, etc...).

Con esto no pierdo la posibilidad de llamar a los objetos de la manera anterior, pero sí que me ahorro el tener que mirar a qué número corresponde cada uno de ellos:

Mientras hacía esto también rehice por completo la clase que se dedicaba a pintar el texto. Aún tengo que ser capaz de lograr que me muestre cosas como tildes y otros caracteres especiales, pero esa parte la voy a dejar para un poco más adelante.

Y la tuve que rehacer porque había cometido un error muy gordo a la hora de interpretar qué significaba definir una variable como “static” y eso me había vuelto un poco loco.
Por culpa de esto las cosas empezaron a fallar cuando di comienzo a la creación de la siguiente clase, la que se encarga de gestionar la animación de los objetos.

Cuando esta clase era invocada por más de una animación pasaba olímpicamente de todo valor posterior posterior al primero. Poner diferentes variables “static” en un único archivo no daba problema, pero cuando quería crear más de una instancia de cualquiera de ellas el resultado no era bonito (generalmente un pete en ejecución, que no en compilación).

Tras mucho leer y no entender, en un foro de Arduino vi lo más parecido que encontré a una respuesta, pero no era capaz de aterrizar el código unitario que presentaban en una estructura de clases.
Después de volverme loco, de hacer mil pruebas y de rehacer doscientas veces las clase “Menu”, “Animacion” y “Texto” logré hacer funcionar aquello, pero seguía sin estar convencido de cómo había quedado, y con razón.
Serendipias de la vida, esa misma noche las piezas encajaron en mi cabeza. La cosa había funcionado, sí, pero había sido por casualidad.

Estoy convencido de que lo habré leído mil veces en todos los libros que me he echado encima, pero no fue hasta esa noche con la cabeza apoyada sobre la almohada que las piezas encajaron y entendí una más tanto el papel que cumplen la declaración de variables como privadas y la función del constructor³.

Al día siguiente cambié las tres clases y todo funcionó. Rehice todo aquello que funcionaba de chiripa y quité todos los “static” que sobraba y funcionó, volví a replantearme las clases principales… y falló, pero porque me equivoqué con la sintaxis, no por un error de comprensión.

Y así he llegado hasta hoy a tope de ánimo. No hay como el ser cabezón para se capaz de derribar las paredes de tu estupidez gracias a tu férrea determinación y tu sólida estructura craneal.

Enlaces:

1. Ha llegado el enumerador

2. Las estructuras y sus cosas

3. De constructores y objetos

Javier Albizu Mié, 23/01/2019 - 20:53

Bajo un océano de bits, mes XIV

Dejamos esto hace cuatro semanas con los ánimos a tope y lo retomamos un poco de aquella manera.

Después de la última entrada la cosa continuó mejorando un poco. Encontré un “fuga de memoria”¹ en la clase dedicada a dibujar las imágenes y fui capaz de corregirla. Me las prometía muy felices hasta que llegó el momento de gestionar los eventos² y determinar cómo iban a ser las interacciones con la aplicación.

Hasta el momento había trabajado con el código que se encargaba de estas tareas que venía en el curso, pero a la hora de tratar de hacer cosas distintas de cambiar un valor por otro la cosa se empezó a torcer.

Me explico.

Mi bucle principal es muy sencillo:

1 - Miro todo lo que pasa en el sistema y, mientras el valor “Salir” no tenga un valor verdadero, hago lo que se encuentra definido en un bucle infinito.

2 - Pregunto si se ha pulsado alguna tecla.

3 - Se cargan las músicas e imágenes del modo de juego que tenga seleccionado.

4 - Se vuelca todo eso en la pantalla principal.
5 - Le digo que no se flipe demasiado y que no pase de las 100 pintadas por segundo.

Hasta ahora no me había hecho falta precisión alguna a la hora de controlar la respuesta del teclado. Con que al pulsar una tecla esta asignase a una variable un valor concreto me era suficiente

Acción a realizar al pulsar una tecla en la presentación

Sólo había un estado posible.

Pero ahora, al ir al menú en sí mismo, la cosa se complica. Tenemos tres estados posibles:

Acción a realizar al pulsar una tecla en el menú

Cada vez que pulso una tecla, el valor de “opcion” (sin tilde), tendría que aumentar o disminuir en uno. Sencillo, pero no hay manera.

Y no hay manera porque el procesador es muy rápido. Entre que pulso la tecla y la suelto pasan varios ciclos de reloj y la pantalla se ha redibujado más o menos entre 4 y 10 veces (acordaos que le he dicho que, como mucho, lo haga 100 veces por segundo, pero aún así es demasiado para esta manera de gestionar las cosas). Así que, cada golpe de teclado, implica que el valor de “opcion” se incremente o disminuya en ese número.

He hecho un apaño con la función “precision” (también sin tilde)… pero no es muy precisa que digamos y sigo atrapado en este punto desde el mes pasado.
La documentación de SDL a este respecto³ no me ha ayudado mucho, el código en el que me baso tampoco. La manera que tiene de controlar el movimiento del cursor no tiene nada que ver con la mía, y no quiero copiar tal cual la suya. Como suelo decir siempre por aquí, quiero entenderlo.

Y no deja de ser una pijada. A la hora de mover bichos por la pantalla esto no importa nada porque, a pesar de trabajar con la resolución de un Commodore 64, recorrer los 384 pixels de altura de la pantalla o los 272 de anchura es una tarea mucho más sencilla de gestionar, pero quiero que esto funcione de la manera en la que lo he decidido (o rehacerlo todo, pero que todo quede como yo decida en base a unas razones que considere razonadas y aceptables).

Por supuesto, podría buscar otras librerías para hacer esto, o podría ponerme a copiar a otros. Podría dedicarme a ver los vídeos de Jonathan Blow⁴ o Fran Gallego⁵. Podría mandarlo todo a paseo y meterme con Unity 8 Bits⁶. Mirar como afronta estos problemas un centenar de personas pero, por más cosas que me vayan descubriendo las píldoras de conocimiento que van soltando, quiero hacerlo a mi manera.

Y no hay mucho más que decir por ahora más allá de…
Continuará.

Enlaces:

1. Memorias a la fuga

2. Los eventos
- Event
- Event loop
- Event driven programming

3. SDL y los eventos
- SDL Events
- Handling the Keyboard

4. Jonathan Blow y sus Game Engina Programmng

5. Fran Gallego
- C++: Optimizando costes básicos de acceso a memoria
- Fuentes propias de texto y código absoluto
- Volatile
- Compiler Explorer/a>

6. Unity 8 Bits

Javier Albizu Mié, 20/02/2019 - 19:37

Bajo un océano de bits, mes XV

Tras mucho demorarlo, finalmente, llegó el día.
Y quizás alguno se pregunte... ¿qué día? ¿el día de qué?.

A lo que respondería: El día en el que bajamos de nivel. Una respuesta que, en sí misma, tampoco es que diga gran cosa.

No, no voy a bajar el nivel de presión (algo que ya es de por sí bastante bajo). No voy a dejar esto.
Bueno, no voy a dejarlo… aunque sí.
Con esta respuesta tan intencionadamente ambigua lo que quiero decir es que abandonamos un nivel de abstracción para sumergirnos en la dirección de las simas más profundas. Bajamos un peldaño idiomático, nos dirigimos hacia las fosas abisales del ensamblador.
Un viaje de destino incierto y que veo complicado que finalice antes de que este reto llegue a su hipotético final.

Y la culpa de todo esto la tiene un hombre; Fran Gallego, el Profedor Retromán¹
Como decía aquel, cada vez que veo uno de sus vídeos me doy cuenta de que no sé nada. No sé lo que sucede en la circuitería o en el procesador, no sé la cantidad de recursos que estoy consumiendo con cada comando, no sé en qué está convirtiendo el compilador las cosas que yo puedo considerar "ordenadas y claras".
No sé lo importante. No sé aquello con lo que tendría que haber empezado.

Así pues, toca cambiar de rumbo y profundizar, pero no a tontas y a locas. No voy a ponerme ahora a estudiar la arquitecturas de los procesadores x64², sino que me encuentro camino de algo mucho más básico y molón; Las tripas del MOS 6510³, las entrañas del Commodore 64. Aunque, claro está, esto era algo que ya se veía venir de lejos.

Por supuesto, tengo intención de volver más adelante al C++, pero antes quiero entender lo que sucede entre bambalinas. Quiero saber cuántos ciclos de reloj le cuesta a la máquina ejecutar una orden, cuántos bits ocupan mis artefactos, cómo hablan entre sí cada uno de los elementos del ordenador, y esto es algo que me va a ser imposible con las arquitecturas modernas, no sólo por su complejidad intrínseca, sino también por la capa de abstracción y ofuscación que supone el mismo sistema operativo.
Confío en que, una vez entienda este tipo de cosas, ese conocimiento me ayudará a comprender la información que me proporcionan herramientas⁴ como Valgrind, C++ Insights o Compiler Explorer. Seré capaz de entender la razón detrás de la “Regla de los tres” (y la de los cinco). No quiero limitarme a repetir sin criterio alguno lo que he leído en los libros o los tutoriales.

Y, sí, también, y por supuesto, tengo un plan.
... sí, otro. Ya sabéis cómo va esto.

Borrón y cuenta nueva.
He comenzado a leer los manuales oficiales que venían con el ordenador⁵. Empezaré por el “Commodore 64 Users Guide” y continuaré por el “Programmer's Reference Guide”. Después de eso ya veré por dónde sigo, porque documentación hay para aburrir.

También ha dado comienzo la parte divertida, la del acopio de herramientas⁶, el tema de entenderlas, realizar una criba y saber cómo, dónde y cuándo usar cada una de ellas ya es otro mundo.

En algún momento indeterminado del futuro, muy probablemente cuando termine con los dos primeros libros, volveré a los curros de ensamblador para CPC del señor Gallego y trataré de ir alternando y replicando los ejercicios que propone para el Z80 con el 6510. Tengo claro que sus arquitecturas no se parecen en mucho, pero ambos son procesadores sencillos. Si logro entender ambos no sólo tendré una parte del camino recorrida ante lo que quiero hacer, sino que me aportaría una base no sólo para plantearme proyectos para el CPC o el Commodore, sino también para Spectrum, MSX, NES, Game Boy y Master System.
Soñar es gratis y los planes tampoco cuestan dinero. El tiempo y mi capacidad para comprender y asimilar la información ya son otro asunto.

Así que aquí me tenéis, a mi edad, escribiendo programas en BASIC para hacer que una pelotita recorra la pantalla de un lado a otro parpadeando como una condenada.

Enlaces:

1. El culpable
- Optimizando en C para Z80 en Amstrad CPC #1
- Optimizando en C para Z80 en Amstrad CPC #2
- Optimizando la memoria en Amstrad CPC #1
- Renderizado Sincronizado en Amstrad CPC
- Interrupciones y música en Amstrad CPC
- Estructuras de datos y funciones en ensamblador Z80 (Amstrad CPC)
- Depurando programas en Amstrad CPC (Z80)
- Renderizado con Double Buffer en Amstrad CPC
- Tips rápidos de programación en ensamblador 1
- C++ : Optimizando accesos básicos a la memoria caché
- C++ : Entendiendo y optimizando std::vector
- C++ : La regla de los tres, constructores y copias
- C++ : Constructores Delegados
- C++ : Operador asignación con copy-and-swap idiom
- C++ : Entendiendo emplace_back y placement new
- C++ : Copy-elision y Return Value Optimization (NRVO / RVO)

2. Gritones de transistores

3. MOS 6510
- El cerebro
- La máquina

4. Herramientas para C++
- Compiler Explorer
- CPP Insights
- Valgrind - Cachegrind manual
- C++ rule of three

5. Los libros
- Commodore books.
- Commodore 64 User's Guide
- Commodore 64 Programmer's Reference Guide
- Anatomy of the Commodore 64
- Assembly Language Programming With The Commodore 64
- What's Really Inside the Commodore 64
- Cómo programar en Ensamblador x86

6. Herramientas para el Commodore
- CodeBase 64
- A$$emble it!
- C64 Dev kit
- CC65
- CC65 Documentaci
- CC65 en GitHub
- Relaunch 64
- Relaunch 64 en Github
- Relaunch 64 binarios de la última versión
- XA (xa65)
- Awesome C64

Javier Albizu Mié, 20/03/2019 - 20:56

Bajo un océano de bits, mes XVI

Dispérsense, aquí no hay nada que ver.

Estoy en una de esas épocas. En una de esas temporadas en las que soy incapaz de concentrarme para poder leer algo de manera continuada. Uno de esos lapsos de tiempo que pueden llegar a durar años.
Aunque mucho me temo que el problema no es únicamente ese.

Reviso mi perfil de Goodreads¹ y veo que en estos momentos tengo en curso la lectura de diecinueve libros, trece de los cuales han sido añadidos como apoyo para este reto.
Durante los primeros pasos de este reto leí cuatro libros, dos de los cuales sólo dos de ellos eran puramente técnicos. Ambos me costó un horror terminarlos y, una vez despachados, seguía sin tener las cosas demasiado claras.

Es increíble la cantidad de capas de abstracción que es necesario atravesar para llegar hasta los niveles de concreción que requiere un programa. Y el problema es igual de complejo en ambos extremos.

La cantidad de factores que debes tener presentes si quieres llegar hasta los niveles más concretos es abrumadora. Cuanto más profundizas en esos niveles todo es a la vez más abstracto y más concreto, y quiero llegar hasta esos el último de ellos.

En estos momentos el juego es lo de menos, la programación sólo es un paso para entender lo que pasa dentro de la máquina. Quiero convertirme en un ingeniero sin hacer la carrera. Quiero un atajo para llegar hasta mi destino, pero para ciertos recorridos no hay un camino fácil.

Cada párrafo de cada uno de los libros que tengo empezados me ha hecho ir hasta sus fuentes, ir hacia un nivel anterior, aparcarlo y comenzar a leer otro libro que no tardo en dejar por otro. Y eso no tiene ningún sentido.
Necesito ir hasta el principio pero… ¿dónde está?.
Corrijo. La pregunta no es dónde está ese comienzo, sino dónde estoy yo. Si encontrar la respuesta a la segunda pregunta no puedo plantearme la primera.

Pero aquí hemos venido a hablar de mi plan. Sí, ese, y el otro, y el otro también.
Como decía el sabio, no existen planes perfectos, sólo intenciones perfectas.

Continúo con los vídeos del Fran Gallego² y me parece que tengo la comprensión al alcance de la mano, a una interrupción sináptica de distancia, pero cuando trato de concretar sus palabras veo que realmente todo está mucho más lejos.
Bajo un nivel y veo a Ben Eater³. Todo se me hace más cercano y lejano al mismo tiempo, más concreto. Pero, a pesar de su tamaño de la circuitería, cuando trato de extrapolar lo que veo funcionando a la escala de las arquitecturas modernas, todo es abrumadoramente pequeño y se mueve a una velocidad tal que no soy capaz de visualizarlas.

Y, más allá de esto, para interiorizarlo todo, para terminar de encajar las piezas, tengo que mancharme las manos. Tengo que hacerlo yo de principio a fin. Y sé que en cuanto me ponga a ello encontraré nuevas carencias, que tendré que volver a bajar hasta otro nivel.

Voy bajando una y otra vez sólo para terminar regresando siempre hasta el punto de partida. Necesito ensuciarme las manos en algo que pueda terminar. En algo que pueda llevar a cabo en un periodo de tiempo concreto.

Así pues, una vez más, ¿cuál es el objetivo?
Supongo que el de siempre… ver hasta donde llego.
De acuerdo, reformularemos la pregunta:
¿Ensamblador, C++?
¿Qué camino vas a seguir?
¿Hacia dónde vas?

Por el momento seguiremos con ensamblador. En cuanto haga funcionar en Vim el resaltado de la sintaxis⁴ para x86, z80 y 6502 (y que no se pegue con el precompilador de YouCompleteMe) empezaré a meterme con los registros de esos cacharros.

A ver si con un poco de suerte la parada lectora termina y puedo continuar con alguno de los libros que tengo empezados.

Enlaces:

1. Mis lecturas en curso

2. Más profesor Retromán
Ensamblador
- Optimizando la Memoria en Amstrad CPC (Z80) #2
- Números pseudo-aleatorios en Amstrad CPC (Z80)
- Optimización del Compilador para Amstrad CPC (Z80)
- Físicas con coma fija en Amstrad CPC (Z80)
- Optimizando en Amstrad CPC (Z80) #3
- Optimizando la memoria en Amstrad CPC (Z80) #3
- Empezando con Ensamblador del Z80
- Empezando con Ensamblador del Z80 (II)
- Empezando con Ensamblador del Z80 (III)
- Depurando el salto del personaje en ensamblador de Z80
- Múltiples ficheros en ensamblador de Z80 con CPCtelera
- Obstáculos en movimiento en ensamblador Z80
- Teoría: Colisiones entre Bounding Boxes
- Tip: cómo optimizar detección de colisiones por frecuencias
- Revisión del proceso de ensamblado y ficheros
- Convertir y dibujar sprites en ensamblador con CPCtelera
- Convertir y dibujar mapas de tiles en ensamblador con CPCtelera
- Detección de colisiones en ensamblador Z80
- Estructuras de datos y objetos en ensamblador Z80 con IX #1
- Estructuras de datos y objetos en ensamblador Z80 con IX #2
- Estructuras de datos con macros en ensamblador Z80
- Reproduciendo música en ensamblador Z80 con CPCtelera
- Música por interrupciones en ensamblador Z80 con CPCtelera
- Revisión de dudas y Consejos en ensamblador Z80
- Efecto de scroll por software en ensamblador Z80
- Scroll por software + double buffer en ensamblador Z80
- Llamar a funciones en C desde ensamblador del Z80
- Revisión del Micro-GameEngine
C++
- C++: Sensores para Enemigos
- C++: Memoria dinámica, ejercicio de nivel intermedio 1
- C++: Memória dinámica, arrays y alineamiento
- C++: Profiling basico, optimización y caché
- C++: Gestión Avanzada de Memoria con Placement New
- C++: Ejercicio. Independizar el render
- C++: Strategy, pimpl y façade para independizar un renderer
- C++: Múltiples renderers. Análisis de código
Juegos de CPC para Android
- Crea videojuegos en Amstrad para millones de jugadores en 2019

3. Ben Eater
Redes
- Networking tutorial 01 of 13 - Sending digital information over a wire
- Networking tutorial 02 of 13 - Intro to fiber optics and RF encoding
- Networking tutorial 03 of 13 - Clock synchronization and Manchester coding
- Networking tutorial 04 of 13 - Analyzing actual Ethernet encoding
- Networking tutorial 05 of 13 - The importance of framing
- Networking tutorial 06 of 13 - Frame formats
- Networking tutorial 07 of 13 - Lower layers of the OSI model
Construyendo un ordenador de 8 Bits
- Learn how computers add numbers and build a 4 bit adder circuit
- Programming my 8-bit breadboard computer

4. Ensamblador para VIM
- Ensamblador de x86 para Vim
- Ensamblador de z80 para Vim
- Ensamblador de 6502 para Vim

Javier Albizu Mié, 17/04/2019 - 22:01

Bajo un océano de bits, mes XVII

Este mes ha sido entretenido a la par que ilustrativo en lo referente a este reto. Pero no lo ha sido porque haya avanzado demasiado en el terreno de la programación, sino porque mi tiempo se ha centrado mayormente en buscar, probar y conocer las herramientas que se encuentran a mi disposición si quiero programar cosicas para el Commodore desde un entorno con arquitectura x86.

Podríamos decir que este mes se lo hemos dedicado a entender un poco mejor el legado de los chicos de Commodore Bussiness Machines¹.

Un vez hecha esta introducción, vamos al turrón.

¿Qué herramientas tenemos a nuestra disposición?

Pues depende.

Si queremos programar en BASIC para el C64² la cosa es bien sencilla. Basta con tener el VICE y utilizar su “petcat” sobre cualquier archivo de texto plano en el que hayas introducido las líneas de código. Con esto te generará un archivo .prg que reconozca el emulador.
De premio, utilizando su comando c1541 puedes meter eso dentro de una imagen de disco .d64.
Es algo tan sencillo que ha sido lo que más me ha costado encontrar. Porque la Internet es asín.

También tenemos la opción de ejecutar “nativamente” en Linux o Windows comandos del BASIC de Commodore con CBM Basic, pero no tienes la posibilidad de usar pokes o sprites por hardware. Cosas de los sistemas operativos modernos

Si queremos ir al ensamblador³ el abanico se amplia. Sólo mirando las herramientas que aparecen en 6502.org la cosa puede llegar a ser abrumadora. Si ya vas a los foros de Lemon 64 o Commodoremania puedes perder un par de vidas tratando de hacer la criba.

Al final el tema de los ensabladores lo he dejado reducido a dos; ACME y CC65.
El primero por el nombre y porque he visto que hay varios tutoriales sobre él, y el segundo porque se encuentra en los repositorios de Ubuntu. Lo que ha terminado por decantar mi criba por ambos ha sido que existen resaltadores de sintaxis de los dos para VIM.

Si la gente no quiere liarse a “compilar el compilador de ensamblador” se puede descargar Kick Assembler, que está hecho en Java y le serviría para cualquier sistema operativo sin liarse demasiado la manta a la cabeza.
En caso de que busque algo aún más sencillo, también podría decantarse por alguno de los IDEs⁵ que tiene a su disposición por ahí.

Relaunch está hecho en Java, así que funcionaría tanto en Linux como en Windows o en Mac, y tanto C64 Studio como Kickass IDE funciona bajo Wine, así que tendría la papeleta solucionada en lo que respecta a cualquiera de los sistemas operativos mayoritarios sin necesidad de tener que compilar nada.
Eso sí, Relaunch no trae compilador “de serie”, pero lo puedes arrejuntar con Kick Assembler y asunto resuelto.

Porque la compilación. Vaya movida.
Si hay algo que me ha quedado claro últimamente es que no sólo tienes que aprender a programar en un lenguaje. Tienes que hacerlo pensando en el compilador que utilizarás y la arquitectura del procesador. De acuerdo a lo que he podido entender (seguramente de manera errónea) durante estas “investigación” esto es algo especialmente sensible en el caso de los compiladores cruzados.

He bajado el código fuente de distintos juegos escritos en ensamblador para el C64 y cada uno sólo puede ser compilado con la herramienta para la que fue pensado. Amigüitos, no intentéis compilar algo hecho para ACME con CC65. Y no intentéis compilar nada de CBM Prg Studio con otro ensamblador.

Pasamos a la caza de bichos⁶ y la cosa se complica un poco más.
Vice tenía un compilador bastante apañado en su versión 3.1 para Windows (y sólo en esa), pero desapareció en la 3.3 (la última que ha salido), donde sólo ha quedado el Monitor que te permite consultar y modificar la memoria y registros desde la línea de comandos.

Si queremos tirar de herramientas gráficas, WinVICE 3.1 funcionan bajo Wine y sigue estando disponible para su, así que por ahí podríamos tener la cosa apañada, pero también existen otras alternativas.

C64 debugger tiene versión nativa tanto para Linux como para Windows y Mac, así que mejor os ahorráis el tratar de compilarlo desde su código fuente (yo no he sido capaz). De cualquier manera, lo que aparece en pantalla nada más arrancar es tan colorido y movido que asusta.

Step 6502 sólo está para Windows, pero funciona bajo Wine, así que se puede usar sin problemas en Linux. Por lo poco que lo he tocado me ha parecido un poco… especial. Hasta donde he podido entender, arranca un emulador en blanco y en estado de pausa. Eres tú quien se dedica a meter a mano los valores hexadecimales en memoria y a avanzar “paso a paso” los ciclos del reloj. Para los muy cafeteros.

Por lo que he podido leer de Vice PDB Monitor la cosa parece interesante, pero ni he conseguido compilarlo ni he logrado que funcione su binario en Windows, así que igual toca investigar un poco más.

Como herramientas para realizar distintas operaciones⁷ como pueda ser hacer gráficos y caracteres o gestionar el contenido de los archivos ,d64 tendríamos SpritePad, Vchar 64 y Droid D64. Las dos primeras sólo están dispobibles para Windows pero funcionan a la perfección en Wine y la tercera está hecha en Java, así que hasta ahí tendríamos la papeleta solucionada en Linux.
Más allá de esto SpritePad, entre otras cosas, también te permite extraer los gráficos de un snapshot de VICE y Droid D64 te permite desensamblar el contenido de los discos y verlo en formato hexadecimal o ensamblador.
Un par de joyicas ambos dos.

Si eres un usuario de Mac no preocuparse, porque ahí está Actraiser y su Dustlayer⁸. Este señor han preparado un entorno de desarrollo para la máquina de la manzanita y, de premio tienen varios tutoriales de ensamblador con ACME.

En lo referente al aprendizaje⁹ también tenemos bastante en lo que rascar más allá de Dustlayer, y a ese respecto CodeBase 64 promete especialmente.

Y con esto creo que terminaríamos este pequeño repaso. Ando tentado de meterme a hacer el equivalente a una CPCtelera para el Commodore con todo lo que he ido encontrando, pero aún estoy über verde como para meterme en un embolado de ese calibre. Tiempo al tiempo.

Más allá del mundo Commodore, este mes también he seguido viendo vídeo a cholón.
Por un lado, he terminado con los de teoría de redes de Ben Eater¹⁰ que comencé el mes pasado y he seguido con los que tiene de electrónica. Lo mola todo, pero si quiero entender estas cosa de verdad tendré para un rato largo.
Por otro, y como no podía faltar, también he seguido con los de Fran Gallego¹¹ como si no hubiera un mañana.

También he encontrado una lista de reproducción de “Matemáticas para desarrolladores de vídeo juegos”¹² a la que le hincaré el diente… algún día.

Y, ahora sí, yo diría que ya habéis tenido suficiente por hoy.

Enlaces:

1. La famiglia
- Gracias por todo, Jack
- Chuck Peddle, father of the personalcomputer
- Bil Herd

2. Basic de C64 en x86
- The Versatile Commodore Emulator
- Compilando Basic de Commodore gracias a VICE
- Manual de petcat
- Manual de c1541
- CBM Basic GitHub

3. Ensablador de 6502 en x86
- Herramientas para C64 - 6502.org
- Acme GitHub
- Vim Acme GitHub
- CC65 GitHub
- Vim CC65 GitHub
- Kick Assembler

5. IDEs:
- Commodore IDE for Windows 32 and Linux
- K2 Devel
- C64 Kickass IDE
- Relaunch 64
- Info en C64 Wiki
- Unity 8 Bits
- C64 Studio
- CBM Prg Studio
- C64 Kickass IDE

6. Debug de C64 en x86
- Using the Vice monitor
- C64 Debugger
- Step 6502 GitHub
- Step 6502 en CSDB
- Vice PDB Monitor GitHub
- Vice PDB Monitor en CSDB
- Debugging 6502 assembly doesn’t have to be awful

7. Más herramientas
- Sprites con SpritePad
- Droid D64
- VChar 64 en GitHub
- VChar 64en CSDB

8. Dustlayer

9. Más tutoriales
- CodeBase 64
- C64 Brain
- A full C64 game in 2013
- The bear essentials developing a Commodore 64 game

10. Más Ben Eater

Terminamos lo de las redes
- Networking tutorial 08 of 13 - The Internet Protocol
- Networking tutorial 09 of 13 - ARP: Mapping between IP and Ethernet
- Networking tutorial 10 of 13 - Looking at ARP and ping packets
- Networking tutorial 11 of 13 - Hop-by-hop routing
- Networking tutorial 12 of 13 - TCP: Transmission control protocol
- Networking tutorial 13 of 13 - TCP connection walkthrough

Electrónica y semiconductores
- Digital electronics tutorial
- How semiconductors work
- Stepping through a program on the 8-bit breadboard computer
- Comparing C to machine language
- Programming Fibonacci on a breadboard computer
- Building an 8-bit breadboard computer

11. Más Profedor Retromán

Ensamblador Z80
- Cargadores de Casete Propios
- Creando un Micro-GameEngine 1
- Creando un Micro-GameEngine 2
- Entidades con comportamientos variables
- Controlando un personaje con teclado
- Múltiples ficheros fuente, includes, símbolos globales y macros

C++
- C++ - Rvalue references, move constructor & move assignment operator

General
- Replanificación y entrega de producto
- ¿Por qué enseñar a programar en ensamblador?
- Clases de Teoría de Matemáticas

12. Math for Game Developers

Javier Albizu Mié, 15/05/2019 - 21:08

Bajo un océano de bits, mes XVIII

Este ha sido un mes de esos de no avanzar demasiado. Uno de esos meses en los que la cabeza no da demasiado de sí y en los que no sabes hacia dónde tirar. Uno de esos en los que, como cada vez me veo sumergido en ellos, me limito a bucear bajito asomando mucho la cabeza. Uno de esos en los que, principalmente, me dedico a la parte más pasiva de este reto; a ver vídeos a tutiplén.

A ver si con el verano la cosa remonta.

Empecé con las clases de matemáticas del canal de Fran Gallego¹. Unas clases que no están impartidas por él sino por uno de sus compañeros, y que no tratan de lo que esperaba sino que versan acerca de la lógica de primer orden², Prolog y otros tema derivados de ambas dos.
Después de ver los primeros diez vídeos decidí dejar eso para más adelante. Había matices que se me escapaban y, como es de rigor, tenía la sensación de llegar a la sala con la película ya empezada. Tampoco tenía la cabeza como para ponerme a profundizar en ello, así que queda aparcado por el momento.
Pero volveré.

Después de eso volví hasta el profe titular³ y los vídeos que me faltan por ver de su canal. Ya falta menos para terminar con ellos… aunque tengo la impresión de que debería volver a darles otra vuelta cuando empiece a hacer algo en ensamblador. Los conceptos importantes están ahí, pero hasta que no me ensucie las manos con código no voy a ser capaz de determinar si he entendido realmente las cosas.

Este mes también ha sido la primera edición del Retro Madrid Academy⁴. Más allá de lo interesante de las ponencias, lo mejor que saqué de la visita fue el ver al amigo Multimaniaco⁵, y las conversaciones en el coche durante la ida y la vuelta hasta la capi. Es increíble lo que ayuda el tratar de verbalizar las cosas que crees haber entendido para terminar de asentar conceptos, o para darte cuenta de lo verdes que los tienes aún.
Necesito tener más conversaciones activas acerca de programación.

Tras largo tiempo en el dique seco, también he visto que se sigue hablando acerca del controlador adaptativo de Microsoft⁶ y la gente que le está dando uso para distintas terapias. Que no decaiga.

En mi pajarear en busca de conocimiento también he seguido con los temas de electrónica⁷ a través de los canales de Ben Eater y Element 14, pero sigo necesitando encontrarme centrado, pillar componentes, y cambiar mi estado de ánimo hacia algo un poco más activo (un poco menos vago) para empezar a llevar a la práctica algunas de las cosas que explican ahí.

Y, para terminar, y llenando huecos, como siempre, ahí estaban al rescate las charlas de las GDC⁸ y Dan Root⁹. Visionados ligeros que me permiten decir que ”técnicamente” no he incumplido el reto durante esos días. Actividades que no dejan de ser un poco placebo en cuanto a lo que se refiere al conocimiento puro. Eso no quiere decir que sean una pérdida de tiempo o que no sean interesantes, pero no dejan de ser tecnicismos con los que rellenar el expediente.

Muy mal.
Que no me pase nada ahora que empiezan los calores.

Enlaces:

1. Clases de Teoría de Matemáticas 1

2. Lógica y otras cosas
- Lógica de primer orden
- Prolog
- PL Man

3. Profesor Retroman

4. Despega RetroMadrid Academy

5. No tan locos giros de guión

6. Más sobre el mando adaptativo de la X-Box
- The Making of the Xbox Adaptive Controller
- Able Gamers
- Special Effect

7. Más electrónica
- How a transistor works
- Making logic gates from transistors
- SR latch
- How Integrated Circuits Work - The Learning Circuit

8. A tope con el GDC
- The Animation Process Of Ori & The Blind Forest
- Art Direction Bootcamp: Pantalones! Things I Wished I knew Prior to Becoming an Art Director
- Visual Effects Bootcamp: Artistic Principles of VFX
- Classic Game Postmortem: Panzer Dragoon, Panzer Dragoon Zwei, and Panzer Dragoon Saga
- Building a Living World from Ancient Ruins in Assassin's Creed Odyssey
- Classic Game Postmortem: Paperboy
- Why Fashion in (Most) Games Sucks, and Why You Should Care
- GDC Live Q&A: Lucas Pope and Return of the Obra Dinn

9. Y con Dan Root
- Alucard's Running Animation
- The Beauty of Parallax
- How to Animate a 2D Fighting Game [redux]
- Making Fluid and Powerful Animations For Skullgirls
- Animator's survival kit
- Fighters Generation
- Zweifuss, personajes de Street fighter y sus animaciones

Javier Albizu Mié, 12/06/2019 - 20:22

Bajo un océano de bits, mes XIX

Este mes la cosa va de desvíos.
Sí, otra vez.

Cuando ya está claro que el propósito con el que afirmaba dar comienzo a este viaje ha quedado totalmente desvirtuado, cada vez me voy dirigiendo hacia lugares cuya visita tenía planteada para mucho más adelante.
Temas íntimamente relacionados con esto pero que, al mismo tiempo, se encuentran en sus antípodas dentro del modelo OSI¹. La eterna pelea entre el software y el hardware. Entre los desarrolladores y los tipos de sistemas.

Y mucho de la culpa de todo esto la tiene Ben Eater².
Tras terminar de ver los cuarenta y cuatro vídeos que componen su Obra Magna; aquella que muestra y explica la fabricación de un ordenador de 8 bits, va el hombre y comienza con otra saga igualmente interesante; la de la creación de una tarjeta de vídeo.

Muy bien. Centrémonos.
Ahora ya tengo una idea más aproximada de lo que buscaba cuando comencé con estos vídeos. Tengo… más o menos claro, qué es lo que hace un ordenador (o, al menos, el del amigo Ben) en un ciclo de reloj. He visto cómo se hablan los registros, la memoria y el bus, he visto cómo se programa el micro-código que va en el procesador y qué son exactamente los mnemónicos que utiliza el ensamblador.

He visto todo eso… y yo también quiero hacerlo. Quiero interiorizar ese conocimiento. Pensar en ciclos de reloj y en bits cuando programo en lugar de bucles de lenguajes de alto nivel.
Como ya decía hace unos meses, ser un ingeniero sin hacer la carrera.
Aún estoy muy lejos porque apenas he comenzado a rascar la superficie, pero voy dando pequeños pasos.

En los vídeos todo está claro, incluso los fallos que van apareciendo, pero cuando he tratado de llevar hasta el mundo real lo más nimio de cuando se muestra en ellos, sigo sin saber por dónde empezar.

Necesito ir de menos a más. De algo un poco más concreto que el “Me voy a hacer un ordenador”. Porque he dicho que quiero hacerlo, no que quiera copiar el suyo. No pretendo ir parando los vídeos, comprando los componentes que utiliza y replicar paso por paso su camino. Quiero hacer algo que me viene aún muy grande.

Pero claro, tengo cosas más pequeñitas por las que podría empezar. Por mi salón aguardan como roboces sin carcasa varios ordenadores desmembrados a la espera de unas nuevas ROMS³, y por mi habitación no dejo de ver un montón de chips a la espera de ser tostados⁴.

A partir del visionado del vídeo en el que el amigo Ben se fabricaba un programador de EEPROMS con un Arduino⁵, me dio por leer poco más al respecto⁶. Por trata de profundizar algo más que la última vez que me puse a ello, pero todo está aún muy neblinoso.

Pero las formas van tomando consistencia. Parece que me voy acercando a algo y, a pesar de que por el momento no soy capaz de “leer” las especificaciones de los chips que tengo, hay formas que sí que voy siendo capaz de discernir.
Por un lado, y si no lo he interpretado mal, el chip que compré para actualizar a los Amiga sí que valdrá para ellos.

Por un lado, y por más que tenga 42 pines, encaja tanto en el zócalo del Amiga 500 (slot de 40 pines) como en el del Amiga 600 (42 pines, y lo que me llevó a conectar mal uno de los que había comprado con la última versión del Workbench). Por otro, igual aún puedo recuperar la ROM que me cargué.

Porque la cosa es que me dio por levantar la pegatina que tenía con la versión del sistema operativo, número de serie y temas similares, y resulta que es una EPROM que se puede borrar con luz ultra violeta y se puede volver a grabar.

Aparte de esto, comparando los patillajes vi que el direccionamiento de los pines de ambos se corresponde. Las patas 41 y 42 corresponden a dos líneas de entrada adicionales. Dos pata que no es necesario que use y que, en el caso del Amiga 500, sobresalen sin estorbar en el zócalo de 40 pines.

El hecho de que coincida su patillaje hace que tenga bastante confianza a la hora de afirmar que no la cagué a la hora de pedir esos chips que. Además, y como premio, resulta que son regrabables.

A partir del modelo de las ROMs originales de los Amiga he tratado de buscar correspondencias, pero no he encontrado nada directo. Las búsquedas de Google me han llevado siempre hasta foros en los que no se decía nada explícitamente, pero sí que se hacía referencia a cosas como el MX23C4100; otra EPROM cuyo patillaje es idéntico al de las que tengo por aquí.

Así pues, parece que la cosa promete.

Viendo el vídeo del programador del señor Eater también me ha quedado clara alguna que otra cosa más; el programador Willem⁷ que compré también me servirá para tostar EPROMs que tienen más patas que su zócalo.
Había leído que existían adaptadores para realizar la conversión, pero aquello era algo que se me hacía muy contraintuitivo. La parte técnica aún está un poco neblinosa en mi cabeza, pero tengo claro que la cosa va a funcionar (y he pedido el adaptador de marras).
En mi momento de flipamiento pensé en hacerme yo el adaptador pero, como de costumbre, cuando me puse a ello no tenía ni idea de por dónde empezar. Aun así no desespero, igual de aquí a un tiempo me lanzo a ello y a otras movidas que se me van pasando por la cabeza.

Por lo pronto, lo único con lo que puedo trastear hasta que me llegue el aparato son las ROMs del Atari.

Tengo cuarenta de ellas y sólo me hacen falta dos, así que puedo destrozar un montón sin sentirme (demasiado) culpable.

Y eso ha sido más o menos para lo que ha dado el mes. Por supuesto, no ha faltado el visionado de otro montón de vídeos⁸ de temas relacionados con el motivo original de este reto. Tengo intención de seguir adelante con la programación de juego y, por más que mi foco de atención haya cambiado de forma drástica, no me olvido de él.

Tengo claro que cuando vuelva con el código que ya tengo escrito tendré que volver a replanteármelo todo casi desde cero. Hay unas cuantas decisiones que tomé que, para mi yo de entonces, tenían sentido, pero a día de hoy me queda claro que fueron barbaridades.
El programa no se resiente, cosas de que las CPUs de hoy van sobradas para tragar lo que hice y que aún les sobren ciclos para dar y regalar, pero no quiero que mi criatura desaproveche ni un ciclo aunque el procesador se dedique a rascarse la barriga mientras tanto.

En fin. Planes y más planes.
Proyectos que no terminan de irse y flipamientos que no dejan de llegar.

La historia de mi vida resumida.

Enlaces:

1. El modelo

2. Ben Eater, ese hombre
- Building an 8-bit breadboard computer!
- The world's worst video card?

3. En anteriores capítulos...
- Nunca a la última 004
- Nunca a la última 009

4. Los chips
- Atari - M27C256B (UV EPROM)
- Amiga - MX23C4100 (¿Amiga Original?)
- Amiga - MX29F1615 (EEPROM Flash)
- Amiga - AM27C400 (AmigaStore)

5. Build an Arduino EEPROM programmer

6. Lo básico
- Basic information about memory chips and programming
- EPROMS: The minimum you need to know to burn your own
- Settings for Willem 4.1 Eprom Programmer
Con Raspberry
- Raspberry-Pi-Python-EEPROM-Programmer
- Raspberry Pi SPI and I2C Tutorial
- Raspberry-Pi I2C 256K EEPROM Tutorial
Con Arduino
- Arduino MX29F1615 programmer
- Arduino EEPROM programmer
- TommyPROM - An Arduino-based EEPROM programmer
A pelo
- Retro EPROM Programming Tutorial
- 27c801 EPROM Programmer Project
Borrando
- Improvising an EPROM programmer

7. Willem
- Adapter EPROM 16 Bit from Toomas Toots
- Willem EPROM Programmer User Guide
- Enhanced Willem EPROM Programmer – Manual
- Willem Eprom programmer for Win 9x/ME/NT/2000/XP
- Start CD

8. Vídeos de animación, retro y temas relacionados
- Cartridge Save File Preservation - Backup, Transfer & Restore Your Save Games
- RetroPixel 2019 - Conferencia Blasphemous
- Dead Cells: What the F*n!?
- Gato Roboto's Animation
- Game Discoverability Day: NOTICE ME: The Grind Behind the $272K Funding Success of Boyfriend Dungeon
- ¿Debe la universidad enseñar lo que demandan las empresas?
- Amstrad GameDev Challenge #01: BASIC vs C
- Planet X3 -The Making of, Part 4

Javier Albizu Mié, 10/07/2019 - 19:55

Bajo un océano de bits, mes XX

Recuperando un poco el tema bajo el que nació este epígrafe, este mes el foco ha vuelto a dirigirse hacia la programación.

Empezaremos con un clásico por estos lares, los vídeos del señor Fran Gallego¹. Este mes ha subido cinco nuevas entradas en su canal, todas ellas con reflexiones que siempre viene bien tener presentes.
En las dos primeras habla acerca de la necesidad de no limitarse a copiar cosas de Stackoverflow y similares. En tratar de ir más allá y leer el código de las cosas que estamos utilizando en nuestros proyectos.
Como de costumbre, la cosa aún me viene muy grande, pero no puedo estar más de acuerdo con este señor.

Además de esto, y dentro de su labor de divulgación del CPC, se ha montado un concurso para animar a la gente a programar cosas para esa máquina. Un reto en el que, bajo el justag de tuister #AmstradGameDevChallenge², Héctor Linares y él están haciendo un “Rpg” para la máquina de Alan Sugar. Dentro de este reto, cada uno de ellos forma parte de un equipo diferente en el enfrentamiento, el de los defensores del BASIC contra el de los partidarios del C.

Por supuesto, mientras se lanzan pullas amistosas entre ellos van demostrando distintas maneras de afrontar los mismos problemas.

Este mes también he descubierto una nueva fuente de información para seguir adelante con mi reto principal; el libro “Programación Retro del Commodore 64”³. Una obra que, lamentablemente, al venderse únicamente a través de Amazon no voy a comprar.

Mandé una consulta a su autor preguntándole por la posibilidad de adquirirlo a través de otras plataformas pero me dijo que, por el momento, no había alternativas. En su respuesta también me decía que, básicamente, lo que venía en el libro no deja de ser lo mismo que había apareciendo en su blog así que, acto seguido, lo que sí que hice fue fabricarme un PDF a partir de las entradas publicadas en él.
Aun así, si a alguien le interesa el libro no llega a los seis euros, así que el dinero no debería ser un problema para que os hagáis con él. Eso sí, igual si le da el coñazo un número mayor de personas decide ponerlo también en Lulu o alguna plataforma de POD.

Entre lo que encuentre en él y las referencias que va mencionando, espero llegar a ser capaz de desensamblar el Traz de Commodore para poder hacer un port lo más fiel posible a todos los niveles para PC.

Como él ha escrito el libro utilizando Windows y CBM Prg Studio, los ejemplos que se pueden descargar de su web no me sirven tal cual están, lo que pretendo utilizar a mi favor dentro de mi proceso de aprendizaje. Dado que el compilador de ese programa no es Acme, tendré que ir haciendo yo las conversiones a mano y ver las diferencias entre ambos.

Por el momento los cambios que he tenido que hacer no hay sido excesivos. Cosas como sustituir las cadena de bytes que Prg studio llama “byte” por “!byte”, o “text” por “!scr”.
También he tenido que añadir unas cuantas cabeceras para que el programa resultante funcione en el emulador. Por más que el compilador no diese errores a la hora de crear el archivo, el prg resultante no funcionaba en el emulador.

Supongo que estas son cosas que CBM Prg Studio “ofusca” y hace de forma automática dentro de sus proyectos para simplificar la labor del desarrollador, pero prefiero hacerlas a mano (y tratar de entender que hay en las posiciones de memoria a las que se llama byte a byte)

Otra diferencia que he encontrado es que ambos no tratan de la misma manera los caracteres y que, si quiero que me aparezca texto, tengo que escribir este en minúsculas ya que, si lo escribo en mayúsculas, lo que aparece en pantalla son los símbolos especiales que se encuentran en esas teclas.
Supongo que si quiero escribir el texto en minúsculas tendré que llamar a la rutina que cambia el modo gráfico de la pantalla, pero aún no he llegado a eso.

En paralelo a todo esto también he comenzado a mirar con un poco más de detenimiento los tutoriales de Dustlayer⁴ donde hay unos cuantos artículos muy interesantes acerca del hardware del Commodore. Por otro lado, los ejemplos que trae están diseñados para Acme, por lo que esos no voy a tener que tocarlos para que funcionen (aunque su autor los haya creado en un Mac).

Dentro de mis búsquedas a través de la red también he encontrado una nueva herramienta para el desarrollo, C64 Unit⁵; un framework de pruebas para software de Commodore. Aún queda mucho para que pueda plantearme el utilizarlo, pero no está de más el tenerlo localizado.
Eso sí, para compilarlo he necesitado instalar un compilador cruzado más; 64tass.

Antes de terminar por hoy, sólo pondré un par de apuntes adicionales.
Por un lado, que no lo haya mencionado en esta entrada no quiere decir que haya abandonado el tema de las EEPROMS⁶. He retomado (por vez N) un libro de fundamentos de la electrónica que me dejó un amigo hace años. A falta de más vídeos de Ben Eater, también sigo buscando otras fuentes a ese respecto (aunque no todas son igual de amistosas).

Por otro, y siguiendo con el tema del visionado de vídeos, no podían faltar por aquí los habituales enlaces a las charlas del GDC⁷ que han caído este mes.

Y más o menos eso ha sido todo lo que he hecho desde la última entrada. A día de hoy, mi escenario de trabajo es Vim + Acme + Vim-acme + Droid 64 + Vice 3.3 y, de aquí a un tiempo, supongo que empezaré a utilizar SpritePad, VChar64 y C64 Debugger.

Salvo Vim, el resto de cosas que voy utilizando las he compilado a mano porque, en la versión de Vice que está en los repositorios de Ubuntu, el monitor con el que se accede al estado de la memoria tenía un comportamiento un poco extraño.

Si a alguien le interesa montarse un entorno similar, no tendría problema en publicar por aquí una guía acerca de cómo he ido montando esto en mi máquina.

Enlaces:

1. Profesor Retromán
- C++ : ¿Por qué reserva 71K un programa vacío?
- Habilidades para ser mejores ingenieros

- Amstrad GameDev Challenge #01: BASIC vs C
- Amstrad GameDev Challenge #02: BASIC vs C
- Amstrad GameDev Challenge #03: BASIC vs C

2. Los contendientes y su juastag
- Fran Gallego
- Hector Linares
- #AmstradGameDevChallenge

3. Programación Retro del Commodore 64
- El libro
- El blog
- Entrevista al autor en AmigaWave #168

4. Dustlayer y el hardware
- Ram under Rom - a brief look into C64 memory
- Hardware Basics Part 1 - Tick Tock, know your Clock
- Hardware Basics Part 2 - A Complicated Relationship

5. C64 Unit
- C64 Unit - La web
- C64 Unit - En BitBucket
- 64tass - El compilador
- 64tass - La guía

6. La electrónica
- The Learning Circuit - How Logic Gates Work
- The Learning Circuit - Making Logic Gates From Discrete Components
- Fundamentos de Sistemas Digitales
- Basic Willem EPROM Programmer To Make Sega Genesis/Mega Drive Reproductions
- Retro EPROM Programming Tutorial
- Lecture 36 ROM-EPROM,EEPROM and Flash EPROM

7. Charlas GDC
- Letting Go: A Florence Postmortem
- Motion Capture Performance: An Actor's Approach
- Trailer Made: What Makes a Successful and Memorable Game Trailer
- Math for Game Programmers: Dark Secrets of the RNG
- Three Statistical Tests Every Game Developer Should Know
- 2019 Animation Tricks of the Trade

Javier Albizu Mié, 07/08/2019 - 20:58

Bajo un océano de bits, mes XXI

Cuanto más avanzamos más nos vamos alejando del propósito inicial de este reto. Pero esto va del aprendizaje y comprensión de lo binario y sus aledaños, así que el ámbito no tiene límites.

De manera sorpresiva, este mes ha tenido una especial presencia en mi pantalla el mundo de la animación a través de Daniel Floyd y su canal New Frame Plus¹. Fue empezar y no poder parar de ver sus vídeos hasta terminar con el último de ellos.
Llegué hasta él a través de un viejo conocido de esta serie de artículos; Dan Root², a cuyo canal también estoy suscrito y que, con ritmo lento, también continúa aportando datos de lo más interesantes acerca de un mundo al que sólo me había acercado de oídas..
Como con todo, todo lo que rodea a la animación compone un universo insondable, y la cantidad de matices que se pueden sacar del más nimio de los gestos no dejan de sorprenderme.

En otro orden de cosas, este mes se me ha fastidiado uno de los discos duros del servidor que tengo en casa. Y esto no sería nada significativo (no es la primera vez, cosa de montarte un servidor con restos de otros equipos), de no se porque me ha dado por preguntarme ¿y cómo funciona esto?³.
No es que haya profundizado demasiado pero, una vez más, me ha dejado con más preguntas que las que tenía cuando empecé. No escarmiento.

Ya que estaba, también me ha dado por mirar cómo funcionan (funcionaban) los disketes. Más concretamente el formato ADF que utilizan los emuladores de Amiga y la emulación de la disketera del Commodore 64⁴. Para sorpresa de nadie, ha pasado tres cuartas partes de lo mismo que con lo anterior. No me miréis así, sé que soy débil, pero es que me han dibujado así.

También apareció un artículo ante mis ojos en el que mencionaban unos cuantos motores para diseñar videojuegos que no conocía⁵. A esto me fue más fácil resistirme, pero lo dejo por aquí por su alguien los encuentra de utilidad.

Siguiendo con la parte de los vídeos, por esta casa no han podio faltar el profesor RetroMán⁶, las charlas del GDC⁷ y el amigo Ben Eater⁸.

Sí. Efectivamente. Como habrás podido deducir, de código ha habido poco avance desde la última vez que escribí sobre el asunto.

No obstante, algún pequeño avance sí que he llevado a cabo. Quizás sea tan tenue que apenas pueda ser considerado como avance, pero alguna que otra página del blog “Programación Retro del Commodore 64” ha caído y, recientemente, su autor ha continuado con las entradas para adentrarse en la programación de una versión del Asteriods en ensamblador⁹.

Y…, más o menos, eso ha sido todo.. Ahora sólo tengo que reunir fuerzas para no terminar de leer la trilogía sobre la historia de Commodore cuya última entrega me ha llegado esta semana y ver si para cuando termine el año tengo algo que sirva para algo como resultado de todo esto.

Enlaces:

1. New Frame Plus
- Dan Floys en tuister
- La Animación de Punch-Out!!
- What Happened with Mass Effect Andromeda’s Animation?
- Tracer & Pose Design 101 - The Animation of Overwatch
- Where To Learn More About Game Animation
- Como los Personajes de Overwatch transmiten personalidad en primera persona
- How to Animate a Smash Bros Character // MARIO
- How to Animate a Smash Bros Attack // LINK
- Spider-Man: La Animación del Impulso Puntual - New Fram Plus
- ¿Es la animación de Red Dead Redemption 2 muy lenta?
- The Bizarre Animation of MR. GAME & WATCH
- Why Skyrim's Mining Animation Is Bad
- My Favorite Game Animation of 2018
- ¿Pueden los juegos antiguos tener buena animación?
- How To Become a Game Animator
- ¿Cómo ha evolucionado la animación de batalla en Pokémon?
- RITMO - Los 12 Principios de la Animación
- Which Dark Souls Has the Best Parry Animation?
- The Animation of Guilty Gear Xrd & Dragon Ball FighterZ
- How Link's Climbing Animation Works in Breath of the Wild

2. Dan Root
- Dynamic Frames in Dustforce
- Fez's Animated Environments
- Breath of the Wild is a Standalone Game
- Behind the Schemes: GRIS with Nomada Studio
- The Animation of Gris
- How to Wield the Master Sword // Video Game Animation Study

3. Duros de verdá
- How to interpret smartctl messages
- Fixing bad blocks on HDDs using fixhdd.py
- fixhdd.py
- Is this a bad sign: smartd: 1 Currently unreadable (pending) sectors....?

4. Los discos y sus cosas
- El formato ADF
- Pi1541 Build (Commodore 1541 Emulator)
- Pi1541 Build
- 6502 - Writing a disk file using assembly on Commodore 64

5. Más motores
- GDevelop
- Stencyl
- RenPy
- Kodu Game Lab
- Game Salad

6. El profe
- Avance Amstrad GameDev Challenge #04: #TeamBASIC misterio memory leak
- Amstrad GameDev Challenge #04: BASIC vs C. Especial Gráficos UDG
- Sprites con caracteres en BASIC de Amstrad CPC

7. Y las GDC
- Bringing Fantasy to Life in Final Fantasy XV
- Audio Choreography for Battle Design
- Conquering the Creative Challenges in Marvel's Spider-Man
- 09 to '19: A Decade of Approachability in Fighting Games
- Making of ASTRO BOT Rescue Mission: Reinventing Platformers for VR

8. Ben Eater y la detección de errores en las comunicaciones

9. Asteroids para el Commodore 64
- Un primer juego sencillo: Asteroids
- Asteroids: estructura del proyecto
- Un primer juego sencillo: Asteroids
- Asteroids: la pantalla de juego
- Asteroids: la nave
- Asteroids: configuración y posicionamiento de la nave

Javier Albizu Mié, 04/09/2019 - 21:02

Bajo un océano de bits, mes XXII

El tiempo continúa transcurriendo y los ánimos se mantienen en un estado de incertidumbre. Estas han sido unas semanas de ver muchos vídeos y leer cosas, pero de picar código ha habido poco. Sigo con el cerebro un poco derretido y no me está dando para mucho.

En lo referente a la práctica activa de la programación, lo único que he hecho ha sido practicar un poco con algunas de las herramientas que disponía¹ como son “Droid 64” y ” “petcat” para poder escribir el código en Basic del Commodore desde Linux y luego convertirlo ese texto en un binario que sea capaz de entender VICE.

Los primeros listados en Basic del manual de usuario los escribí hace unos meses directamente en el emulador, pero resultaba una labor bastante incómoda. Aun así, no tenía demasiada opción porque la exportación de los PRG a texto plano que hacía Droid 64 dejaban bastante que desear.

Por otro lado, a la hora de tratar de convertir los archivos de texto directamente a PRG con petcat aquello petaba por todos lados. Cuando trataba de listar el código en el emulador los caracteres que me mostraba no tenían demasiado que ver con los que había escrito. Así pues, al principio la cosa fue complicada. No sabía cómo escribir “desde fuera” las teclas especiales del C64 y eso me rompía el código. Aparte de eso, y al igual que me sucedió con Acme, hasta que no llegué a entender que tenía que escribir todo el código en minúsculas me retrasó bastante. Las mayúsculas no las interpretaba como la letra que yo veía, sino como el carácter especial que aparece en el Commodore cuando las combinas con el “Shift”.

Pero…
Tras extraer con Droid 64 el archivo PRG “en crudo” de uno de los discos virtuales de Commodore que había creado, y realizar la conversión de ese PRG a un archivo de texto con petcat la luz se “hació”

Convertir de Prg a Bas:
petcat -2 -o archivo_de_destino.bas -- archivo_de_origen.prg

Ahí pude ver que mnemónico tenía este programa para combinaciones de teclas como las de “CLR/HOME” del Commodore. Es más, bobo de mi, estaban todas documentadas en su página de ayuda. No sé cuántas veces había mirado ese documento hasta darme cuenta de que eso había estado ahí todo el rato.
En fin, una vez superado ese bache en mi comprensión lectora, la cosa ya fue mucho más sencilla. Es más, comprobé también que podía ahorrarme los mnemotécnicos de petcat utilizando las tablas de código ASCII que vienen en el manual del Commodore. Una vez hecho esto, para convertir un archivo de texto plano a Prg eran tan sencillo como ejecutar un:

petcat -wsimon -o archivo_de_destino.prg -- archivo_de_origen.bas

Pero claro, la cosa no podía quedar ahí y esto me llevó a mirar otra serie de cosas. Consultas basadas en gran medida en los vídeos de la Competición Basic vs C².
Comprobé que, aunque el resultado en pantalla es idéntico, poner un “10 print "{clr}" no es lo mismo que escribir “10 print chr$(147)”. Al igual que sucede con el BASIC de CPC, el número de caracteres influye en lo que la memoria que va a ocupar el programa.

Emocionado de la vida ante aquel nimio avance, decidí hacer otra prueba loca. Nuevamente con Droid 64 exporté el PRG del Traz a código ensamblador y, tras hacer dos pequeños apaños, traté de compilarlo con Acme sin erótico resultado.
Aquel era el resultado esperado y, obviamente, ya desde antes era consciente de que aún me queda mucho por entender antes de lanzarme a desensamblar un programa, pero en ese punto fue en el que la cosa se volvió a descontrolar… una vez más.

Youtube es una mala influencia y, de vez en cuando, las sugerencias de sus algoritmos parecen acertar y recomendarte algo válido o, cuando menos, prometedor. Referencias que me hacen danzar de un lado a otro³ buscando “el método”. Un método que no voy a encontrar fuera pero que, ahora mismo, no tengo el nivel de concentración necesario para alcanzar por mi mismo.

Más allá de los recién llegados, los viejos conocidos⁴ continúan produciendo material. Lo nuevo de Ben Eater promete, y las entradas del blog “Programación Retro del Commodore 64” siguen un ritmo que no soy capaz de seguir (más aún cuando no he terminado con el libro original). Por el momento cada una de ellas va alimentando el documento de texto en el que las voy recopilando.
Como premio, con la llegada del nuevo curso, Fran Gallego ha empezado el curso con fuerza siempre con cosas interesantes.

Por su parte, Gamasutra me ha hecho conocer y amar a Jeff Vogel, mientras me mostraba que en Itch.io⁶ puedes agrupar los juegos por el motor que se ha utilizado para crearlos (teniendo algunos de ellos incluso enlaces al Github en el que se aloja su código).

En fin. Toca recomponerse, tratar de buscar el equilibrio y marcar una ruta que sea capaz de seguir.
En cuatro semanas te cuento si he sido capaz de hacer algo de eso.

Enlaces:

1. Herramientas para Basic
- Petcat es tu amigo
- Droid 64 no tanto

2. La guerra que acabará con todas las guerras
- Amstrad GameDev Challenge #05: BASIC vs C
- Amstrad GameDev Challenge #06: BASIC vs C. Especial RetroZaragoza En Vivo

3. One Lone Coder y más cosas que mirar para evitar ponerse a hacer
- Code-It-Yourself! Tetris - Programming from Scratch (Quick and Simple C++)
- NES Emulator Part #1: Bitwise Basics & Overview
- Learn 6502 Assembly Programming - Lesson1 : For absolute beginners!
- Ensamblador VASM
- VASM
- Retro Insectivores: Finding and Eliminating Bugs in NES Development

4. Los de siempre

Ben Eater
- “Hello, world” from scratch on a 6502

Programación Retro del Commodore 64
- Asteroids: movimiento sencillo de la nave
- Asteroids: movimiento de la nave con ángulo y velocidad
- Asteroids: nave con giros controlados
- Asteroids: eliminación de zonas ocultas
- Asteroids: información en la zona derecha de la pantalla
- Asteroids: disparos
- Asteroids: disparos – rutinas accesorias
- Asteroids: disparos – algunas mejoras necesarias
- Asteroids: disparos – caracteres personalizados
- Asteroids: los asteroides
- Asteroids: los asteroides – un híbrido entre la nave y los disparos
- Asteroids: configuración y posicionamiento de los asteroides
- Asteroids: movimiento de los asteroides

El profe
- Instalación de CPCtelera 1.5 development branch
- Ejemplo básico: dibujar y mover un cuadrado con CPCtelera 1.5
- Introducción a la arquitectura Entity-Component-System (ECS)
- Arquitectura Entity-System: implementación básica inicial
- Arquitectura Entity-System: revisando la implementación inicial [#ASM #Z80]
- Ensamblador, linker, includes y símbolos globales [#ASM #Z80]
- Gestión automática con macros y constantes [#ASM #Z80]
- Creando Videojuegos: Iteraciones y Calidad de Producto
- Dudas, consejos y fé de erratas [#ASM #Z80]
- Entity-System (II): sistemas físico, input y render [#ASM #Z80]
- IA Básica: Árboles de Decisión y Niveles de Abstracción en Videojuegos [#ASM #Z80]
- Implementando el sistema de IA básico [#ASM #Z80]
- Entity-System (II): revisión y dudas [#ASM #Z80]
- Revisión del modelo de IA básica implementado [#ASM #Z80]

Dan Root
- The Animation of Metal Slug
- The Animation of Hollow Knight

GDC
- Beyond Framerate: Taming Your Timeslice Through Asynchrony
- How to Get a Job Writing for Games
- The Art of Wonder Boy: The Dragon's Trap

5. Jeff Vogel
- Why All My Games Look Like Crap
- I Am the Cheapest Bastard In Indie Games

6. Los motores y más
- Which are the most commonly used Game Engines?
- Juegos por "engine" en Itch.IO
- Spelunky HD en Itch.IO
- Spelunky HD en Github

Javier Albizu Mié, 02/10/2019 - 22:17

Bajo un océano de bits, mes XXIII

Cuando nos encontramos tan cerca del final volvemos al principio. A los tipos y conceptos básicos. A tratar de entender un poco mejor esas cosas que antes nos limitábamos a copiar de la red o los manuales porque… “funcionaban”.
A tratar de expresar con mis propias palabras lo que creo haber entendido, lo que he asumido como ciertas a partir de lo que he visto, leído y hecho.

Porque este ha sido otro de esos meses en los que apenas he tocado el teclado para escribir código. Aun así, poco a poco los conceptos se van asentando en mi cabeza. Cosas que, por más que leí cuando comenzaba con esto, no terminaba de asimilar. Y es que las lagunas de mi conocimiento son muy profundas y mi capacidad de concentración en estos últimos años ha dejado bastante que desear.

Pero, por suerte, tengo los vídeos del Profe¹. En gran medida, si he logrado avanzar en este proceso de comprensión en estos últimos tiempos, esto ha sido gracias a los vídeos del señor Fran Gallego que, tras el inicio de curso, sigue con su imparable subida de vídeos diaria.

Porque, a base de escuchar como con su paciencia infinita va desgranando los secretos del “debugger” del WinApe, algo va quedando.
En conjunción con esto, los vídeos de Ben Eater también me han ayudado a hacerme una visión global de lo que sucede dentro del procesador. A entender más o menos que significa una arquitectura de 8, 16, 32 o 64 bits. A entender que, aunque aunque el z80 es un procesador de 8bits, también posee registros de 16 que gracias a los que puede acceder hasta 64 ks de RAM. A descubrir como, gracias al intercambio de bancos de memoria² se podían llegar a gestionar cantidades de memoria mayores a las previstas por el procesador con leves modificaciones en la arquitectura de la máquina o del sistema operativo (lo de leves es un decir).

Como digo, poro a poco las piezas van encajando. Con décadas de retraso, los misterios arcanos detrás de las líneas del Autoexec.bat y el Config.sys van teniendo un poco más de sentido.

No sé cuántas explicaciones he leído acerca de lo que es un puntero, cuantos ejemplos he visto, o cuántos he creado yo por mi cuenta, pero seguía siendo un concepto que se me hacía difuso. Hoy, tras escribir un pequeños programa, las cosas se van asentando un poco (aunque hay ciertos aspectos que me siguen eludiendo)

Por un lado, la manera en la que se se trabajan en C++ con los distintos tipos de punteros se me siguen escapando un poco. Creo que es una cosa de la implementación concreta en este lenguaje, pero no deja de ser una jodienda.

Por otro lado, una vez superado el escollo de escribir el código que buscaba (algo que tampoco me ha resultado trivial), una parte de los resultados que me han aparecido no han sido los que esperaba.

Variable	Valor
TextoConst	Hola Mundo
&TextoConst	0x55fd6c1dcd60
TextoConst[0]	H
&TextoConst[1]	ola Mundo
&TextoConst[2]	la Mundo
TextoNoConst	Holita mundo
&TextoNoConst	0x55fd6c1dd138
TextoNoConst[0]	H
&TextoNoConst[1]	olita mundo
&TextoNoConst[2]	lita mundo
NumeroNoConst	0x55fd6dd62e90
&NumeroNoConst	0x55fd6c1dd140
&NumeroNoConst	66
Caracter	L
&Caracter	L
Numero	99
&Numero	0x55fd6c1dd14c
TextoNoConst	Adiosito mundo
&TextoNoConst	0x55fd6c1dd138
TextoNoConst[0]	A
&TextoNoConst[1]	diosito mundo
&TextoNoConst[2]	iosito mundo

Porque… ¿por qué la variable tipo char_no_puntero cuando la llamo por referencia (&Caracter) no me da una posición de memoria, y la tipo_int_no_puntero (&Numero) sí?
¿Por qué el puntero_a_int (NumeroNoConst) me da dos posiciones de memoria diferentes dependiendo de si la llamo directamente o por referencia?

De nuevo, asumo que esto deben ser cosas de la implementación de C++, pero no dejan de ser ejemplos de que estoy trabajando con una herramienta que no termino de comprender. De que las cosas que he hecho funcionan gracias al copia pega acrítico del código de otros, no porque tenga del todo claro lo que estoy haciendo.

En otro orden de cosas, el tratar de entender los punteros es algo que sí que me ha ayudado a aclarar el porqué de los “números” en las arquitecturas de procesadores.
El entender que si tengo 8 gigas de RAM en mi ordenador (unos 8,000 millones de bits), un procesador con registros de 32 bits (salvo que hagan ñapas como el intercambio de bancos) nunca podrá llegar hasta la información que se encuentre más allá de los 4,000 millones ya que sus registros no pueden almacenar unos números tan grandes como aquellos en los que se encuentran esas posiciones de memoria.

Size	Valores únicos representables	Notas
8-bit	256	= 2⁸
16-bit	65 536	= 2¹⁶
32-bit	4 294 967 296	= 2³² (~4.000 Millones)
64-bit	18 446 744 073 709 551 616	= 2⁶⁴ (~18 billones de millones)

(esta tabla la he sacado de aquí ³)

Y no sé si esto que estoy escribiendo tendrá sentido para alguien que no sea yo. La manera en la que he plasmado esto no deja de ser una interpretación personal, pero sí que creo que sería capaz de explicárselo a alguien que compartiese esta curiosidad. Y este no me parece un logro menor.

En fin. Aparte de esta pequeña reflexión, durante este mes también han⁴ ido⁵ apareciendo⁶ muchas cosas más por la red a las que les he ido hincando el diente, y quedan otras tantas pendientes para⁷ más adelante⁸, pero creo que con esto ya es suficiente por hoy.

Enlaces:

1. El Profe

- Ensablador
- Sistema de IA: implementando la acción move_to [#ASM #Z80]
- Entity-System (II): Análisis de Rendimiento, Problemas y Mejoras [#ASM #Z80]
- Entity-System (III): ajustes en los sistemas [#ASM #Z80]
- Sistema de IA: Comportamiento 'Patrol' básico (I) [#ASM #Z80]
- Sistema de IA: 'Patrol' básico (II), mejoras de código [#ASM #Z80]
- Revisión IA 'Patrol' y Entity-System (III) [#ASM #Z80]
- Enfrentándose a flickering y tearing: analizando el raster [#ASM #Z80]
- Técnicas de renderizado y restauración del fondo [#ASM #Z80]
- Render y restauración del fondo (II): modo XOR, tiles tocados y sprites por partes [#ASM #Z80]
- Entender los detalles y ser minuciosos para mejorar en ingeniería
- Entity-System (IV): managers con punteros y mejoras de código [#ASM #Z80]
- Primer dibujado XOR: evitar costes con código automodificable [#ASM #Z80]
- Sistema de colisiones: implementación básica con array de punteros [#ASM #Z80]
- Colisiones entre bounding boxes [#ASM #Z80]
- Entity-System (IV): revisión de estructura e implementación [#ASM #Z80]
- Colisiones con múltiples entidades [#ASM #Z80]
- Optimizaciones de Colisiones e IA
- Entendiendo dibujado de tilemaps en CPCtelera y colisiones [#ASM #Z80]
- Saber limitarse al planificar proyectos
- Pautas simples de Game Design
- Herramientas de depuración y mejoras de código [#ASM #Z80]
- Sistema básico de animaciones (I) [#ASM #Z80]
- Sistema básico de animaciones (II) [#ASM #Z80]
- Entity-System (V): Estructura y Animaciones [#ASM #Z80]
- Sistema de animaciones: estados de movimiento [#ASM #Z80]
- Sistema de animaciones: cambios de secuencia [#ASM #Z80]
- Depuración de bugs irregulares: playback session de WinAPE [#ASM #Z80]
- Compresión de binarios e imágenes en CPCtelera [#ASM #Z80]
- Convertir y reproducir música: Arkos Tracker CPCtelera [#ASM #Z80]
- Controlando las interrupciones [#ASM #Z80]
- Música por interrupciones [#ASM #Z80]

- Basic
- Amstrad GameDev Challenge #07: BASIC vs C #ECS #TeamFromScratch

2. Accediendo a la memoria
- Bank Switching
- Expanded memory
- Extended memory

3. Tamaños de variables y registros

4. GDC
- GDC Plays indivisible with Mike Z and Mariel Cartwright

5. New Frame Plus
- Squash & Stretch - The 12 Principles of Animation in Games

6. Dan Root
- X7 and The Importance of Principles
- The Key to Metroid Prime's Atmosphere

7. Programación Retro del Commodore 64
- Asteroids: activación de nuevos asteroides
- Asteroids: colisiones de la nave con los asteroides
- Asteroids: una explosión en condiciones
- Asteroids: colisiones – algunas mejoras necesarias
- Asteroids: colisiones de disparos con asteroides (paso I)
- Asteroids: colisiones de disparos con asteroides (paso II)
- Asteroids: colisiones de disparos con asteroides (paso III)
- Asteroids: información en la línea inferior de la pantalla
- Asteroids: movimiento de los sprites por toda la pantalla (paso I)
- Asteroids: movimiento de los sprites por toda la pantalla (paso II)

8. Unraveling the jpeg

Javier Albizu Mié, 30/10/2019 - 19:29

Bajo un océano de bits, mes XXIV

Al igual que lleva sucediendo durante los últimos meses, afrontamos las últimas acometidas de los distintos retos presentes con una capacidad de concentración cada vez más mermada.
Básicamente, me estos limitando a hacer acopio de enlaces para cuando vengan días mejores sin ser capaz de procesar ninguno de ellos como sería debido.

Aun así hemos logrado algo parecido a pequeños logros. Es lo que tienen la cabezonería y la repetición.

A lo largo de este mes, el profe¹ ha terminado con las clases de ensamblador para Z80 y ha vuelto a comenzar con las clases de C++. Podría decir que todo eso “ya lo he visto” en sus vídeos de otros años, pero con cada nueva iteración va añadiendo explicaciones adicionales y, si bien en ediciones anteriores ya había hablado de la creación de Makefiles, el enfoque que están teniendo las lecciones sobre ellos y el lenguaje de maros en esta nueva tanda se me hace nuevo, complejo, clarificador al mismo tiempo.
Por supuesto, cuando me ponga con mis propios scripts de compilación con Make me daré cuenta de que no he entendido nada y tendré que revisarme una vez más estos vídeos, pero si que se van descubriendo conceptos que hasta ahora estaban ofuscados dentro de las diferentes capas de abstracción.

Por su parte, en Programación retro para el C64² han terminado con las entradas dedicadas a la creación de un clon del Asteriods para el Commodore 64. He de reconocer que no he leído las entradas, pero el PDF en el que he recogido todo el material de ese blog ya ocupa trescientas veinticinco páginas.

En su momento metí la primera parte de ese documento en mi ebook, pero me quedé bloqueado en las entradas que hacían referencia a la gestión de la memoria del C64. Algo similar a esto ya me había sucedido cuando me puse con la guía del usuario del propio ordenador, así que, hasta cierto punto, era el resultado esperado.

Dado lo limitado de mi capacidad de asimilación igual tengo que dar ese paso que llevo retrasando desde hace mucho y saltar hasta el nivel físico antes de continuar con las capas superiores.
En estos días Ben Eater³ está con su proyecto de hacer un ordenador de 8 bits alrededor de un 6502 y, al mismo tiempo, en su página ofrece kits para replicar los montajes de hardware que hace en su canal. Hacer algo de esto es una cosa que me lleva tentando desde hace mucho, pero no quiero limitarme a replicar lo que él hace. No quiero montar un mueble de Ikea recomponer un puzzle para que sea igual que la foto que viene en su envoltorio. Tengo que empezar de menos a más. Entender cómo funcionan la electrónica sobre las que se construyen las puertas lógicas y hacer circuitos sencillos. Entender cómo se almacena la información y la manera en la que se comunican los diferentes componentes.
Hace tiempo pedí a un amigo que se mueve en el territorio de la electrónica que me recomendase algún oscioloscopio⁴ con unas prestaciones mínimas como para poder meterme en un berenjenal de este tipo, pero aún ando dudando en el qué, el cómo y el cuándo meterme con ello a fondo.
Lo que tengo claro que este no es el momento, pero también tengo claro que ese ”ahora” no llegará hasta que yo lo decida así. No es una cuestión de magia, serendipias o musas.

Por el camino también se me han cruzado otro par de proyectos la mar de interesantes⁵: Entornos de desarrollo con los que programar cosicas para el Amiga y la MegaDrive. Herramientas con las que meterme más adelante; cuando entienda un poco más del hierro que tienen debajo.
Eso sí, últimamente estoy encontrándome bastante a menudo VASM, un compilador cruzado para ensamblador de distintos micros viejunos que, a pesar de que está a punto de cumplir la mayoría de edad, parece que ahora es cuando va ganado tracción.

Para terminar de arreglar las cosas, a principios de mes me apunté al curso intensivo online de once semanas “Introduction to Computer Science”⁶ que ofrece Havard a través de la plataforma EDX.
A pesar de no haber sido capaz de mantener el ritmo de dedicación que se recomienza (veinte horas semanales) sí que he sido capaz de solventar algunos de los ejercicios que plantean. Seguramente no terminaré en el plazo indicado, pero espero que al menos me sirva para comenzar a entender o familiarizarme con conceptos básicos de otros lenguajes como el SQL el PHP o el CSS.

Más allá de todas estas disquisiciones y movidas varias también he seguido con el resto de canales habituales que suelen aparecer por aquí⁷.
Porque ¿por qué centrarme en una única cosa cuando existe todo un universo de dispersión?

Enlaces:

1. El Profe

CPC
- Control avanzado de las interrupciones [#ASM #Z80]
- Revisión de música y uso de interrupciones [#ASM #Z80]
- Pantallas de carga en 3 minutos con CPCtelera [#ASM #Z80]
- Fuentes de texto personalizadas con CPCtelera [#ASM #Z80]

C y C++
- C y C++ : Compilación manual, extern "C", includes y mangling
- C++ : Compilación, enlazado y makefiles básicos (I)
- C++ : Compilación y makefiles básicos (II)
- C++ : librerías, dynamic link y búsqueda de símbolos de enlace
- C++ : Dibujando sprites manualmente con tinyPTC
- C++ : Makefiles con macros avanzadas y reglas generadas

2. Programando un clon de Asteroids en ensamblador para C64
- Asteroids: movimiento de los sprites por toda la pantalla (paso III)
- Asteroids: movimiento de los sprites por toda la pantalla (paso IV)
- Asteroids: el reto de los asteroides que siempre se expanden
- Asteroids: niveles de dificultad progresivos
- Asteroids: pantalla inicial y pantalla de juego – nueva pantalla
- Asteroids: pantalla inicial y pantalla de juego – comienzo de partida
- Asteroids: pantalla inicial y pantalla de juego – final de partida
- Asteroids: pantalla inicial y pantalla de juego – inicializaciones
- Asteroids: una pantalla inicial un poco más sofisticada
- Asteroids: sonido y música – repaso del SID
- Asteroids: sonido y música – visión global
- Asteroids: sonido y música – inicialización del SID y las voces
- Asteroids: sonido y música – tablas de definición de los sonidos
- Asteroids: sonido y música – eventos con sonido
- Asteroids: sonido y música – reproducción de los sonidos
- Asteroids: presentación de números en decimal – repaso de conceptos
- Asteroids: presentación de números en decimal – posible uso de BCD
- Asteroids: presentación de números en decimal – velocidad, ángulo y vidas
- Asteroids: presentación de números en decimal – coordenadas X e Y
- Asteroids: presentación de números en decimal – puntos y record
- Asteroids: algunas sugerencias para el lector
- Asteroids: el reto de los asteroides que siempre se expanden (solución)
- Asteroids: mapa de memoria y librerías mejoradas
- Asteroids: conclusiones

3. Ben Eater
- How do CPUs read machine code? — 6502 part 2
- Assembly language vs. machine code — 6502 part 3
- Kit 8 bits Computer
- Kit 6502

4. Osciloscopios
- HANTEK DS5102P
- RIGOL DS2202A
- SIGLENT SDS2202X-E
- TEKTRONIX TBS1102B
- KEYSIGHT DSOX1102A

5. Programación para plataformas retro
- Want to code Amiga games in Assembler? If so then read on!
- Amiga Game Development
- VASM
- Cómo hacer un videojuego para la SEGA Mega Drive original en pleno 2019
- SGDK
- GenDev

6. CS50 - Introduction to Computer Science

7. El resto de los habituales

GDC
- Parkour: How to Improve Freedom of Movement in First-Person Games in 20 Simple Steps

Dan Root
- The Animation of Indivisible
- Indivisible Animated Opening by Studio TRIGGER and Titmouse

New Frame Plus
- The Effects Animation of Hollow Knight

The learning circuit
- The Learning Circuit - How To Drive A 7-segment Display
- The Learning Circuit - Combinational Logic Devices
- The Learning Circuit - How Flip Flops Work

Javier Albizu Mié, 27/11/2019 - 22:13

Bajo un océano de bits, mes XXV

Poco hemos avanzado a lo largo de este mes. Aunque, claro, dependiendo de cómo lo mire, no sólo no he avanzado sino que he retrocedido.

¿Cómo?
¿Que puede ser que me haya puesto un tanto dramático?.
¿Yo?.
Por favor.

En fin, vayamos por partes.

Me encuentro en una encrucijada el lo referente al C++.
Si algo me está quedando claro a partir del visionado de las clases de este año de Fran Gallego¹, esto sería el hecho de que los textos de referencia que había seguido hasta el momento no estaban teniendo en cuenta las evoluciones que ha sufrido este lenguaje durante la última década.

Por lo que estoy viendo se han hecho esfuerzos significativos para “facilitar” el acceso hasta él y acercarlo hasta otros lenguajes más “amistosos”. El “nuevo C++”² tiene cosas como “Auto”, “Fill” o “Pragma” diseñadas para este fin. Para abstraer al desarrollador a la hora de realizar cosas en apariencia triviales… pero, precisamente por esto, me resisto un poco a usarlas.

A pesar de que tengo claro que son funciones mucho más óptimas que las cosas que pueda ir haciendo yo al vuelo, me esconden lo que hay detrás de ellas (siempre y cuando no me ponga a analizar su código, claro). Pueden ser herramientas ideales para quien se quiera acercar a la programación de nuevas, pero no las considero útiles para el proceso de aprendizaje que me he propuesto. Al menos no en el momento en el que me encuentro ahora mismo.

A su vez, toda la filosofía alrededor de la programación orientada a objetos se me sigue haciendo muy abstracta. A pesar de los vídeos, me cuesta mucho terminar de conceptualizar y aterrizar la herencia y el polimorfismo. Si bien es cierto que tengo una idea muy somera acerca de todo ello, se me sigue haciendo un poco bola cuanto trato de “visualizarlas”. “Entiendo” lo que son las clases virtuales y las relaciones de parentesco que se pueden establecer entre ellas… pero me cuesta horrores conseguir aterrizar eso al terreno de lo concreto.

Podría ponerme con ello, tengo pendiente volver a rehacer desde cero el código que ya tengo para mi clon del Traz pero, en paralelo a todo esto, también sigo con la parte de más bajo nivel y no es cuestión de dispersarme aún más.

Porque otra cosa no pero, allí donde me adentro, la dispersión sigue siendo la norma.

Por un lado, hace poco descubrí los vídeos de Michael Steil³ y sus charlas acerca de las interioridades de distintas máquinas. Por el momento me he centrado en aquellas que tienen alguna relación con el 6502 pero, a buen seguro, antes o después van a terminar por caer también todas las demás.

Por otro, un compañero del trabajo me descubrió un par de semanas atrás el canal de ObiJuan⁴ y su FPGAWars. Empecé a echarle un ojo a sus charlas sobre FPGAs, a su repositorio de Git y al IceStudio, el entorno de desarrollo que ha creado junto a otro montón de gente para trabajar con FPGAs libres. Incluso estuve tentado de comprarme una IceZum Alhambra, pero en el último momento me frené. Ya tengo por casa un par de ZX-UNO y, a priori, podría utilizar alguna de ellas para el cacharreo.

Por lo que he podido ver, en principio IceStudio no soporta la FPGA que viene con el ZX-UNO, la Xilinx Spartan XC6SLX9-2TQG144C pero, ¿quién sabe?, quizás de aquí a un tiempo lo incluyan (o me termine de volver loco del todo al tratar de implementarlo yo mismo).

Porque, por supuesto, eso no es todo. Este mes me he apuntado a un curso. Sí, a otro más. En esta ocasión a uno de Electrónica Digital⁶.
Como no podía ser de otra manera, también voy con retraso en este y es muy probable que tampoco lo termine a tiempo, razón por la cual empezaré a descargarme los vídeos para poder consultarlos una vez que el curso haya terminado, pero la noche es joven.

Quizás, sumando todo esto al libro “Fundamentos de Sistemas Digitales” de “Thomas L. Floyd” que comencé a leer en julio (y que me prestaron hace cosa de una década), consiga llegar en algún momento hasta algún lugar.

La cosa es que este reto termina la primera semana de enero y, una vez llegada esa fecha, debería centrarme en el curso de acceso a la uni para mayores de 25.

Otra cosa es que sea capaz de hacerlo y no amplíe aún más mis quehaceres diarios para terminar definitivamente con mi salud mental y física.

Enlaces:

1. El profe
- C++ : Compilar y enlazar librerías estáticas
- C++ : Introducción básica a constexpr y const
- C++ : new, delete, excepciones, std::terminate y RAII. Asegurando liberación de recursos
- C++ : Gestión de memoria con std::unique_ptr (Smart Pointers)
- C++ : Include guards, const member initializers, explicit constructors
- C++ : Render System (1): update básico
- C++ : Entity Manager (1): std::vector reserve
- C++ : Entity Manager (2): range-based for, std::fill y emplace_back
- C++ : Manager-Render: enlace por referencia, includes y forward declarations
- C++ : Render System (2) : fill, copy & iterators
- C++ : Depurando con cgdb: reserve vs resize
- C++ : Function objects, operator() y lambdas
- C++ : Interfaces, override, final, virtual, vtable
- C++ : Interfaces puras y destructores virtuales
- C++ : Leer ficheros rápido usando iteradores y contenedores
- C++ : Sprites con PicoPNG, iteradores y std::memcpy
- C++ : Sistemas Physics y Collision en Entity-Component-System

2. El C++ moderno
- Auto
- Fill
- Pragma

3. Michael Steil y el 6502
- 27c3: Reverse Engineering the MOS 6502 CPU
- 25c3: The Ultimate Commodore 64 Talk
- 33c3: The Ultimate Game Boy Talk

4. Juán González-Gómez (ObiJuan)
- Tutorial: Electrónica digital para makers con FPGAs
- FpgaWars
- Tutorial de Electrónica Digital con FPGAs libres
- IceStudio
- Icezum Alhambra
- ZX-UNO

5. Electrónica Digital
- Coursera – Sistemas-digitales
- Fundamentos de Sistemas Digitales

Javier Albizu Mié, 25/12/2019 - 20:11

Bajo un océano de bits, mes XXVI

Se acabó lo que se daba pero, cuando llegamos al ultimo “Bajo un océano de bits”, esto está muy lejos de terminar.

Los retos que empezaron hace dos años van terminando poco a poco y, para no faltar a la tradición, se van solapando a los que les tendrían que sustituir (aunque etos solapamientos no meterán ruido por aquí).

Esta entrada empieza con una mentira en su título, o al menos con una media verdad. Porque, en este mundo en el que vivimos, veintiséis meses no caben en dos años. A pesar de que esto, podría buscarme algún argumento al que agarrarme, porque esto ya dio sus primeros pasitos antes de su inicio oficial.

Mas no importa.
Muy bien, dirá nadie, ¿qué ha dado de sí este último tramo del recorrido?

No gran cosa, la verdad.
El reto finalizaba formalmente el día 5 de este mes, pero eso no ha evitado que continuase con las cosas que tengo a medias (y que otras se quedasen apalancadas).

Tras una larga búsqueda, logré encontrar algunos de los componentes que andaba buscando para modificar mi recreativa. El problema real no fue tanto el encontrarlos (que también), como el dar con alguien que no fuese Amazon o una tienda china donde comprarlos. Al final el ganador ha sido RS-Componentes¹ (que seguramente los encargará a china… pero mucho me temo que de ahí no hay manera de escapar cuando tratamos con cualquier tema de electrónica).
Ya que estábamos, también compré un nuevo Arduino para cuando me ponga a hacer cosas con electrónica...

… cosas como el tan ansiado programador de EPROMS².
En tiempos recientes, y tras conseguir el adaptador para chips de 42 pines, he tratado de hacer algo con el WILLEM… sin erótico resultado. He conseguido leer el contenido de las ROMS del Amiga… pero no tengo claro que la colocación en el zócalo sea la correcta (puedo desplazarlo un pin p’atrás o p’alante que el condenado lo lee… aunque el binario resultante es diferente)
Hasta que tueste esa información en una ROM no seré capaz de saber cuál de las posiciones es correcta. No lo sabré, claro está, hasta que no lo conecte, hasta que no encuentre un manual en el que me deje claro su uso, o hasta que no sea capaz de entender los esquemas de los chips, el WILLEM y sus añadidos.

Muchos puntos suspensivos en este párrafo. Demasiados.

Cosas que hemos comprobado que no van (al menos con lo que tengo ahora mismo):

Con el WILLEM y el adaptador no he podido grabar los chips MX29F1615.
No sé si será porque lo estoy alimentando a través del puerto USB y tiene poca potencia, porque me falta algún jumper por configurar, o porque realmente no se puede (lo más parecido a ese chip que aparece en el software nativo del programador es un MX29F1610… (sí, más puntos suspensivos) que tiene 44 pines… (y dale) pero que 42 de ellos coinciden con los del MX29F1615 y 40 de ellos con el AM27C400.
La cosa es que cuando he tratado de programar ese chip diciéndole que es cualquiera de esos dos modelos (MX29F1610 o AM27C400) el “pograma” me da errores diferentes. Errores que no están documentados en ningún lado (lo que incluye la red de redes)

Por lo que me pareció entender en el artículo que hablaba de un “Borrador UV casero”, si exponía una EPROM al sol durante el suficiente tiempo era posible que esta se borrase (But what counts is intensity× exposure time, says the datasheet). Así que, ni corto ni perezoso, hace unos meses puse el chip que me cargué castigado en el marco de la ventana con la esperanza de que, unos meses después, quedase como una tábula rasa. El experimento falló, pero no sé hasta qué punto es porque entendí mal ese punto, porque la luz no le ha dado en el ángulo correcto, o porque está realmente estropeado.
La cosa es que, cuando lo pincho en el WILLEM, este me dice que no está vacío, pero sí que me muestra que unas partes de él están borradas (valor FF).

Esta semana me tienen que llegar un par de leds UV de 3W con los que trataré de borrarlo de nuevo. También he pedido otro par de AM27C400 que tardarán un poco más en llegar. ¿Quién sabe?. Igual de aquí a un tiempo tengo ROMs con la última versión del Kickstart de Amiga de sobra... o más chips escacharrados.

A partir del curso de Sistemas digitales también me vi obligado a mirar un poco del álgebra de Boole³, un tema que parece que a la de mil igual termina de entrar (sobre todo la parte que corresponde a los XOR, NOR y compañía). A su vez, esto, junto a los vídeos del bueno de Ben Eater me han ayudado a pillar otras cosas.
Cosas como, por ejemplo, el funcionamiento de la memoria volátil. Porque sí, también me dio por mirar cómo funciona la memoria RAM⁴ y, oye, más o menos hasta me voy haciendo una idea del asunto. También he visto alguna que otra charla de hacking de consolas⁵ e incluso me parece haber entendido una parte nada despreciable de los conceptos de los que hablan.

Así pues, parece que todo lo previo sí que ha servido para algo.

A su vez, a día de hoy me manejo decentemente con git, entiendo los mensajes de error de un makefile, y, de vez en cuando, compilo desde sus fuentes cosas que antes sólo era capaz de instalar desde repositorios.
Estos días me ha dado por retomar el MAME⁶ y me lo he compilado a mano. Hasta entonces no me había dado cuenta de la mala bestia en la que se ha convertido este programa (más aún desde que lo juntaron con el MESS).
5,1 gigas de código que a un procesador Ryzen 3 2200G le costó cerca de tres horas compilar (y a un Athlon II X3 455 cerca de siete).

En lo tocante a la parte de software puro, más allá de darle a los vídeos de Fran Gallego⁷ durante este mes no he hecho mucho más.

Por su parte, dentro de los temas periféricos-que-antes-fueron-principales, esto es, la creación de vídeo-juegos y la animación⁷… pues tres cuartos de lo mismo. Un poco de GCD, un poco de Dan Root y un poco de New Frame Plus no hacen daño a nadie.

No hacen daño, claro está, salvo que a Dan Root se le ocurra hacer un vídeo hablando de los canales que sigue y te lleve hasta Game Makers Toolkit9.
Miedo me da ponerme con el resto de sus recomendaciones:

- CriticaLink
- Video Game Story Time
- Be Kind Rewind
- Strafefox

Para cerrar uno de los círculos que empezaba allá por los comienzos, parece que el tema de la accesibilidad se va moviendo poco a poco. Porque, más allá de los vídeos que le dedica Game Makers Toolkit, esta semana también han salido un par de cosas relacionadas (la primera de las cuales es amor puro)¹⁰

En fin. Para esto han dado los últimos dos años. Espero haber servido para que alguien abra los ojos a todas estas cosas que he descubierto y me han dejado con ganas de más. Espero no ser el único que ha sacado algo de este viaje narrado que continuará en modo silencio.

Enlaces:

1. Comprando componentes
- Conector RJ45 para rack
- Conector USB 3 para rack
- Arduino Mega Atmega

2. Anteriormente en… por aquí
- Nunca a la última 004
- Nunca a la última 009
- Bajo un océano de bits, mes XIX

3. Y un poco de electrónica teórica y práctica
- Álgebra de boole en UNOCOOS
- Connecting an LCD to our computer (Ben Eater)

4. Intentando entender la memoria (RAM)
- Random Access Memory using Logic Gates
- Flip-Flops and the Art of Computer Memory
- Memory and Programmable Logic

5. Hackeando consolas
- 27c3: Console Hacking 2010
- 33c3: Console Hacking 2016

6. MAME y MESS
- MAME
- MESS
- El repo

7. El profe
- C++ : Componentes ECS, Caché y Branch Prediction
- C++ : Por qué separar entidades en componentes en un #ECS
- C++ : Component Storage y Physics Component #ECS
- C++ : Sistemas #ECS de un único componente
- C++ : Formas de asociar entidades y componentes #ECS
- C++ : Referencias cruzadas y Template Types
- C++ : Identificadores automáticos y miembros static inline

8. Los de siempre

GDC
- The Art of Firewatch
- Environment Design as Spatial Cinematography: Theory and Practice
- The Banner Saga Franchise: Making Indie Sound AAA
- Crashlands: Design by Chaos

Dan Root
- How Trico Was Animated
- Are There Benefits to the Absence of Animation?
- The Five Fundamentals of Game Animation: An Introduction

New Frame Plus
- My Favorite Game Animation of 2019