Rutina para dibujar un Sprite en pantalla.

[DaDMaN]

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.

La verdad es que 16 pixeles de altura me desmonta un poco el tema... 20 pixeles por 10 tiles = 200 pixeles (el alto total de la pantalla)... con 16 pixeles, la cosa descuadra un poco... pero si no queda mas remedio, adaptaré "mi pensamiento".

[Artaburu]

Hombre, pueden ser de 20 de alto pero la rutina será un poco más lenta porque comprobará todo el rato si hay salto de caracter o de línea pero irá bastante rápido también. ¿El fondo se guarda o se reconstruye el tile tocado? ¿hay buffer para dibujar los sprites?

[DaDMaN]

Hombre, pueden ser de 20 de alto pero la rutina será un poco más lenta porque comprobará todo el rato si hay salto de caracter o de línea pero irá bastante rápido también. ¿El fondo se guarda o se reconstruye el tile tocado? ¿hay buffer para dibujar los sprites?

La idea es que no se pueda pasar sobre los tiles... seran plataformas... yo no me veo capaz de restaurar fondos ni leches xD

Osea, se dibuja el "mapeado" con los tiles de las plataformas y hasta la siguiente pantalla no se redibuja la pantalla completa...

Habia pensado en meter disparos... que si pasarian sobre los tiles de las plataformas... pero claro... repito, soy un cutre y no me veo capaz de gestionar eso, ni se como hacerlo.

Salu2

[MiguelSky]

Yo creo que hay un problema en la parte final de la rutina, en

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

Esas medidas de ancho hay que cambiarlas por variables para hacer la rutina 'universal'. Por otro lado, el &37b0 no se de donde sale

[Artaburu]

Okis, si el juego es divertido no tiene porqué ser un alarde de la técnica. Como no redibujas tiles sigue con los de 10x20 tranquilamente
Para los disparos, si los dibujar con XOR y cuando pasen los redibujas en la posición anterior con XOR, se restaura el fondo... simpre que no se haya tocado nada. Bueno, como los disparos serán pequeños spritillos diminutos y simpáticos, también puedes capturar el fondo para ellos.

[Artaburu]

Yo creo que hay un problema en la parte final de la rutina, en

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

Esas medidas de ancho hay que cambiarlas por variables para hacer la rutina 'universal'. Por otro lado, el &37b0 no se de donde sale

Ah, pequeño saltamontes... la rutina sólo vale para número par de bytes, eh? y ese número tan raro es el número que hay que restar para pasar a la siguiente línea cuando se salta de caracter. Es la diferencia entre el valor de la última posición de un caracter menos la siguiente (o al revés). Por ejemplo, entre &F800 y &C050

[MiguelSky]

es el número que hay que restar para pasar a la siguiente línea cuando se salta de caracter. Es la diferencia entre el valor de la última posición de un caracter menos la siguiente (o al revés). Por ejemplo, entre &F800 y &C050

Ahá !!! ¿Y que hay de lo sumar C850 y despreciar el acarreo ? xDD Que sepas que me ha gustado , pero deberías estandarizar esa rutina, auqne solo sea para números pares.

[Artaburu]

es el número que hay que restar para pasar a la siguiente línea cuando se salta de caracter. Es la diferencia entre el valor de la última posición de un caracter menos la siguiente (o al revés). Por ejemplo, entre &F800 y &C050

Ahá !!! ¿Y que hay de lo sumar C850 y despreciar el acarreo ? xDD Que sepas que me ha gustado , pero deberías estandarizar esa rutina, auqne solo sea para números pares.

Pero es que para sprites pequeños creo que es más lenta. De todas formas no costará mucho estandarizarla. A ver si esta tarde-noche puedo.

[Artaburu]

Os dejo una rutina que colgó Prodatron en algún foro alemán y que encontró DaDMaN. Mejora muy mucho a las rutinas que hay hasta ahora en este hilo. Sirve para dibujar sprites sólidos (sin transparencias)
La rutina original está aquí:
http://www.cpc-forum.de/phpbb/viewtopic.php?t=209
Ojo que si la cogéis debéis meter un par de ex de,hl porque si no me equivoco, se le olvidó meter un cambio de hl a de para poder hacer el salto de línea.

La rutina que cuelgo aquí está modificada para ejecutarla desde BASIC con call &writesprite,destino,dimensiones,origen
Dimensiones =&alto.ancho
Es muy sencilla de entender y de modificar para pasar los parámetros desde ASM, pero en caso de duda... preguntad.

Código: Seleccionar todo

writesprite:
ld b,(ix+2) ;ancho
ld l,(ix+4)
LD h,(ix+5)

ld a,64
sub b
add a
ld (width1+1),a
xor a
sub b ;-ancho
ld (width2+1),a
ld a,(ix+3) ;A lleva el alto del sprite
width0: ex de,hl
width1: jr width1 ;cada LDI es un byte
;se hace el salto al byte correspondiente (64-ancho)
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi
dec a
ret z
width2:
ld bc,#700
ex de,hl
add hl,bc
jp nc,width0
ld bc,#c050
add hl,bc
jp width0

[jgnavarro]

con meter un jr width1 entre las siguientes lineas funciona:

ld a,(ix+3) ;A lleva el alto del sprite
width0: ex de,hl

o un ex de,hl que es más rápido...

[Mode 2]

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.

Este enlace parece roto ¿sabeis de algun otro sitio donde se encuentre esta información?

Gracias.

[MiguelSky]

Sí

http://www.cpctech.org.uk/docs/instrtim.html

o http://www.cepece.info/amstrad/docs/instrtim.html

Tengo que ver si puedo actualizar el mirror de cepece.info, que ya no lo está...

[syx]

ó puedes usar la versión de mi google code

[jgnavarro]

Me gusta

ó puedes usar la versión de mi google code

[Mode 2]

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.

Sí, es muy instructiva y puedes saber que instrucciones 'penan' más en tiempo pero algo pesado calcularlas a mano. Imagino que con el time de Basic o un análogo en Ensamblador te dará una idea de cómo de rápida o no es una rutina ¿no?

ó puedes usar la versión de mi google code

¡¡¡Que guay!!, y en español.

Os dejo una rutina que colgó Prodatron....

La rutina que cuelgo aquí está modificada para ejecutarla desde BASIC con
call &writesprite,destino,dimensiones,origen donde Dimensiones =&alto.ancho
Es muy sencilla de entender y de modificar para pasar los parámetros desde ASM, pero en caso de duda... preguntad.

writesprite:
ld b,(ix+2) ;ancho
ld l,(ix+4)
LD h,(ix+5)

ld a,64
sub b
add a
ld (width1+1),a
xor a
sub b ;-ancho
ld (width2+1),a
ld a,(ix+3) ;A lleva el alto del sprite
width0: ex de,hl
width1: jr width1 ;cada LDI es un byte
;se hace el salto al byte correspondiente (64-ancho)
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi:ldi
ldi:ldi:ldi:ldi
dec a
ret z
width2:
ld bc,#700
ex de,hl
add hl,bc
jp nc,width0
ld bc,#c050
add hl,bc
jp width0

Tengo una pequeña duda, la he probado y va perfectamente pero ahora a pasarla a Ensamblador, sin la llamada a BASIC veo que la dirección del sprite no aparece asignandose a DE por ningun lado aunque al poner un 'breakpoint' nada más comenzar la rutina ya tiene DE asignada dicha dirección (en mi ejemplo he puesto en &4000 el comienzo del código y el sprite en &4400). Seguramente será una tontería, pero no la veo.

Por cierto, a día de hoy ¿es ésta la rutina más rápida para pintar un sprite sin respetar el fondo que conocéis?

Gracias.