Un pequeño ejemplo de desarrollo en C para Spectrum

[mcleod_ideafix]

El C me resultaría extremadamente cómodo, se programar en ANSI C, pero no lo veo práctico para un ZX Spectrum en muchos casos y veo abstracto combinar dos lenguajes en un código (ASM y C), le quita flexibilidad y portabilidad al lenguaje C.

Hombre, pues precisamente lo veo lo suficientemente práctico como para que gente que quiere hacer programas para el IF2, a los que el ensamblador se le atraganta por lo abstracto o por lo diferente que es del BASIC, se anime y presente cosas al concurso. El C, quieras que no, con su FOR, su GOTO, su IF, sus asignaciones, etc. está un poco más cerca del BASIC que del ensamblador. Esta es de hecho la motivación principal de escribir este post.

Por otra parte, no sólo de juegos vive el Spectrum (la inmensa mayoría de cosas que he escrito para el Spectrum son utilidades, no juegos), y para todas esas cosas el C es muy válido como lenguaje de programación.

Si hay a quien no le duelen prendas al escribir un programa en BASIC pensando en poder compilarlo con tal o cual utilidad, ¿por qué no usar un lenguaje pensado desde el principio para ser compilado y dar un código compacto? Los compiladores de C para dispositivos empotrados, a poco que se les ayude un poco, pueden generar un código bastante decente para el espacio que se dispone. Y para los casos en los que la velocidad o el control es primordial, recurre al ensamblador en línea. ¿La portabilidad? #ifdef y #endif son tus amigas. Utilidades como AMP (creo que la primera implementación libre de un reproductor MP3 para Unix) hacen uso del ensamblador en línea para acelerar los cálculos si detectan que la plataforma para la que se compila es x86 o Sparc (en ambos casos usan el juego de instrucciones SIMD de cada arquitectura). Hace muchos años ya se escribía de esta forma (compilación condicional, según la plataforma, por ejemplo) usando sistemas de desarrollo "profesional" para el Spectrum como el PDS.

[Benway]

veo abstracto combinar dos lenguajes en un código (ASM y C), le quita flexibilidad y portabilidad al lenguaje C.

No tanto. Fíjate que BeTiled comparte un montón de código entre las versiones de Spectrum y MSX. Un Z80 es un Z80

Vamos, utopian lo podría decir mejor que yo, pero, a parte de la biblioteca gráfica, el código es prácticamente idéntico, salvando algunos detalles específicos del spectrum: Uso de atributos y demás... Eso nos ha permitido tenerlo en un tiempo récord, a pesar de haber tenido que hacer la biblioteca (mérito de Utopian, que nos permitirá portar los juegos más fácilmente a partir de ahora).

En este caso, del BeTiled!, para la versión CPC estamos reprogramándolo en ensamblador, y fijaos que, aunque empezamos antes que la versión MSX, todavía no está terminada.

Y, a parte, suscribo al 100% el comentario de McLeod_Ideafix.

Con respecto al "resultado" al ver el código, en un juego como BeTiled!, la mezcla ASM - C hace que pueda resultar un poco "confuso", si no lo comentas bien. Y luego, hay cosas relacionadas con el compilador en sí (en este caso, z88dk), que hacen que te tengas que alejar de los "cánones clásicos" de programación: Abusando tremendamente de variables globales, en detrimento de las locales, sobre todo para ahorrar espacio.

En BeTiled!, en concreto, al querer que funcionase en 48k, tiene todos los bitmaps metidos en la RAM principal (lo único que está "paginado" es la música, los fx y el player), así que anduve extremadamente corto de espacio al final, así que tuve que tirar de variables globales, e incluso implementar ciertos bucles en ASM en lugar de en C para ahorrar algunos bytes (a veces 8 bytes, y en otras ocasiones hasta casi 100).

Al final, el código puede resultar un poco "revoltijo", aunque me esforcé en dejarlo claro con comentarios y con el mapa de memoria, pero ahora me resulta "fácil" programar así, mezclando ASM y C... de hecho, en mi opinión personal, es la "mejor" (o más cómoda) manera de hacerlo para juegos sin scroll... aunque, curiosamente, el proyecto que tengo casi terminado (el iLogicAll, del que ya he hablado aquí alguna vez), lo estoy haciendo sólo en ASM, a pesar de no tener scroll ni florituras gráficas

[na_th_an]

programar así, mezclando ASM y C [...] es la "mejor" (o más cómoda) manera de hacerlo para juegos sin scroll.

101% de acuerdo

[utopian]

veo abstracto combinar dos lenguajes en un código (ASM y C), le quita flexibilidad y portabilidad al lenguaje C.

No tanto. Fíjate que BeTiled comparte un montón de código entre las versiones de Spectrum y MSX. Un Z80 es un Z80

Vamos, utopian lo podría decir mejor que yo, pero, a parte de la biblioteca gráfica, el código es prácticamente idéntico, salvando algunos detalles específicos del spectrum: Uso de atributos y demás... Eso nos ha permitido tenerlo en un tiempo récord, a pesar de haber tenido que hacer la biblioteca (mérito de Utopian, que nos permitirá portar los juegos más fácilmente a partir de ahora).

Sip, básicamente el código es el mismo, y toda la lógica del juego es igual, lo cual me ha permitido portarlo sin tener que entender parte del código . Aparte de ser el mismo z80, ayuda el que la resolución de pantalla en modo SCREEN 2 sea la misma del Spectrum, que tengan el mismo AY...

[Gandulf]

Pero de todas formas eso que decíis es válido tb si fuera hecho en ASM la versión speccy. Sólo habría que cambiar rutinas concretas, nada que afecte a la lógica y control del juego. El código ASM es el mismo, sólo hay que variar las rutinas gráficas y un par de cosillas más, pero muy concretas. En la época dorada se hacían conversiones a toda pastilla y no existían compiladores de C.

De todas formas coincido con vosotros en que si el juego no tiene scroll o un cálculo gráfico intensivo lo más cómodo es hacerlo en C (para el que le guste), pero más que por la portabilidad, que en máquinas con Z80 es prácticamente igual este tema, por que no tienes que escribir tanto código (y no hablemos si usas splib).

[na_th_an]

En C se pueden pasar luego a PC y otras máquinas en un plis también.

[utopian]

En C se pueden pasar luego a PC y otras máquinas en un plis también.

Y a Commodore 64: http://www.cc65.org/

[Gandulf]

Ya hombre, estoy hablando de conversiones comunes entre ordenadores con Z80 como en la época dorada. No estaba intentando defender la portabilidad del ensamblador , no tendría sentido. Me refiero al ejemplo que pusisteis de conversión a MSX.

En cuanto a la versión de commodore, creo que es un ordenador tan distinto que la conversión se complicaría mucho. Ya no serían sólo las rutinas gráficas o de sonido, sino creo que la forma de estructurar todo, por las características especiales de este ordenador (procesador lento pero chips dedicados).