Muchísimas gracias por tus palabras, @Lenko
. Me alegro muchísimo de que CPCtelera te esté siendo de ayuda. Perdona por tardar tanto en contestar, pero he estado un mes de viaje y tenía muchas cosas pendientes
El tema de las variables globales no tiene que ver específicamente con CPCtelera. Se trata de una característica del compilador SDCC. Este compilador está pensado para entornos embebidos. Básicamente, asume que el binario que genera se va a terminar implementando en una ROM. En una ROM los valores no pueden ser modificados (no se puede escribir). Esto genera un problema no con las variables globales, sino con los inicializadores de las variables globales. Si escribes una variable global con esté código:
El problema está en cómo se pone un 100 en la posición de memoria donde se almacena la variable puntos. Esa posición de memoria estará en RAM, pero el 100 debe estar en código del programa, es decir, en ROM. Eso significa que cuando ejecutes el programa desde ROM copiarás ese 100 desde la ROM a la RAM. Este comportamiento es necesario si trabajas en ROM, pero destructivo si tu programa funciona en RAM y se lee desde un dispositivo de almacenamiento (cinta o disco). Es destructivo porque generaría 2 copias de la variable puntos (una que es la que debería haber ido a ROM, que es como una constante con el valor 100, y otra que es la propia variable) y porque además debe añadir un cachito de código adicional para copiar los valores del "supuesto espacio ROM" (en nuestro caso está todo en RAM) a la ubicación de la variable en RAM.
En CPCtelera se configura SDCC para que no incluya el código que copia de ROM a RAM, ya que no lo necesitamos para nada. Nuestro programa funciona entero en RAM. Esto significa que si ponemos inicializadores para las variables globales (el = 100 de nuestro ejemplo) no van a funcionar. Además, no debemos hacerlo porque sí se van a generar 2 copias de la variable en memoria (la que debería ser ROM, y la variable propiamente dicha).
Por esto se recomienda utilizar una de 2 posibles opciones:
- Definir las variables como constantes globales y luego modificarlas a nuestro gusto, saltándonos los warnings del compilador. Al ser definidas como constantes, el compilador asume que pueden estar en ROM y no genera las 2 copias antes mencionadas, pero en nuestro caso práctico están en RAM, por lo que podemos modificarlas con un poco de maña.
- Utilizar algo de ensamblador (tampoco mucho) para definir los valores de la variable a mano. Es realmente mejor que la alternativa anterior, pero algo más engorroso en general. De todas formas, es cuestión de gustos.
En cuanto a los métodos de máscara, la máscara inline (incluida en el sprite) es ligeramente más rápida que el uso de tabla de máscara en general. Quizá en algunos casos no lo sea, pero puedes asumir tranquilamente que es más rápida en general. Eso sí, esta rapidez viene acompañada del coste de duplicar el tamaño de los sprites, que contienen su información de colores + máscara en lugar de colores sólo. A partir de ahí, es una cuestión personal de cada proyecto decidir cuál usar y porqué. Eso sí, ten en cuenta que si usas ambos métodos de forma simultanea, entonces también usaras el código de las dos funciones de dibujado con máscara. Esto son también más bytes en tu ejecutable. En la documentación de CPCtelera tienes los bytes que ocupa cada función, por lo que podrías calcular si te interesa o no.
Espero que esto te sea de ayuda