[Devlog] Vircon32: Creando mi propia consola

En breve tengo las game jams (la mía y la de MV), así que quiero estar lo más preparado posible para poder hacer diferentes tipos de juegos. Para eso ahora mismo Vircon32 tiene algunas carencias, porque no es como un Unity o Godot que te lo dan todo automático. Las cosas hay que hacerlas más desde cero. Y creo que algo que le falta hasta ahora es poder tener una pequeña librería o sistema para hacer físicas básicas.

Para eso he pensado que podría adaptar el código del Pinball Maker que ya hice, porque no usé ningún motor ni librería y la física funcionaba bien:

Adaptando el código a la consola ya tengo las formas más básicas para colisiones: rectángulos, círculos, cápsulas y arcos. Mezclando esto con un poco de física (rozamiento y rebote) y añadiendo gravedad, ya se puede hacer alguna cosa bastante potable:

Aunque el GIF pega algún tirón, en la consola se ve suave. Aún así sigue siendo un motor MUY básico, y no va a poder manejar formas complejas ni demasiados objetos, pero aún así puede abrir bastantes posibilidades. Ahora mismo solo lo estoy usando yo pero tras las jams cuando tenga más tiempo intentaré ya organizarlo un poco y subirlo con las demás librerías.

#700 es una pasada que los ojos siga la dirección de a donde va, son pequeños detalles.

#704 Vas a contar hasta más de 2147 millones??

He creado un pequeño update de las herramientas de desarrollo de Vircon (versión 23.10.27). Es poca cosa, si teníais ya algo en marcha para preparar la vircon jam no hace falta que lo actualicéis.

Las novedades son estas:

• Corrige un error en las directivas #error y #message.
  Seguramente no las usáis pero hay una de mis librerías recientes que la usa.

  ---

• Añade variables extern. Aunque no exista todavía linker, esto
  ayuda a organizar mejor los archivos separando headers e implementación

  ---

• Permite una coma final en los enum y las inicializaciones.
  Así me adapto a lo que permiten los compiladores normales de C.

#708 Errores de hardware personalizados no. Hay los típicos: dividir por cero, etc, que tú puedes causar a voluntad. Pero en principio no sirven para identificar errores a no ser que los "fabriques" para intentar por ejemplo saltar a una dirección de memoria concreta (que no exista) y ver eso en los datos del pantallazo azul.

Pero para identificar de dónde viene cada error, lo mejor sería que crees tu propio "pantallazo": escribes algo en la pantalla y terminas el programa (parando la CPU). Por ejemplo, esto te va a mostrar un pantallazo blanco con el mensaje que quieras:

void make_error( int* message )
{
    clear_screen( color_white );
    set_multiply_color( color_red );
    print_at( 20, 20, "PROGRAM ERROR" );
    set_multiply_color( color_black );
    print_at( 20, 50, message );
    exit();
}

Esto cuando lo ejecutes se verá así, y el programa se habrá detenido (en el emulador te dirá "CPU PARADA"):

PD: También puedes usar una variante de esto para hacer como si el programa tuviera "breakpoints": pones el mensaje y en vez de detener el programa esperas a que se pulse algún botón del mando y luego continúas. Así sabes por dónde está pasando tu programa.

#710 A ti! Además me has hecho pensar, tal vez podría haber alguna forma de implementar "breakpoints" sin tener que hacer un depurador. No daría la misma funcionalidad pero podrías llegar a tener el call stack en cada parada...

#712 Pues sí, la verdad. Pero hacer algo así me requeriría mucho tiempo, y la verdad no sé hasta dónde sabría llegar... pero bueno, vamos paso a paso. Poco a poco iremos mejorando cosas.

#716 ah que ya hay tema? Cuál es?

#716 cuántas librerías has hecho ya? Habrá que ir montando un gestor de dependencias no? ( ͡° ͜ʖ ͡°)