Rutina para dibujar un Sprite en pantalla.

[tecnoxarxa]

Os doy una serie de claves:

1º No usar JAMAS los registros índice ix o iy, y menos dentro de un bucle tipo rutina que pinta un sprite. Solo cuando no exista más opción, para tablas de situación etc.
2º No usar jamas ldi ldir, o djwz
3º Procurar que el salto sea jp y no relativo jr
4º Usar siempre las instrucciones más cortas y rápidas en ejecutarse.
5º Normalmente los sprites pueden ser de 2 bytes, 3, 4, de ancho, recomendable escribir una rutina específica e ideada para cada ancho y solo a partir de 4 o 5 bytes, usar una general de ancho variable.
6º Cuando hay scroll, es recomendable muchas veces redibujar todo (ej. livingston supongo II, mutan zone, sol negro..), por tanto no preocuparse demasiado por el fondo. Esto se trabajará según el modo de pantalla del juego intentando respetar los pixels de fondo que no se usan en el sprite, para hacerlo transparente en las zonas que no tiene dibujo el sprite
7º Una buena idea es recuperar datos de un sprite, de dos en dos con la pila.
8º Evitar bucles en general y cálculos tipo add, sbc.

9º Ahora voy por el scroll, cuando tenga reescrita la de dibujar sprites la pego.

[Artaburu]

Con la información que aparece en:
http://andercheran.aiind.upv.es/~amstra ... trtim.html
Se pueden calcular mejor los tiempos relativos de ejecución de las rutinas.

Código: Seleccionar todo

LD bc,xx ;3
ld HL,xx ;3
ld DE,xx ;3
imp_sp_normal
; C, ancho-> actualizar (_ancho_sprite_zz+1)
; B, alto
; HL, origen
; DE, destino

ld a,b ; 1
loop_alto_2zz
_ancho_sprite_zz
ld bc,&0004 ; 3
loop_ancho_2zz
LDI ; 5
LDIR ; 6/5 (3*6+5)
; total:32 NOP
; 8 veces: 32*8=256 NOP
;_______ cambio de línea __________________
ex de,hl ; 1
ademas_linea
LD BC,&07fc ; 3
ADD HL,BC ; 3
jp nc,sig_linea_2zz ; 3
ld bc,&c050 ; 3
add HL,BC ; 3
sig_linea_2zz
ex de,hl ; 1
dec a ; 1
jp nz,loop_alto_2zz ; 3
; en el peor de los casos, la parte de cálculos para cambiar de línea: 21 NOP
; en otro caso: 15 NOP.
; dibujando un sprite de 8 pixels de alto, como mucho, una vez 21 NOP y el resto 15.
; 21+15*7=126 NOP
ret ; 3
;Para dibujar sprites de 4*8 bytes Total NOP: 9+256+126=391
;Entre refrescos de pantalla ocurren 19968 NOP. Da para dibujar unos 50 sprites de 4*8 bytes.

Ale, a trabajar que hay que aumentar el ratio de sprites por refresco

[Mochilote]

Con la información que aparece en:
http://andercheran.aiind.upv.es/~amstra ... trtim.html
Se pueden calcular mejor los tiempos relativos de ejecución de las rutinas.

No había visto la tabla de andercheran, la verdad es que en microsegundos se ven más claras las cosas

Saludos.

[tecnoxarxa]

Claro, o recuerdo mirarlo en el libro del Z80 en pulsos de reloj.

Es la mejor forma. sumando los tiempos.

En internet hay más sitios donde poder verlo. Lo más fácil, es ir a la web de zilog donde hay mucha documentación sobre el tema. Además el libro del Z80 está digitalizado en una tal mula.

saludos !!!!

[Artaburu]

Creo que ya lo comenté en algún hilo pero se pueden mejorar estas rutinas evitando el uso de la pila mediante los registros dobles en modo 8 bits. Por ejemplo:

Código: Seleccionar todo

org &4000
;run &4000

ld de,sp_ppal
ld c, 39 ;alto
ld b,10 ;ancho
ld hl,&f180
call imp_sp_normalx
ret


imp_sp_normalx ; dibujar en pantalla el sprite
; Entradas bc-> Alto Ancho
; de-> origen
; hl-> destino
; Se alteran hl, bc, de, af
;el ancho se guarda en HX
DB &DD:LD L,B ;LD LX,B
;el alto es LY
DB &FD:LD L,C ;LD LY,C
loop_alto_2x
; push bc
; ld b,c
; push hl
DB &DD:LD B,L ;LD B,LX
;push hl
loop_ancho_2x
ld A,(DE)
ld (hl),a
inc de
inc hl
djnz loop_ancho_2x
; en lugar de usar pop y push se hace un cálculo previo de la resta y de la suma
; restar el ancho a HL y continuar (ahorramos pop y push)
;pop hl
;si ha cumplido con el alto se sale.
DB &FD:DEC L
ret z
;codigo del salto de línea
ld a,h
cp %11111000 ;OPCION. Si H empieza por %11111xxx entonces el salto es de caracter
jp m,salto_linea
salto_caracter
ld bc,&37b0+10 ;37b0+ ancho
sbc hl,bc
jp loop_alto_2x
salto_linea
ld bc,&0800-10 ;0800-ancho
add hl,bc
jp loop_alto_2x







sp_ppal
;db &00,&00,&00,&00,&00,&00,&00,&00,&00,&00
db &00,&00,&00,&00,&00,&00,&00,&80,&00,&00
db &00,&00,&00,&00,&00,&00,&30,&48,&00,&00
db &00,&00,&00,&00,&00,&00,&70,&06,&00,&00
db &00,&00,&00,&00,&00,&10,&C0,&12,&00,&00
db &00,&00,&00,&00,&00,&F0,&42,&09,&80,&00
db &00,&00,&00,&00,&30,&F0,&C1,&04,&C0,&00
db &00,&00,&00,&00,&70,&F0,&E0,&0A,&20,&00
db &F0,&80,&00,&00,&F0,&F0,&F0,&04,&60,&00
db &80,&60,&00,&10,&F7,&F7,&F8,&02,&B0,&00
db &C0,&30,&00,&10,&F9,&FC,&FC,&84,&70,&00
db &A0,&10,&80,&10,&D0,&E8,&F5,&80,&30,&00
db &58,&10,&00,&10,&90,&C8,&F7,&80,&00,&80
db &A4,&A0,&00,&00,&F0,&F8,&FF,&C0,&00,&80
db &52,&52,&00,&00,&F6,&FF,&FE,&A0,&10,&00
db &21,&85,&80,&00,&F7,&F7,&FE,&00,&90,&80
db &10,&80,&48,&00,&F3,&FF,&FE,&30,&C0,&40
db &00,&00,&24,&30,&F0,&F1,&FC,&C0,&80,&40
db &00,&00,&12,&60,&50,&73,&CC,&00,&00,&40
db &00,&00,&01,&E4,&70,&F7,&F8,&00,&10,&40
db &00,&00,&10,&78,&30,&F0,&E0,&00,&10,&C0
db &00,&00,&10,&F6,&90,&00,&60,&80,&20,&80
db &00,&00,&10,&FD,&F0,&20,&C0,&40,&10,&80
db &00,&00,&10,&DA,&10,&E0,&F0,&20,&30,&00
db &00,&00,&00,&E7,&90,&3C,&FA,&C0,&70,&00
db &00,&00,&00,&00,&10,&B4,&FF,&E8,&D2,&00
db &00,&00,&00,&00,&10,&79,&FB,&EC,&96,&00
db &00,&00,&30,&80,&30,&96,&F5,&F0,&B4,&00
db &00,&00,&20,&60,&70,&4B,&F3,&D2,&1E,&00
db &00,&00,&50,&B0,&C3,&B4,&70,&A5,&38,&00
db &00,&00,&70,&C0,&70,&E0,&30,&4B,&34,&00
db &00,&00,&70,&F0,&90,&00,&21,&86,&68,&00
db &00,&00,&30,&F0,&E0,&80,&21,&78,&C0,&00
db &00,&00,&00,&70,&F0,&00,&21,&4B,&80,&00
db &00,&00,&00,&10,&F0,&00,&70,&F0,&80,&00
db &00,&00,&00,&00,&00,&00,&F0,&80,&C0,&00
db &00,&00,&00,&00,&00,&00,&B0,&E0,&60,&00
db &00,&00,&00,&00,&00,&00,&D0,&F0,&D0,&00
db &00,&00,&00,&00,&00,&00,&20,&00,&30,&00
db &00,&00,&00,&00,&00,&00,&10,&F0,&E0,&00


[Artaburu]

A raíz del juego Groops y de una conversación con su creador (Eliot) me comentó que el dibujaba los sprites desde abajo a arriba y así evitaba el parpadeo. Quisiera probar esta técnica y modificar alguna de las rutinas para que lo haga hacia arriba, pero antes, por no trabajar para nada (que es tontería). ¿Tenéis alguna rutina que dibuje así? ¿Suponéis que se evitaría parpadeo?

[transformer]

Eso es aplicable a todas las direcciones de movimiento, o en particular a objetos "que caen"? Pq puede tener alguna relación con la forma de refresco de la memoria, la pantalla y la imagen y, a su vez, supongo que dicho efecto y mejora se nota por igual en emuladores y en ordenadores y monitores auténticos (?)

Me ha dejado intrigado esto

[Artaburu]

Caramaba, qué preguntas más raras.
No, simplemente la idea que me he hecho es que como el refresco va pa'bajo, si dibujamos pa'rriba la intersección con el refresco es menor pero claro, también habrá parpadeo (me has hecho pensar) así que no se si se avanzará mucho. Uno de los trucos suele ser dibujar primero los sprites de abajo (cuando empieza el refresco) y después dibujar los de arriba (cuando el refresco ya está por abajo). Pero funcionar y verse se vería y funcionaría por igual en un emu que en el CPC real.

[Artaburu]

A ver si me podéis echar una manita que hay cosas que no llego a entender. En CPCWiki hay alguna rutina para dibujar sprites en la que para moverse por la pantalla y por los datos del sprite usa registros de 8 bits. Por ello hace mención al modo 1 con 32 caracteres y que la dirección de la pantalla tenga el byte más bajo de 64 bytes. O algo así interpreto yo. ¿Estoy en lo cierto o interpreto mal? El párrafo de marras es:

1. The best screen width to use is 32 (MODE 1 characters in CRTC register 1). This is wide enough for most games, and it's special property is that if your screen base address is on a 64 byte boundary, no pixel row will cross a 256 byte page boundary, hence you can use INC reg8 to move to the next display byte rather than INC reg16 (where reg8 is an 8-bit register, and reg16 is a 16-bit register). This only saves 1 microsecond, but in a tight loop, every one counts.

Y el texto completo:
http://www.cpcwiki.com/index.php/Progra ... st_Sprites

[AugustoRuiz]

1. The best screen width to use is 32 (MODE 1 characters in CRTC register 1). This is wide enough for most games, and it's special property is that if your screen base address is on a 64 byte boundary, no pixel row will cross a 256 byte page boundary, hence you can use INC reg8 to move to the next display byte rather than INC reg16 (where reg8 is an 8-bit register, and reg16 is a 16-bit register). This only saves 1 microsecond, but in a tight loop, every one counts.

La traducción literal es:

El mejor ancho de pantalla a utilizar es 32 (caracteres en modo 1, en el registro 1 del CRTC). Esta es lo suficientemente ancha para la mayoría de los juegos, y la propiedad especial que posee es que si la dirección base de la pantalla está dentro de un límite de 64 bytes, ninguna fila de píxeles cruzará un límite de página de 256 bytes, por lo tanto se puede usar un INC reg8 para desplazarse al siguiente byte en vez de un INC reg16 (donde reg8 es un registro de 8 bits y reg16 es un registro de 16 bits). Esto sólo ahorra 1 microsegundo, pero en un bucle "apretado" (es decir, que se repite muchas veces - NdT), cada microsegundo cuenta.

Lo que yo interpreto es que si la dirección base de la pantalla está entre &XX00 y &XX40, los píxeles de una fila estarán entre &00 y &FF, con lo que src_next_byte sería simplemente INC r8, ahorrándote un microsegundo por píxel. Cuanto mayor el sprite, más ganancia, claro.

Pero creo que no quiere decir que la pantalla tenga que estar en modo 1, sino que el ancho lo indica en caracteres de modo 1.

Es decir, 32 caracteres * 8 pixels por caracter = 256 pixels por línea
256 pixels / 4 pixels por byte = 64 bytes por línea. (&40)
&40 (máx dirección base) + &40 (posición del último pixel + 1, creo) = &80 (menor que &FF)

Y para modo 0:

16 caracteres * 8 pixels por caracter = 128 pixels por línea
128 pixels / 2 pixels por byte = 64 bytes por línea. (&40)
&40 (máx dirección base) + &40 (posición del último pixel + 1, creo) = &80 (menor que &FF)

No se si estoy metiendo el zueco hasta el fondo o no...

[Artaburu]

Me parece que es más o menos lo que dices, da igual el modo. He estado mirando la memoria desde &c000 en adelante, por línea, y el salto se produce siempre en la misma columna con lo que se pone la pantalla para que inicie en &c010 en lugar de &c000 tenemos esos 32 caracteres de modo 1 y podemos usar incrementos en registros de 8 bits.

[DaDMaN]

Creo que ya lo comenté en algún hilo pero se pueden mejorar estas rutinas evitando el uso de la pila mediante los registros dobles en modo 8 bits. Por ejemplo:

Código: Seleccionar todo

org &4000
;run &4000

ld de,sp_ppal
ld c, 39 ;alto
ld b,10 ;ancho
ld hl,&f180
call imp_sp_normalx
ret


imp_sp_normalx ; dibujar en pantalla el sprite
; Entradas bc-> Alto Ancho
; de-> origen
; hl-> destino
; Se alteran hl, bc, de, af
;el ancho se guarda en HX
DB &DD:LD L,B ;LD LX,B
;el alto es LY
DB &FD:LD L,C ;LD LY,C
loop_alto_2x
; push bc
; ld b,c
; push hl
DB &DD:LD B,L ;LD B,LX
;push hl
loop_ancho_2x
ld A,(DE)
ld (hl),a
inc de
inc hl
djnz loop_ancho_2x
; en lugar de usar pop y push se hace un cálculo previo de la resta y de la suma
; restar el ancho a HL y continuar (ahorramos pop y push)
;pop hl
;si ha cumplido con el alto se sale.
DB &FD:DEC L
ret z
;codigo del salto de línea
ld a,h
cp %11111000 ;OPCION. Si H empieza por %11111xxx entonces el salto es de caracter
jp m,salto_linea
salto_caracter
ld bc,&37b0+10 ;37b0+ ancho
sbc hl,bc
jp loop_alto_2x
salto_linea
ld bc,&0800-10 ;0800-ancho
add hl,bc
jp loop_alto_2x







sp_ppal
;db &00,&00,&00,&00,&00,&00,&00,&00,&00,&00
db &00,&00,&00,&00,&00,&00,&00,&80,&00,&00
db &00,&00,&00,&00,&00,&00,&30,&48,&00,&00
db &00,&00,&00,&00,&00,&00,&70,&06,&00,&00
db &00,&00,&00,&00,&00,&10,&C0,&12,&00,&00
db &00,&00,&00,&00,&00,&F0,&42,&09,&80,&00
db &00,&00,&00,&00,&30,&F0,&C1,&04,&C0,&00
db &00,&00,&00,&00,&70,&F0,&E0,&0A,&20,&00
db &F0,&80,&00,&00,&F0,&F0,&F0,&04,&60,&00
db &80,&60,&00,&10,&F7,&F7,&F8,&02,&B0,&00
db &C0,&30,&00,&10,&F9,&FC,&FC,&84,&70,&00
db &A0,&10,&80,&10,&D0,&E8,&F5,&80,&30,&00
db &58,&10,&00,&10,&90,&C8,&F7,&80,&00,&80
db &A4,&A0,&00,&00,&F0,&F8,&FF,&C0,&00,&80
db &52,&52,&00,&00,&F6,&FF,&FE,&A0,&10,&00
db &21,&85,&80,&00,&F7,&F7,&FE,&00,&90,&80
db &10,&80,&48,&00,&F3,&FF,&FE,&30,&C0,&40
db &00,&00,&24,&30,&F0,&F1,&FC,&C0,&80,&40
db &00,&00,&12,&60,&50,&73,&CC,&00,&00,&40
db &00,&00,&01,&E4,&70,&F7,&F8,&00,&10,&40
db &00,&00,&10,&78,&30,&F0,&E0,&00,&10,&C0
db &00,&00,&10,&F6,&90,&00,&60,&80,&20,&80
db &00,&00,&10,&FD,&F0,&20,&C0,&40,&10,&80
db &00,&00,&10,&DA,&10,&E0,&F0,&20,&30,&00
db &00,&00,&00,&E7,&90,&3C,&FA,&C0,&70,&00
db &00,&00,&00,&00,&10,&B4,&FF,&E8,&D2,&00
db &00,&00,&00,&00,&10,&79,&FB,&EC,&96,&00
db &00,&00,&30,&80,&30,&96,&F5,&F0,&B4,&00
db &00,&00,&20,&60,&70,&4B,&F3,&D2,&1E,&00
db &00,&00,&50,&B0,&C3,&B4,&70,&A5,&38,&00
db &00,&00,&70,&C0,&70,&E0,&30,&4B,&34,&00
db &00,&00,&70,&F0,&90,&00,&21,&86,&68,&00
db &00,&00,&30,&F0,&E0,&80,&21,&78,&C0,&00
db &00,&00,&00,&70,&F0,&00,&21,&4B,&80,&00
db &00,&00,&00,&10,&F0,&00,&70,&F0,&80,&00
db &00,&00,&00,&00,&00,&00,&F0,&80,&C0,&00
db &00,&00,&00,&00,&00,&00,&B0,&E0,&60,&00
db &00,&00,&00,&00,&00,&00,&D0,&F0,&D0,&00
db &00,&00,&00,&00,&00,&00,&20,&00,&30,&00
db &00,&00,&00,&00,&00,&00,&10,&F0,&E0,&00


Amos a ver... debo tener yo el día muy inútil...
He pillado esta rutina (que aparentemente segun dices Arta es la más rapida de todas las que hay aquí colgadas) para "tilear" un mapeado... Bien, me he puesto a hacer pruebas con ella.

He generado un tile de prueba con el SPROT en MODO 0:

Código: Seleccionar todo

5,20
db &48,&C0,&C0,&C0,&0C
db &00,&88,&CC,&44,&C8
db &00,&00,&00,&00,&88
db &00,&00,&00,&00,&40
db &00,&00,&00,&00,&C8
db &00,&00,&00,&00,&04
db &48,&84,&0C,&C0,&84
db &44,&CC,&08,&88,&CC
db &00,&44,&80,&00,&00
db &00,&44,&00,&00,&00
db &00,&44,&80,&00,&00
db &00,&00,&80,&00,&00
db &00,&44,&80,&00,&00
db &00,&00,&08,&00,&00
db &0C,&C0,&0C,&C0,&48
db &4C,&CC,&44,&44,&00
db &C4,&00,&00,&00,&00
db &44,&00,&00,&00,&00
db &80,&00,&00,&00,&00
db &44,&00,&00,&00,&00

La resolución es de 10x20 (pixeles reales del Modo 0)...

Pues bien, meto el tile, cambio el alto y el ancho por los que me genera el sprot (5x20), ejecuto y cualquier parecido con la realidad es pura coincidencia.

¿Que hago mal? O es que esta rutina solo vale para Modo 1?

[Artaburu]

Ej que el ancho se refiere a bytes... en modo 0 serían 20 pixels.
Si vas a tilear lo mejor es usar otra rutina más sencilla. ¿qué alto y ancho tienen tus tiles?

[DaDMaN]

Ej que el ancho se refiere a bytes... en modo 0 serían 20 pixels.
Si vas a tilear lo mejor es usar otra rutina más sencilla. ¿qué alto y ancho tienen tus tiles?

10 pixeles de ancho (modo 0) y 20 pixeles de alto... osea, un cuadrado perfecto de 20x20 en modo 1 o 10x20 en modo 0

no se si me he explicau!

El tema es que tiene que ir lo mas "follao" posible... pq tiro de BASIC (interpretado de momento), y como tengo que dibujar los 160x200 de la pantalla (160 tiles concretamente), pues... eso

[Artaburu]

Para hacer las cosas más rápidas, te aconsejo un tile de 8 o de 16 pixels de alto de modo que todos se puedan dibujar en inicio de caracter y así ganar velocidad haciendo una rutina específica. El ancho ya da un poco más igual puesto que el cálculo del incremento es trivial.