[Devlog] Vircon32: Creando mi propia consola

#302 Sí, aunque por mucho que se optimize no creo que se llegue a hacer más que algo tipo StarFox (el de SNES). Hay otras técnicas que se adaptan mejor a esta consola pero ya las cubriré en su momento.

#304 Pues te contesto por partes. Sí, va a haber una documentación completa del chip de video y de los demás. Pero aún no la he escrito. Tengo muchas cosas entre manos, a ver si llego a ello! Pero sí, cada sistema de la consola está modelado como su propio chip. Aunque no llegan a un nivel tan bajo como la CPU. El chip gráfico por ejemplo, está pensado para que se implemente con librerías modernas tipo OpenGL/DirectX/Vulkan pero de forma muy simple y dando bastante libertad de cómo hacerlo. Por eso se limita a operaciones muy básicas como dibujar imágenes y no baja al nivel de cómo se debe manejar cada pixel, cómo se debe implementar el buffer de pantalla, o cuál debe ser el timing para las operaciones de dibujo. Si exigiera en cambio poder tener acceso directo a la memoria de video, estas cosas sí deberían tenerse en cuenta y la consola se volvería más compleja.

En cuanto a la velocidad de CPU, hay 2 motivos para que esté limitada. El principal es rendimiento. Mi equipo es potente (Core i7, 16GB RAM, etc) y el límite que pude alcanzar en mis pruebas fue de unos 43.5 MHz. Si se quiere poder ejecutar Vircon en Raspberrys o móviles ese rendimiento hay que bajarlo bastante más. De todas formas, a diferencia de otras CPUs, en Vircon cualquier instrucción se realiza en ún único ciclo (incluso las operaciones trigonométricas o los accesos a memoria), con lo cual hay más potencia de lo que puede parecer.

El otro motivo es que Vircon32 pretende ser una consola orientada al 2D. Se van a poder hacer juegos completos con técnicas pseudo-3D (por ejemplo Raycasting u scaling) pero esta consola tampoco pretende enfocarse en ello. Para hacer experimentos de este tipo ya existen sistemas como Pico8 y TIC80, y Vircon aunque lo permite está más enfocada en ser muy accesible (es decir, lo más simple posible) y dar buen soporte a juegos. Por eso características como los 4 pads, 7 botones, memory card, etc.

#306 A ver si te sé responder. Digamos que en términos de video y audio, Vircon32 sigue un modelo de alto nivel, donde los conceptos que se manejan son texturas, regiones, operaciones... en lugar de definir todo a un nivel muy bajo y trabajar directamente con pixels, colores, memoria, etc. Al trabajar a un nivel más alto no se necesita definir ni aprender tantos elementos ni tantos procesos. Es una manera de simplificar, pero aún así permite tener los gráficos y sonidos que los juegos necesiten. Si usáramos un modelo de más bajo nivel habría más flexibilidad a la hora de usar todo tipo de efectos y hacks, pero eso tiene un costo que puede ser elevado. Para mi como creador del proyecto, para quien quiera aprender a hacer juegos y para quien pueda estar interesado en crear sus propios emuladores o herramientas.

Lo que comentas sobre shaders no lo he entendido del todo. En los gráficos de Vircon32 no hay ningún tipo de shader. De hecho ni siquiera mi emulador implementa nada usando shaders: lo hace todo con la pipeline antigua de OpenGL, porque para esto no son necesarios. Además centrarse en APIs más antiguas también garantiza que incluso en equipos más viejos o en sistemas embebidos se podría usar algo tipo OpenGL ES para implementarlo. Aunque también hay la opción de usar shaders si se prefiere, claro.

Nueva versión del compilador de C

Ahora sí. Ya lo he subido a la web junto con su código fuente.
También están actualizadas las guías del compilador, en español y en inglés.

Hay varias novedades importantes:

• Ya se pueden usar enumerados
  Muy útil, ya que no hay implementadas constantes. Además es una manera más fácil de definir las texturas y sonidos del juego, que siempre tienen IDs consecutivas, en vez de hacer 20 #defines.
• He añadido switch, case y default
  Antes la selección de escenas o máquinas de estados las hacía encadenando if-else, porque no había otra cosa. Ahora quedará mejor.
• También he puesto etiquetas y goto
  En teoría no se deberían usar pero ya que C los soporta, pues por si acaso. Podría haber situaciones en las que simplifique el flujo.
• Las estructuras y arrays ya se pueden inicializar con listas
  Ya podemos declarar los típicos arrays: int[ 3 ] Array = { 1, 2, 3 }; También viene bien para estructuras o datos compuestos como vectores. Esto va a ahorrar muchas líneas de código.
• Las estructuras y uniones se pueden autoreferenciar
  Ahora se podría hacer la típica estructura de nodo para una lista, que contiene un puntero al nodo siguiente. Aún así recordad que no tenemos por ahora funciones de memoria dinámica (malloc/free).
• He actualizado los includes
  No es la gran cosa pero he incluido un par de funciones nuevas: en video para extraer las componentes R/G/B/A de un color, y en audio para poder manejar el volumen global (y no canal por canal), que es algo que se me había quedado en el tintero hasta ahora.

Bufff. Me voy a ir a tomarme un descanso por hoy

#318 Sí, no sería muy difícil. De hecho herramientas de este tipo las podría crear cualquiera (no solo yo). Lo que no sé es si merecería la pena, al fin y al cabo no te va a ahorrar más que unos pocos segundos a no ser que tengas una gran cantidad de texturas o sonidos. Otra cosa es que ya nos metiéramos a generar más cosas, como por ejemplo el script make o alguna otra, a lo mejor entonces le vería más utilidad. Pero vamos todo sería verlo