Fourspriter 2.0

[na_th_an]

Biblioteca Fourspriter 2.0. Incluye manual y ejemplo sencillo. Edición especial "última hora" para el concurso de BASIC de Radastan de 2010. Emplea este hilo si quieres preguntar algo o te salen dudas. Te responderemos rápidamente que "la más tetuda".

Fourspriter 2.0 es una biblioteca sencilla para manejar hasta 4 sprites de 16x16 píxels con movimiento a nivel de carácter. Concebida en un principio para ser enpleada directamente desde BASIC, también puede emplearse sin problemas con BASIC compilado (mediante compiladores nativos como HiSoft BASIC o cruzados como ZXBasic), C o ASM. La biblioteca se encarga de actualizar las posiciones de los sprites y de restaurar cualquier fondo que hubiera bajo ellos, de forma que puedes usar lo que quieras como fondo.

Para que te hagas una idea de las capacidades de la biblioteca, el juego クラシック 日本語 モンスター 城 3 fue creado en Sinclair BASIC, compilado con HiSoft BASIC, y emplea la versión 1.0 de Fourspriter.



Fourspriter 2.0 es una extensión en asm permitida en la categoría BASIC extendido del concurso de BASIC de Radastan de 2010. Según sus reglas, un juego como クラシック 日本語 モンスター 城 3 (construido con HiSoft BASIC y Fourspriter) podría entrar a concurso.

¡Manos a la obra!

Descarga:

[boriel]

Precisamente quería contactar con The MojonTwins pero no vi el form de contacto en el blog. Aunque he estado "un poco" (uff) liado, he vuelto, digamos, con el ZX Basic. El caso es que me gustaría incluir las librerías de MojonTwins de forma oficial.

Es cierto que a la gente le gusta incluir sus propias librerías y modificarlas otras (por ej. las de foursprite, etc). Pero no puedo incluirlas todas, especialmente si son de propósito muy específico: por ejemplo, no tiene sentido incluir en el compilador una librería de gráficos para UN juego dado, etc...

Las librerías de MJ me gustan mucho, me parecen genéricas, y me da que están bastante probadas... ejem...
En cualquier caso, dado que todos hacemos esto por la escena, y no ganamos un duro (al menos por ahora), me gustaría al menos preservar el nombre.

La idea es la siguiente: las librerías de MojonTwins estarían distribuidas con el compilador, en su propio directorio, /mt/ por ejemplo. Y sólo ahí habrá código que será solo de MT. Y para usarlo habría que hacer:
$this->bbcode_second_pass_code('', '
#include <mt/fourspriter2.bas>
')
por ejemplo. Si alguien quiere hacerse "otra versión", variación, mutación o recombinación nucleica, perfecto, pero ya no irá en ese directorio. Y así distinguimos qué código es de MT del resto.
Ya me dirán si les parece bien.

Otra cosa, sé que integrar código asm con el compilador, etc... es un poco coñazo, porque no he puesto por falta de tiempo documentación interna sobre el compilador. Pero me comprometo a echar una mano (aquí, en castellano) en lo que haga falta.

Ya me dicen si les interesa. Igual no..

[na_th_an]

Buenas.

Pues sí, me parece perfecto La versión 2.1 que hay puesta ahí arriba adaptada para ZX Basic funciona bastante bien. De hecho, está empleada en dos juegos que a ver si todo va bien y podemos terminar para el concurso de Bytemaniacos de este año. Tiene los problemas que todos conocemos (el último de los 4 sprites parpadea un poco en las primeras 4-5 lineas de caracteres de pantalla), pero es fácil de usar y fácil de mejorar. Es todo un honor que nuestra colección de rutinas forme parte de la distribución oficial del compilador

Sobre la interfaz BASIC/asm creo que lo único que haría falta sería una forma alternativa a POKE/PEEK para "ver" las variables de la zona de ensamblador desde BASIC, aunque tampoco supone un gran problema. Otra cosa que estaría bien sería que nos documentases sobre cómo reciben las funciones los parámetros, para saber cómo poder leerlos desde un trozo de código ensamblador situado justo debajo del SUB... o del FUNCTION... .

Y poco más. ¡Gracias de nuevo!

[radastan]

De aquí puede salir algo grande, me parece perfecto unir las dos herramientas más majas para los programadores noveles.

[boriel]

¿Tenéis algún minicódigo para probar el fourspriter?
Voy a hacer algunas modificaciones para que vaya un poco más rápido con el compilador. También quería proponer las siguientes mejoras, pero claro, necesito probarlo.

También quisiera hacer unas propuestas de mejora, a ver que os parece. Pero para no liarnos con el código, por qué no se bajan el repositorio del compilador? si no es molestia...
Asi iremos controlando las versiones.

Para bajárselo, si tienen linux, solo hay que instalar subversion y escribir en una consola:
$this->bbcode_second_pass_code('', '
svn co https://boriel.homeip.net/svn/zxbasic zxbasic
')Si es en Windows, lo mejor es utilizar el tortoiseSVN, instalarlo, y hacer un checkout de https://boriel.homeip.net/svn/zxbasic

Alguna mejora simple es (que ya la estoy haciendo):
1.- Tienes alguna instrucción cp 0 por ahí. Pasarlo a or a (o and a). Eso es trivial, asi que nada.
2.- Hacer locales todas las etiquetas posibles. Esto si es una currada y los estoy haciendo ya. Me explico:
en ASM todo es global y hay un único espacio de nombres (por ahora). Eso significa que si declaras una label xpos que es muy común, y la declara también cualquier otra librería o subrutina, te dará un error el ensamblador, porque estará duplicada. El truco es declararla local, dentro de un PROCedimiento. Esto también lo tiene Pasmo, por lo que sé. Y es así:
$this->bbcode_second_pass_code('', '
PROC ;; Declara que comienza mi subrutina

LOCAL xpos ;; Declara que esta etiqueta sólo es visible dentro de esta subrutina
xpos:
...
bla bla bla
...

ENDP ;; Cierra la subrutina (el bloque de código)
;; En este punto xpos ya no será visible
')
El trabajo es que hay que declarar LOCAL para todas las etiquetas posibles. y son un montón. También creo que es mejor usar el prefijo MJ (Mojon Twins) en lugar de fsp21, y sustituir tabuladores por 4 espacios (rollos de que luego se vea bonito en la salida del compilador con --asm). Total... que todo es lo estoy subiendo al repositorio. ¿Qué les parece?

Luego hay 2 mejoras de optimización que creo que se podrían poner, pero lo comentamos en otro post para que este no sea muy largo.

[boriel]

Aquí tienen la sugerencia de mejora #1:

El siguiente código copia el bitmap de pantalla a DE
$this->bbcode_second_pass_code('', '
call getscraddr ; HL = Dirección en el bitamp de XPOS,YPOS

; Lo siguiente de repite 8 veces
ld a, (hl)
ld (de), a
inc h
inc de
...
')
Y esto de arriba, además, se repite x 4 (una por cada carácter del sprite). Evidentemente, se hace por rendimiento (bucle desenrollado, creo que se llama). Pero dado que siempre se llama a getscraddr, siempre hay un CALL implicado. Mi idea es sustituir la llamada a la subrutina getscraddr por otra que calcule la dirección del carácter y realice el código de copiado. De esa manera, el código quedaría:
$this->bbcode_second_pass_code('', '
scr2buf: call char2buf ; HL = Dirección en el bitamp de XPOS,YPOS

; xpos++
ld hl, xpos
inc (hl)

;; Segundo char
call char2buf ; HL = Dirección en el bitamp de XPOS,YPOS

; xpos--
ld hl, xpos
dec (hl)

; ypos++
inc hl
inc (hl)

;; Tercer char
call char2buf ; HL = Dirección en el bitamp de XPOS,YPOS

; xpos++
ld hl, xpos
inc (hl)

;; Cuarto char
jp char2buf ; HL = Dirección en el bitamp de XPOS,YPOS
')
y la subrutina char2buff (que copiaría el bitmap de pantalla a buffer):
$this->bbcode_second_pass_code('', '
char2buff: ;; El comienzo es una copia de getscraddr
ld a, (xpos)
and 31
ld l, a
ld a, (ypos)
ld c, a
and 24
add a, 64
ld h, a
ld a, c
and 7
rrca
rrca
rrca
or l
ld l, a

;; Ahora viene el código de copiado desenrollado: 8 veces ld a, (hl) .. ld (de), a
...
...
ret
')
Este código debería ser igual de eficiente que el original, pero mucho más corto. Así ahorraríamos un buen puñado de bytes. Qué os parece???

[na_th_an]

Me parece todo genial, lo que sea para mejorar la biblioteca, bienvenido sea. Soy consciente de que el código es un poco basurilla, entre otras cosas porque es lo primero que programé en ASM que no fuera un simple efectillo tonto o una copia de datos en bloque. Lo que no tengo es tiempo ahora de ponerme, la verdad, ando con 200 temas de vida real, dos juegos en desarrollo a punto de salir, el concurso de Radas, y mil cosas más De verdad que el año se nos ha puesto un poco cuesta arriba, ya que teníamos dos mil proyectos y al final vamos a tener que dejar bastantes cosas para el año que viene...

Sobre "minicódigo para probar", no tengo (nosotros, "para probar", hacemos un juego directamente, que si no, nos aburrimos), pero hace tiempo te mandé lo que llevaba hecho para el concurso de Radas para que le echases un vistazo. Ahí tienes el uso de la biblioteca a saco, con los cuatro sprites a la vez, animaciones, cambios de color, todo.

Puedes cambiar el código como mejor te venga, y formatearlo para que quede mejor con el resto. Soy muy consciente de que mi manera de indentar es un poco "característica" . Sobre los tabuladores, debe habérseme pasado, ya que intento convertir de tabuladores a espacios antes de publicar nada. En mi editor de textos tengo TAB = 4 espacios, y lo suelo dejar así mientras desarrollo porque es más cómodo, pero para publicar suelo hacer la conversión.

Ya tengo el repositorio configurado desde hace tiempo Bien es cierto que hace tiempo que no hago un Update... Ea, ya está hecho

[boriel]

Ok! No problem. Ya subí la versión más reducida. También estoy cambiando otras cosas en el compilador.
Digamos que tengo que "estandarizar" todo lo posible antes de empezar la rama 2.0beta. Y por eso quería dejarlo todo ordenadito.

Para mi el mayor coñazo son los gráficos. ¿¿Con qué los hacéis??

[na_th_an]

Con Photoshop Luego los convertimos con SevenuP. La salida de código C de SevenuP es muy fácil de adaptar a la sintaxis de un array de ZX Basic y se puede hacer con un find/replace en el editor de textos

[angel]

$this->bbcode_second_pass_quote('na_th_an', 'C')on Photoshop Luego los convertimos con SevenuP. La salida de código C de SevenuP es muy fácil de adaptar a la sintaxis de un array de ZX Basic y se puede hacer con un find/replace en el editor de textos