.
La jam ya ha terminado, ahora ya tenéis en itch.io los participantes y podéis probar lo que ha subido cada uno. Durante esta semana les podéis votar y la semana que viene se repartirán los 2 premios
Para quien no haya estado siguiendo la jam, he hecho un video de presentación de mi juego. Es un juego arcade estilo Contra. Lo podéis bajar en itch.io o en la web.
Voy a estar unos cuantos días trabajando en reestructurar el código del emulador y la herramienta para editar controles. La idea es adaptarlos para compilar con CMake y, modificando un poco el script que ya me dio overflow, con esto se podrá conseguir por fin que el emulador sea multiplataforma y subirlo a un segundo repositorio (como dije habrá un repo para software de la propia consola, el que ya existe, y otro de software para ordenador que es el que se creará ahora).
Por otro lado, ahora que tengo más experiencia con la consola me estoy planteando la posibilidad de un cambio en su diseño para hacer que Vircon32 sea una máquina más equilibrada y funcional. De hacerse, los cambios serían estos:
- Reducir la RAM de 64 a 16 MB. La cantidad que hay ahora mismo es desproporcionada. No es necesaria para ningún tipo de juego que yo me imagine, y no concuerda para nada con la generación de 32 bits.
- Aumentar la capacidad de dibujo de la GPU. Su capacidad en "pixels dibujados" por frame se mantendría, pero simplemente reduciría las penalizaciones por dibujar regiones rotadas (50% -> 25%) y escaladas (25% -> 15%). Esto daría más margen si se quiere hacer juegos muy basados en pseudo-3D (pensad en algo tipo After Burner).
- Aumentar la frecuencia de la CPU de 9 a 12 MHz. Esto no me voy a atrever a decidirlo hasta que haya portado el emulador a Libretro para poder probarlo en una Raspberry y ver si podría con ello o no. En caso de no poder o ir muy justo se dejarían los 9 actuales.
Me gustaría recalcar que no me gustan los cambios de diseño. Otras consolas como la Pico-8 han ido actualizándose y sacando versiones nuevas, mi idea es que exista una sola versión, final, que se tome como un estándar y que sea compatible con todo lo que haya para siempre. Si me estoy planteando este cambio es porque todavía es bastante pronto, las especificaciones aún no están publicadas (es decir "estamos a tiempo") y además los cambios no van a hacer que deje de funcionar ningún software para la consola (como mucho reducir la RAM podría hacerlo pero ningún programa actual se acerca ni a usar 16 MB).
#365 los cambios de ram qué implican? Menor complejidad en código y/o consumo de recursos? O es un simple cambio por mantener la coherencia de la arquitectura que intenta simular?
no tengo un conocimiento como para poder decir si son buenos cambios, pero tus razonamientos son coherentes. quizas @r2d2rigo sea el que pueda aportar algo mas ya que estuvo jugando con los limites de la maquina 
en cualquier caso, agradezco tambien el Cmakeizarlo un monton!
He subido un video sobre los juegos de la jam. Si no habéis seguido ese hilo le podéis echar un ojo para ver cómo han sido los juegos:
#371 pense que ibas a salir hablando y comentando y me he quedado rallado al ver los subs y sin sonido xDDDD
#372 Ya, es que el canal pretende ser internacional. Al principio alguna vez sí que edité videos por duplicado (español e inglés), pero es demasiado curro...
7 días después
Ahora sí, ya está. Me ha costado más días de los que pensaba pero ya he creado el segundo repositorio que teníamos pendiente. Al final me he venido arriba y he subido no sólo el emulador con EditControls, sino ya también las herramientas de desarrollo (compilador de C, ensamblador, etc). Lo tenéis disponible aquí:
https://github.com/vircon32/ComputerSoftware
Gracias a @overflow he podido preparar los proyectos para compilar en multiplataforma usando CMake. Soy nuevo en ello (me he tenido que pelear bastante con CMake), así que puede que haya cometido alguna cagada, pero de momento puedo decir lo de "a mi me compila". En mi PC (Windows) compila, instala y se ejecuta todo sin problema. En teoría puede compilarse también bajo Linux o Mac, puede que funcione bien pero no está probado. En Windows no dispongo de Visual C++ (uso MSYS2+MinGW), con lo cual tampoco está probado con el compilador de Microsoft.
Además de lo que ya he dicho también he estado haciendo algunos arreglos más:
- He cambiado a linkado dinámico, ya que en CMake el estático da mucho por saco. Creo que así será bastante más portable y menos propenso a errores. Esto hace que en Windows crezca el número de DLLs que acaba habiendo en las carpetas de los programas (lo cual me fastidia), pero tampoco llega a ser algo excesivo.
- He reestructurado el código para separar mejor algunos fuentes que se reutilizan en varios programas.
- He arreglado algunos warning para que la compilación salga lo más limpia posible. Aún así quedan un par de ellos que no se van a poder evitar bajo C++11.
- Algunos programas todavía usaban TinyXML++, los he reescrito para usar TinyXML2 que es más portable.
Aparte, en la versión del emulador que he subido a GitHub, también he aplicado ya los cambios de diseño que comenté: se ha reducido el tamaño de RAM y Memory Card y se aumenta la capacidad de la GPU de dibujar con escalado y rotación. Como ya dijimos el aumento de velocidad de la CPU se queda en barbecho por ahora. Os recuerdo que estos cambios no os afectan en nada a vosotros: no tenéis que cambiar código de ningún programa, ni cambiar las roms que ya teníais.
Creo que esto es todo. Con esto, la consola empieza a ser multiplataforma y además estando todo en GitHub ya lo tenéis más accesible para que se vaya ampliando la comunidad 
#375 Gracias a ti por la ayuda! Siento no haberme podido poner con esto antes, son muchas cosas jeje
#377 ¿Qué es lo que te impide usar install?
Cuando tienes el emulador y EditControls instalados lo que te queda viene siendo esto:
Vircon32\
-> Emulator\
-> Bios\
-> Images\
-> (los 2 ejecutables)
-> (en Windows: las DLLs)
-> (los 2 XML de configuración)
-> GuiFont.ttf
-> ReadMe.txt
En cuanto a los threads de OpenAL no conozco esos errores (nunca me ha pasado). Pero parece que hay información online, por ejemplo aquí. De todas formas dicen que es solo un warning: el audio funciona, aunque puede afectar a la latencia
Ya, se podría hacer como dices, y que en la carpeta de build se copiara todo (en realidad la "instalación" es solo copiar archivos). La cosa es que en esa carpeta de build CMake te genera también mucha basurilla.
La verdad es que a mi tampoco me parece un buen sistema el que usa CMake, en el sentido de que tienes que elegir la carpeta de instalación desde antes de empezar, en lugar de hacer primero el build y luego poder elegirla o que directamente te lo preguntase en ese momento...
¡Sorpresa! Tenemos también un TERCER repositorio:
https://github.com/vircon32/Vircon32Documents
He subido aquí todos los documentos en PDF que hay publicados hasta ahora (especificaciones y guías). Al tenerlos en GitHub se pueden no solo descargar, sino que también deja leerlos online directamente cosa que en mi web no es posible. Además quedan todos bien organizados en un único lugar y quedará constancia de cuándo alguno de los documentos reciba cambios.
Ya he empezado a mirar el port del emulador a libretro, para Retroarch y RetroPie. Cuesta coger algunos conceptos (libretro necesitaría documentar mejor bastantes cosas), pero ya he hecho algún progreso inicial.
En cambio lo que parece que puede costar bastante más de lo que pensé es adaptar mi código de OpenGL (basado en la pipeline antigua), a OpenGL ES para que funcione en la Raspberry Pi. No me puedo creer que no haya una forma más directa de portar el código que el "ahora dedícate a aprender shaders desde el principio durante 20 horas"... 
¿Alguien conoce una manera mejor, o tiene algún consejo para eso?
#382 te escribo para agradecer las nuevas contribuciones, y decirte que ojala pudiera ayudarte con lo de OpenGL 
#383 Gracias hombre. He estado buscando también a ver si existe algo tipo "guía de opengl moderno para programadores del antiguo" pero no parece existir
#382 te echo una mano con el tema cuando quieras, he implementado un SpriteBatch en OpenGL como 4 veces ya.
De hecho tengo una en C, podria pasartela y que la adaptes a tu gusto.
EDIT: los recursos que mas te pueden ayudar con OpenGL moderno son https://learnopengl.com/ y https://open.gl/
#385 Gracias! Reconozco que me he tenido que buscar qué era eso del SpriteBatch.
En OpenGL ES creo que sabría dibujar un quad en pantalla, que es lo más básico para Vircon. La dificultad estaría más en la parte de implementar las modificaciones de color (lo que antes se hacía con glColor y glBlendFunc) y tal vez el uso de la textura ya que parece que no se hace como en la pipeline antigua. Aunque puede que también me encuentre problemas en otras partes. No tengo ni idea de shaders, así que no sé cómo de fácil o difícil puede ser hace esto.
#386 aqui tienes el shader que yo uso para dibujar sprites:
// Vertex shader
#version 100
#extension GL_EXT_separate_shader_objects : enable
layout(location = 0) attribute vec3 in_Position;
layout(location = 1) attribute vec4 in_Colour;
layout(location = 2) attribute vec2 in_TextureCoord;
uniform mat4 WorldViewProjectionMatrix;
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
void main()
{
vec4 objectSpacePos = vec4(in_Position.x, in_Position.y, in_Position.z, 1.0);
gl_Position = WorldViewProjectionMatrix * objectSpacePos;
v_vColour = in_Colour;
v_vTexcoord = in_TextureCoord;
}
// Fragment shader
#version 100
precision mediump float;
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform sampler2D BaseTexture;
void main()
{
gl_FragColor = texture2D(BaseTexture, v_vTexcoord) * v_vColour;
}
- El vertex buffer tiene un vector de 3 floats para la posicion, 4 unsigned bytes para el color y 2 floats para las coordenadas de textura por cada vertice.
- Solo soporta una textura que esta bindeada a GL_TEXTURE0.
- Recibe un unico uniform que es la matriz de transformacion de camara.
- glBlendFunc sigue funcionando como antes, no lo tienes que tener en cuenta en el shader.
#387 Gracias le echaré un ojo, de momento he visto la primera página y las explicaciones parece que pueden ser buenas
#388 Genial. Aún así esto me va a llevar tiempo. Hasta teniendo el código de ese shader, todavía no sé nada más. Ni cómo se usa, ni cómo integrarlo con las otras partes... supongo que me puede llevar 2 o 3 semanas empezar a hacer algo. Voy desde cero absoluto jeje
