Dozznar es uno de los programadores mas prolíficos que tenemos y que en los últimos años se ha ido labrando el respeto de la comunidad commodorera gracias a sus aportes. Ya le tuvimos AQUÍ presentándonos sus anteriores trabajos y en esta ocasión nos hablará de su experiencia con el Oscar64, sus ventajas, importancia, facilidad de uso y el porqué, si comenzáis con la programación, es una buena opción.
–Os dejamos con Dozznar:
–Siempre he tenido la sensación de no saber informática de verdad. Aunque me dedico profesionalmente a ello, las capas de abstracción de los sistemas modernos y el hecho de no dedicarme al desarrollo han contribuido a alimentar esta percepción.
Eso, unido a mi interés por el videojuego retro, despertaron en mi una inquietud: la de intentar realizar un videojuego para alguno de los sistemas que me acompañaron en mi infancia.
De entre todos aquellos sistemas, había uno que me llamaba especialmente la atención, era el Commodore 64. Inicialmente, comencé a escudriñar documentación sobre el código máquina de su CPU. Aunque me sorprendió la sencillez de su arquitectura comparada con la del procesador Z80, no me veía capaz de afrontar un proyecto de videojuego en ensamblador.
En ese momento comencé una búsqueda de algún tipo de atajo mientras aprendía ASM. Algún lenguaje de más alto nivel que estuviera soportado por el 6502 pero que tuviera un rendimiento aceptable, hablando siempre de compiladores cruzados. La verdad es que no encontré un especial interés en la comunidad por un producto de estas características, más allá de un compilador de Basic en el CBM Prg Studio. Lo que más se parecía a lo que buscaba, era un compilador de C llamado cc65, que no me daba buenas sensaciones debido a que no estaba mantenido desde el año 2013.
En todo caso, me decidí a probarlo y desempolvé mi memoria para recordar como se programaba en C. Durante mis estudios, un grado superior de informática de gestión (FPII), había programado en varios lenguajes. BASIC para un sistema operativo llamado Theos. COBOL, Clipper y Turbo Pascal para MS-DOS y C para sistemas UNIX.
La anécdota fue que al principio de curso en 4º, había una especie de cribado para dividir al alumnado en dos materias:
- Sistemas AS400 y lenguaje RPG (En Navarra había bastantes salidas profesionales con estos sistemas en aquel entonces)
- Sistemas Unix y lenguaje C. En el Instituto teníamos una red en Xenix, Una versión de Microsoft de Unix que no tuvo mucho éxito.
En fin, que a los alumnos no se nos dio opción de elegir. Cada uno, por sorteo, cayó en una de las dos materias. Tuve la "suerte" de caer en Unix y C.
El caso es que por casualidades de la vida, mi carrera profesional derivó hacia el área de sistemas, en la que sigo trabajando como administrador en un operador logístico. Mi desconexión con la programación era total.
Me puse manos a la obra y tras los clásicos "Hola mundo", pruebas con punteros y una exhaustiva lectura del "manual de referencia del programador", libro del cual aconsejo su lectura ya que explica a conciencia y bastante claramente los conceptos necesarios para comprender el Commodore 64, comencé a coger soltura y realicé un par de mini-juegos, Bombrun64 y Fart Escape.
Gracias a la pandemia, pude seguir con un poco más de dedicación con esta afición y fruto de ella surgió "Juanje juega in Sinverland" y posteriormente Randoom y Randoom para Commodore PET. Mi sensación con este compilador era que funcionaba bastante bien siempre que no le pidieras excesivo rendimiento y no le vi bugs o problemas que me impidieran desarrollar mis proyectos. Pero entonces fue cuando alguien, creo que Josepzin, pasó el enlace al grupo de Telegram al Github de un compilador llamado Oscar64 de un tal Drmortalwombat.
Empieza lo bueno.
En un principio, y dado que ya me encontraba cómodo con cc65 fui un poco "perezoso" para probar el producto. Pero en cuanto ejecuté las demos que traía y leí la documentación, se me empezaron a abrir los ojos. Poco a poco iba descubriendo las "mieles" de este fantástico compilador que me iba atrapando por su rendimiento y su gran cantidad de funciones añadidas.
El trabajo de realizar juegos no solo era mucho más sencillo, si no que tenían una optimización muy superior. Tanto es así, que he llegado a definirlo como "maker de videojuegos". Si se revisa el código intermedio ASM que produce al compilar, veremos que es infinitamente más legible y con mucho menos "overhead" que el cc65.
De entre las cosas que más me han ayudado a simplificar mi proceso de creación destacaría:
- La facilidad para embeber datos externos (gráficos, sprites, músicas) incluso comprimiéndolas con LZO con un sencillo parámetro:
De un solo fichero puedo embeber varias partes definiendo el área de bytes que quiero recopilar y almacenarlo comprimido en un vector.
char SprIngameData[] = { #embed 5120 0 lzo "../resources/Sprites/Sprites.bin" }; char SprMenuData[] = { #embed 2160 5120 lzo "../resources/Sprites/Sprites.bin" };
- La facilidad para crear formato CRT con perfecta y cómoda gestión de los bancos en ROM:
//Section and region for easyflash bank1 #pragma section( bcode1, 0 ) #pragma section( bdata1, 0 ) #pragma region(bank1, 0x8000, 0xc000, , 1, { bcode1,bdata1 } ) //Section and region for easyflash bank2 #pragma section( bdata2, 0 ) #pragma region(bank2, 0x8000, 0xc000, , 2, { bdata2 } ) //Section and region for easyflash bank3 #pragma section( bdata3, 0 ) #pragma region(bank3, 0x8000, 0xc000, , 3, { bdata3 } )
Se definen regiones y secciones donde alojar nuestro código en los diferentes bancos del cartucho. Posteriormente podremos acceder a los datos o código de cada banco con un sencillo comando:
eflash.bank=<NUMERO DE BANCO>
Posteriormente al compilador le especificamos un parámetro para que cree un fichero con formato ".CRT":
oscar64.exe mygame.c -n -v -tf=crt
Y también:
- Multitud de funciones integradas enfocadas en la creación de videojuegos
- Funciones para crear sonidos FX
- Funciones de gestión de sprites
- Funciones para multiplexar sprites
- Funciones para mover sprites sin preocuparte por el MSB en la coordenada X
- Funciones para gráficos vectoriales muy optimizadas (nunca pensé que se pudiera hacer algo así en C en un C64)
- Funciones para el manejo de IRQ
- Funciones para poner textos en modos Bitmap
- Ficheros de apoyo para el Debug (".lbl",".map",".asm") muy útiles para no perderte en ningún momento
Y por supuesto una comunidad viva en Github que puede interactuar con DrMortalWombat y aportar al proyecto. Él está siempre muy activo respondiendo cualquier duda que surja.
En definitiva un gran producto en las mejores manos con el que ya he disfrutado desarrollando el "Valkyr" y viene en camino el "Randoom2, Ancient Stones" que espero vea la luz en breve.
Para terminar, quiero agradecer a DrMortalWombat el "currazo" que se ha pegado para hacer este compilador (y el que se sigue pegando para mejorarlo). También el hecho de que lo use para sus propios videojuegos y además publique el código fuente que es de gran ayuda para gente quiera aprender a usarlo.
https://github.com/drmortalwombat
Sin más, os animo a que lo probéis. Quizás la mejor manera de "engancharse" con él sería intentando primero compilar los ejemplos que trae y luego modificarlos para ver el resultado que producen los cambios.
1 Comentarios
Buen artículo señores, como siempre.
ResponderEliminar