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