Actualización de estado #9

Hoy miércoles 31 de marzo de 2019, he grabado la última demostración antes del lanzamiento.

Seré sincero, la beta pública no ha ido tan bien como esperaba. Solo he tenido un reporte, y pone en evidencia que no puedes confiar en el usuario final. A día de hoy la versión más reciente es la 5A, aunque ya estoy trabajando en una 5B para corregir los últimos errores que surjan. Porque de aquí pasaré a la release, la versión estable de la v1.0.

Esta actualización v1.0.5 ha incluido archivos hspp (HardScratch Packed Proyect), para exportar e importar proyectos. Es una forma de pasar código de ejemplo para que los nuevos usuarios exploren las posibilidades de HS desde el primer momento.

Los hspp no son más que una carpeta con el nombre del proyecto que contiene los archivos de tablero e implementación, comprimida en zip.

Dependiendo del nivel de aceptación que tenga esta última release, lanzaré OpenWound estable este domingo o mañana lunes.

En Github está disponible un manual en markdown y unas breves instrucciones de uso.

Resumen adicional:

Ahora que el desarrollo de HardScratch está llegando a su fin, me gustaría dar algunos datos completamente inútiles. Normalmente aquí se harían agradecimientos; que queréis que os diga, no tengo muchos amigos, esto va a ser breve.

• Gracias a Temis Simón, por escuchar las penurias por las que he pasado en este proyecto.
• Gracias a Almudena García, por las charlas de la ASL.
• Gracias a Gonzalo Muñoz, por presentarme la ASL.
• Gracias a las dos o tres personas que han probado la Beta.

Animes me han dado ganas de ver en este tiempo:

• To Aru Kagaku no Railgun: Se trata del anime genérico de estudiantes con superpoderes. Tras ver unos cuantos AMVs me llamó la atención el manejo poco convencional de los poderes, una vez vi el primer episodio, la historia de amor me atrapó.
  Este es un ejemplo de anime que va un poco más allá de lo obvio. El personaje que controla la electricidad no se limita a tirar rayos inexplicables. Sino que se explica que, al poder modificar a su gusto el campo eléctrico, es capaz de crear corrientes a su alrededor y esto también hace que pueda controlar el campo magnético. Es por esto que puede acelerar una moneda hasta los mil metros por segundo de velocidad inicial, convirtiéndola en un arma de riel, o caminar por las paredes metálicas.
  Su amiga, no se queda en teletransportarse; puede teletransportar objetos cercanos sin la necesidad de tocarlos. Puede usar este poder de forma inteligente para clavar objetos punzantes dónde ella quiera o derribar un edificio teletransportando el vidrio de las ventanas a las vigas, cortándolas sin ningún esfuerzo.
  A demás, las shipeo muchísimo.
• Charlotte: Un único AMV bastó para que lo viera enterito y debo decir que es tan malo como esperaba. Otro genérico de estudiantes con superpoderes, una trama como un colador y un argumento pésimo. Si eres capaz de olvidar estos defectos, el final te deja casi tan transpuesto como Gakkou Gurashi.
• Magic Kaito: Me gustó el traje y la estética, pero creo que nunca lo veré.
• Patema Inverted: Pinta bien. Otro AMV que me llamó la atención.

Canciones pop antiguas que más he escuchado (Nunca escucho pop, pero cuando lo hago, es de 2012):

• Train - Drive by
• Pitbull - Timber
• Clean Bandit - Rather Be
• Rise Against - Satellite 
• Fleur East - Sax
• Kongos - Come with Me Now
• Algunas menciones de honor: Daft Punk - Technologic, Chimo Bayo - xtA si xta no, Edwin Birdsong - Cola Bottle Baby, DJ Eliazar - Swing Those Blues Away, Taylor Swift - Shake It Off.

Actualización de estado #8

Hoy jueves 28 de marzo de 2019, me apetecía hablar sobre los progresos en estabilidad que he ido realizando a lo largo de la semana.

Habiendo sacado ya 4 actualizaciones tipo Hotfix, es probable que todavía hagan falta más correcciones. Creo que principalmente los errores que se detecten en la Beta serán por confiar demasiado en la capacidad de detección de fallos del programa. Por ejemplo, cargar una implementación vacía si el archivo aún no existe, error que ya está corregido.

Los cambios significativos de esta semana son:

Nuevo método de carga: ya no requiere un sobres fuerzo del ordenador en un solo tic, sino que la carga se distribuye en los tics que hagan falta; por lo que el tiempo de espera es proporcional a la magnitud del tablero y no satura el procesador.

Nuevo sistema de sonido: desde la primera versión del gestor de audio hasta la actual han pasado cinco iteraciones, cada una con sus problemas y sus soluciones. Primero creaba y abría un clip de audio con un stream de audio recién cargado del archivo, luego tuve un solo clip para todos los sonidos, después un clip precargado para cada sonido (ya que a veces tarda un poco en abrir el clip), ahora tengo un dataline por el que paso el stream de audio al mismo tiempo que se va leyendo (Apenas tiene latencia y no ocupa memoria innecesaria).  Todos estos métodos fueron probados tanto en el hilo principal, como creando un hilo para cada sonido en progreso.

Mejorada la estabilidad de simulación: antes la llamada a VMESS se realizaba en el hilo principal del programa, ahora se crea un hilo a parte que queda a la espera de VMESS y cuando termina vuelca sus datos en el hilo principal. También se ha mejorado la detección de errores esporádicos en la ejecución, mediante un limite de tiempo de respuesta. Modelo de COM Surrogate.

Nuevos sonidos: Efectos de sonido completamente originales, grabados en casa.

• SwitchUp: Activar conmutador.
• SwitchDown: Desactivar conmutador.
• ButtonUp: Presionar botón
• ButtonDown: Despresionar botón.
• KeyPress: Pulsar y soltar tecla.

El conmutador usado es muy parecido al que tienen los entrenadores electrónicos de la universidad. El botón lo saqué de una fuente de alimentación AT, tiene más de 20 años. La tecla es una CherryMX Blue.

Actualización de estado #7

Hoy viernes 22 de marzo de 2019, he librado una BETA del proyecto.

Durante esta semana he terminado de implementar la Interfaz, con los diseños ya publicados anteriormente. Entre las nuevas características destaca el multiproyecto; ya contaba con parte del código para ello, pero no había forma de darle uso a nivel usuario. Los ajustes permiten cambiar el tema claro u oscuro, la resolución y activar o desactivar la pantalla completa. De nuevo, ya estaba escrito,  pero no era accesible desde la interfaz.

Debo disculparme por una decisión muy mal tomada. Para corregir el posicionamiento fino de algunos elementos he creado una rutina de chequeo que no haría falta si el resto del código funcionase bien. Sumado a que, en proyectos grandes, los primeros tics después de la carga el programa apenas responde; he agregado una cortina de carga para la sección de diseño.
Esta cortina se ejecuta en el mismo hilo que la carga y el número de tics que dura es estático, por lo que es completamente inútil. Está ahí para que el usuario no se desespere si el programa no responde justo después de la carga. En mi defensa diré que es raro en mi publicar algo que no tenga ponis, y este era el sitio perfecto para ponerlos.

El otro gran pilar de esta semana ha sido el Error Handling, el como responde VMESS y HardScratch a los errores de GHDL. Los casos más frecuentes que se han ocurrido ya están cubiertos, pero nada pone más a prueba un programa que un usuario real. Es por esto que he decidido liberar una build semi completa de la cercana v1.0. El BETA TESTER Pack incluye un launcher que permite enviar reportes automáticamente con el log del programa.

Normalmente, en mis proyectos, no se suele alcanzar la 1.0; ya que esto supone admitir que el programa está completo y funcional, cosa que nunca logro. Esta vez daré el salto a la v1.0 directamente para poder satisfacer el grado de acabado mínimo del concurso. Es una mera cuestión de nombres.
Hablando de nombres. El mote de esta versión ha sido escogido por razones irónicas, las mejores razones. El nombre completo es HardScratch v1.0 OpenWound. Sé que Scratch obtiene su nombre de la expresión "from scratch" (desde cero), pero literalmente significaría rasguño. Es por esto que me resulta gracioso que la versión de un "Hard Scratch" (Rasguño Duro), se llame "Open Wound" (Herida Abierta). Primero por que un rasguño es una herida, segundo porque una herida abierta (pudiendo infectarse) es más seria que un rasguño de la misma forma que HardScratch es más serio que Scratch, tercero porque "Open" suele ser prefijo de muchos proyectos de código abierto, cuarto porque una herida abierta es propensa a llenarse de infecciones como un programa recién lanzado es proclive a estar lleno de errores, cuarto porque HardScratch ha comenzado a expandirse como una infección lo haría por el sistema circulatorio.

Puedes descargar HardScratch BETA TESTER Pack, desde aquí.

Actualización de estado #6

Hoy sábado 16 de marzo de 2019, he dejado funcionando la simulación. Nunca la expresión "dejar funcionando" se había usado de forma tan precisa.

Puedo afirmar que, para la combinación que tengo actualmente en el proyecto de prueba, la simulación funciona correctamente.

Paso a describir la estructura:

HardScratch (la interfaz): está escrita en Java. Hace uso de la librería LWJGL3. Sus componentes para el guardado son BUMLAY (codificador) y BUCKLE.

VME2: escrito en Autoit. Es un generador de código VHDL que recibe por entrada los archivos guardados de BUMLAY (decodificador).

VMESS: escrito en Autoit. Contiene a VME2. Es una herramienta para simular código generador por VME2 en tiempo real. Utiliza el programa GHDL para compilar VHDL a C y ejecutar la simulación.

VMESS: VHDL MADE EASY SIMULATED SIMULATION.

VHDL no puede ser ejecutado en un procesador, requiere de una FPGA para ser ejecutado de forma "nativa". Es por esto que se tiene que traducir a un código C equivalente. No obstante, las simulaciones se realizan simulando el comportamiento de una UUT (unidad bajo pruebas) mediante un archivo que reproduce estímulos secuenciales. Pero estos estímulos están fijos en el archivo de prueba y no pueden ser modificados en tiempo de ejecución.

VMESS simula ser una simulación mediante la conversión de sistemas secuenciales, a sistemas combinacionales más una memoria. Las entradas se introducen en cada ejecución, las señales se inicializan según el código original la primera vez, después se inicializarán al valor que tomaron al final de la ejecución anterior; para ello se añade una salida por cada señal.

VMESS recibe entradas y memoria, y envía salidas y memoria. El programa que usa VMESS debe almacenar esa memoria para realimentarla en cada ejecución.

He apodado este sistema VME Simulated Simulation porque explica perfectamente su función. A demás de llevar la palabra MESS, que también describe perfectamente el código.

Esta vez no hay demo, y no quiero hacer promesas, pero creo que en la siguiente actualización habré terminado el Error Handling y tendré listo un ejemplo interesante.

Actualización de estado #5

Hoy domingo 9 de marzo de 2019, tengo el honor de presentaros el peor sistema de guardado de todos los tiempos.

Yendo directo al grano, tengo la manía de no usar ningún lenguaje de etiquetas o estándar preestablecido cuando quiero guardar información en un fichero. En su lugar, tengo la mala costumbre de crear una nueva nomenclatura cada ocasión. Lo mismo con la comunicación cliente servidor, siempre me invento los protocolos.
Esta vez, y para que sea más sencillo de entender desde fuera, he creado dos estándares: BUMLAY y BUCKLE.
BUMLAY cuenta con dos divisores principales, uno de apertura y otro de cierre, a de más de un divisor extra. EJ: [data1|data2|data3][data1|data2] Permite recursión, EJ: [data1|[data1|data2]|data2] Lo utilizo para comunicar la interfaz grafica en Java con el backend en Autoit3.
BUCKLE tiene un divisor principal y uno secundario pero no permite recursión. EJ: data1|data2|data3{|}data1|data2 Lo utilizo para que la interfaz gráfica guarde el tablero y otros datos de configuración.

Este proceso de agregar funcionalidad a la fachada estética lo he apodado HardWork, en referencia al título del proyecto HardScratch.

Y esa es la gran adición de esta semana, el guardado y la carga. Tengo que decir que ha sido más sencillo de lo que pensaba en un principio. Claro, hubiera sido más fácil si simplemente hubiera usado una librería de Json o YAMAL para Java.

En la demo 4 se notan varios erres de solapamiento y de carga, aún estoy depurandolos; pero los más notorios ya están corregidos. El error de poder asignar un Tip a un Hole sin ser el que está seleccionado, que no tiene sentido porque el Finder muestra los elementos especificos para ese Hole, ha sido apodado cariñosamente "Asignación de rasquichuela sin mirar a lo Ronaldinho". Adjunto una imagen extra de como será la placa simulada.

Actualización de estado #4

Hoy domingo 3 de marzo de 2019, he regresado de un viaje al pueblo y traigo mejoras estéticas sustanciales.

Empezando por la incorporación de una interfaz que se asemeja en gran medida al diseño inicial. Cuenta con una barra suprior para cambiar de pestaña y dos botones para guardar y regresar al menú.

La barra desplegable se desliza siguiendo una regresión cuadrática, el típico efecto de desplazamiento suave.

He terminado de agregar todas las piezas que faltaban a excepción de el ForNext, que está todavía en el aire. A demás de ampliar las posibilidades de la clase padre Elemento para reducir el código en las Piezas, clases hijas; he mejorado la selección, creando una capa intermedia para que los piezas seleccionadas estén por encima de las demás y ahora se reordena la lista de elementos para que la última seleccionada se dibuje sobre las demás, pese a estar en la misma capa. Lo que me lleva al siguiente punto, una mejor redistribución de capas; ahora es el Hole, el que llama a dibujar al Tip, cuando la pieza lo necesita. Esto hace que el controlador se desentienda de los Tips una vez son asignados. Adjunto un diagrama que explica el modelo de capas.

Por otro lado he modificado el diseño de la página de configuración para que se pueda seleccionar la resolución, ya la ventana no será reescalable.

Adjunto una muestra de la paleta de colores que tienen actualmente las piezas. Está pendiente cambiar la paleta de la derecha, correspondiente al tema claro.

Las tareas pendientes por orden son: agregar la opción de guardado para la cual será necesario que el controlador pueda mapear las piezas y sus conexiones, agregar la opción de carga, agregar los diferentes menús y configuraciones.

Por última he grabado un vídeo mostrando el estado actual del proyecto.

Lista de resoluciones:

LIST OF RESOLUTIONS
   []  {}    ()
  4:3 16:10 16:9

{} 1024x640
[] 960x720
() 1280x720
[] 1024x768
() 1366x768
{} 1280x800
[] 1280x960
[] 1400x1050
{} 1680x1050
[] 1440x1080
() 1920x1080
[] 1920x1440
{} 2304x1440
() 2560x1440
() 3840x2160
() 7680x4320

Actualización de estado #3

Hoy domingo 24 de febrero de 2019, he grabado un vídeo para enseñar las adiciones que he ido haciendo al proyecto desde la semana pasada.

El termino definitivo para los elementos que representan bloques lógicos es "Pieza", el antiguo Elemento sigue haciendo de base pero ha sido adaptada a las mecánicas que faltaban en la primera demo.

A parte de los orgánulos básicos que tienen los elementos he creado el par Tip-Hole. (Referencia al par Electron-Hueco) Los tips son elementos especiales que comienzan siendo arrastrados y si se sueltan y no están conectados un hueco, se eliminan. La mayoría de huecos son estáticos, porque están hechos para una categoría especifica de Tips. Pero hay un componente recurrente que utiliza huecos dinámicamente.

Estoy hablando de el Constructor, usado para generar expresiones. Admite cualquier combinación de literales, variables, paréntesis, operadores lógicos y aritméticos. Sus huecos se adaptan al tamaño de la pieza, el constructor se adapta al tamaño de sus huecos y avisa a la pieza que lo contiene para que se actualice. Hay dos tipos de Hole en un Constructor; un hueco Daft y un hueco Punk, es broma se llama Linker. Los Linkers son operadores y los Daft son variables o literales. En general el usuario puede crear cualquier abominación, pero la secuencia Daft-Linker mantiene un poco de coherencia. Los paréntesis no encajan en ningún grupo, pueden ser colocados en cualquiera y no provocan alteración en la secuencia.

Para que los Tips encajen perfectamente se hace una aproximación fina hasta el centro del hueco. (La cual dio problemas por el tratamiento que tienen las posiciones en el código base)

Para conectar piezas se usa un mecanismo más avanzado de par Macho-Hembra. El puerto hembra, caracterizado por tener dos terminales a los extremos, tiene el trabajo de mover al macho. El puerto macho, con un terminal central, no se encarga de otra tarea más que realizar una aproximación fina hasta encajar perfectamente.

En realidad no hay piezas macho o hembra, sino que son los puertos los que tienen género. Una pieza puede estar conectada con un puerto macho, y tener a su vez otra pieza conectada por un puerto hembra.

Como resultado, si la hembra se mueve el macho le sigue; para desconectarlos hay que mover al macho.

El usuario arrastra las Piezas y Tips desde un generador ubicado en el lateral izquierdo. El Summoner tiene una forma y texto para identificar el elemento que generará cuando se pulsa en él. Existen colecciones de Summoners que aparecen dependido de el elemento seleccionado.

Adjunto una anécdota del problema que cariñosamente he apodado "Piezas gays"
Puestos a decir verdades; el nombre Tip no tiene nada que ver con lo que hace, se lo puse porque fue lo primero que se me vino a la cabeza al crear la clase. Lo mismo con Daft, le puse el nombre porque estaba escuchando Steam Machine.

He tenido que reconstruir todo el mecanismo de docking. Las cajas que se incrustan en los huecos (llamados Tip y Hole, respectivamente) tienen un mecanismo completamente diferente a las piezas grandes (Al final yamadas Pieces).

Al principio la conexión entre piezas era muy sencilla. Cuando terminas de arrastrar algo, el controlador miraba que puertos estaban en superposición y si coincidían en nombre (El puerto de uno tiene el mismo nombre que la otra pieza y vice versa) se lo decía a los objetos.

En la conexión hoy dos roles. La hembra (conexión con dos patillas) mueve consigo al macho, pero el macho puede moverse libremente. Si cuando el macho se mueve se aleja demasiado acaban desconectados.

Pero hay una pieza (el ExtraVar) que tiene un puerto macho que va al Declarator o a otro ExtraVar y un hembra al que se conecta otro ExtraVar. El problema es que la conexión solo se podía hacer si el puerto coincidía con la otra pieza. El ExtraVar solo podía conectarse a si mismo mediante Hembra-Hembra y os podéis imaginar como acaba eso.

He creado un objeto de tipo puerto que se configura como macho o hembra y que actúa de mediador entre las piezas. Ahora los puertos del ExtraVar son los dos del mismo tipo, pero uno macho y otro hembra.

Ahora está bien hecho.

Yo lo llamo "El error de las piezas gays"

Actualización de estado #2

Hoy jueves 21 de febrero de 2019, he terminado de dar forma a la interfaz. También he actualizado enormemente el código pero hablaré de ello en una actualización futura.

Tengo decidida la resolución, será cualquiera que el usuario le de. En un principio iba a limitarla desde 1280x720 o 1920x1080, pero he llegado a una forma de adaptar la interfaz a cualquier resolución. El límite inferior es 1280x800 y el superior viene dado por la potencia gráfica del equipo.

Las interfaces más agradables serán completamente relativas y se verán idénticas en cualquier resolución. Pero el resto de interfaces usan elementos de tamaños fijos, en el caso de los menús se crea espacio entre sus elementos para cubrir toda la ventana. De esta forma el espacio de trabajo es mayor conforme aumenta la resolución.

Por otro lado; en mi cabeza siempre he tenido un diseño oscuro (que está tanto de moda últimamente), no obstante un tema claro atraería más a un público joven, que es el objetivo. Por esto se van a incluir dos diseños.

Como se puede ver en los diseños que adjunto, se diferencian por los colores y algunas imágenes.

Actualización de estado #1

Hoy domingo 17 de febrero de 2019, he subido a github el código base en el que he estado trabajando este fin de semana.

La parte visual del proyecto está hecha con OpenGL en Java mediante la librería LWJGL.

Pese a haber tenido experiencia previa con LWJGL 2, he preferido usar la versión más reciente (3.2) y debo decir que no tiene nada que ver.

Pese a este contratiempo, he ido dando pinceladas durante la semana al motor base. Mi idea es crear una base (que no un framework, ahora esta de moda llamar framework a todo) para que el diseño de la interfaz sea lo más fácil posible, ya que sobre ella debe ir el funcionamiento final y no quiero tener que discutir sobre el sistema de coordenadas cuando ya haya pasado a implementar las últimas funciones del programa.

En rasgos generales cabe destacar que he intentado escribir todo el código en ingles; tengo la mala costumbre de mezclar idiomas todo el rato. lowerCammelCase para todas las variables excepto las constantes o variables globales importantes, esas en mayuscula y SNEAK_CASE.

Esta es la estructura que he seguido:

• Dot define un punto en el espacio 2D. (sirve para lidiar con el sistema de coordenadas de LWJGL)
• ElementBase es el padre de todos los objetos que tienen posición, es decir, de todos los elementos y orgánulos.
• Shape es la estructura básica de una forma. El resto de formas se crean a partir de estas, por ejemplo Shape_Square. Estos si son orgánulos.
• Texture es una textura, carga imágenes y contiene el ID de textura en OpenGL.
• Image es el orgánulo que dibuja una textura.
• Font es una colección de Texturas para dibujar texto.
• TextLabel es un orgánulo que dibuja texto.
• TextBox es un orgánulo que permite introducir texto, utiliza un TextLabel.
• Element es el que contiene los orgánulos. Se maneja con sus propiedades principales Drawable y Dragable, y la lista de orgánulos. Element es abstracto, los elementos reales implementan esta clase.
• Global contiene las constantes o variables globales a las que se accede en cualquier parte del código.
• Keyboard y Mouse son dos clases para leer las entradas.
• SoundPlayer es una clase para reproducir audio.
• Controller es proceso principal. Se le llama desde el ciclo de ejecución del hilo (creado en Display) y se controla el número de actualizaciones mediante SyncTimer. Controller maneja el dibujado, arrastrado y seleccionado de los elementos. (Estos dos últimos diferenciándose muy poco)

Adjunto un vídeo que muestra un elemento de prueba con las características que he introducido.

Entre semana intentaré publicar un esquema con los elementos reales de la interfaz y para el fin de semana que viene espero poder tener una demo con características más cercanas a la interfaz final.

Actualización de estado #0

Hoy lunes 11 de febrero de 2019, he creado este blog.

He usado blogger porque no se me ocurría otra forma más cutre y anticuada.

También adjunto un logo provisional a este proyecto.

No esperéis actualizaciones hasta dentro de unos días, aún me faltan algunos exámenes del cuatrimestre.

En las siguientes actualizaciones espero realizar una prueba de concepto del motor gráfico y, más adelante, publicaré esbozos e la interfaz hechos en papel.