Animación de sprites y Spectaculator

[Rinconete]

Acabo de terminar una rutinilla de animación de sprites que imprime en memoria para combinar el sprite con el fondo y que luego copia esto sobre la memoria de vídeo. El movimiento es suave sin parpadeo. Para sincronizar la rutina con el refresco de la pantalla hay una rutina de servicio de interrupción que inicializa una variable en memoria a 0. Luego, en el bucle principal, justo antes de copiar en memoria de video se inicializa la variable a 1 y se espera a que cambie a 0, es decir, a que haya una interrupción, y entonces se produce la copia sobre la memoria de vídeo.

Cuando ejecuto en Spectaculator el movimiento es suave pero a veces se ve como una especie de interferencia en el sprite, y que además se repite cada tantos segundos. Teniendo en cuenta que estoy moviendo el sprite en la misma coordenada Y (sólo varía la X), que el movimiento es siempre el mismo (de un lado a otro de la pantalla) y que la rutina de impresión está sincronizada con la generación de la interrupción, usease con el refresco de pantalla, ¿porqué rayos sale esa interferencia?.

Con EmuZWin no sale ¿?.

[Gandulf]

Si simplemente esperas a que se produzca la interrupción y no aprovechas ese tiempo, no te hace falta la variable, puedes hacer:

EI
HALT
DI

y ya tienes el inicio de la interrupción y el retrazo vertical.

Si vas a usar ese tiempo para algo, usa el bit 7 del registro R, que es más rápido y no ocupa memoria.

Si usas un monitor TFT Spectaculator no se sincroniza bien con los retrazos, y su usas Windows Vista menos. Para ver si tu animación es perfecta o no, utiliza un spectrum real. De todas formas el "defecto" debería verse siempre en el mismo sitio en vertical.

Si lo que estás haciendo es un volcado de un buffer de 6144 bytes a la dirección 16384, pues es que no da tiempo en un retrazo, para minimizar esto tienes que dejar que te pase el haz de electrones y luego ir detrás con una pequeña pausa.

Otra cosa clave es ¿cómo vuelvas es buffer a VRAM?? Si es con un LDIR irá de pena, primero porque no es demasiado rápido y segundo porque las líneas no irán consecutivas, y por lo tanto tendrás un efecto "persiana".

[Rinconete]

Si simplemente esperas a que se produzca la interrupción y no aprovechas ese tiempo, no te hace falta la variable, puedes hacer:

EI
HALT
DI

y ya tienes el inicio de la interrupción y el retrazo vertical.

Con HALT también lo había probado, obteniendo idéntico resultado.

Si vas a usar ese tiempo para algo, usa el bit 7 del registro R, que es más rápido y no ocupa memoria.

sí, voy a usar el tiempo para otra cosa; y ¡no recordaba lo del registro R! tomo nota

Si usas un monitor TFT Spectaculator no se sincroniza bien con los retrazos, y su usas Windows Vista menos. Para ver si tu animación es perfecta o no, utiliza un spectrum real. De todas formas el "defecto" debería verse siempre en el mismo sitio en vertical.

supongo que esto incluye también los portátiles . Estoy usando uno, y además Vista y Spectaculator 6.30.

El movimiento es un sprite que circula de derecha a izquierda con la coordenada Y constante. Lo curioso es que el defecto se reproduce cada tantos segundos. Es como cuando te pilla el refresco de la pantalla y el gráfico aparece como quebrado.

Si lo que estás haciendo es un volcado de un buffer de 6144 bytes a la dirección 16384, pues es que no da tiempo en un retrazo, para minimizar esto tienes que dejar que te pase el haz de electrones y luego ir detrás con una pequeña pausa.

ok, no es mi caso, estoy imprimiendo sólo el gráfico

Otra cosa clave es ¿cómo vuelvas es buffer a VRAM?? Si es con un LDIR irá de pena, primero porque no es demasiado rápido y segundo porque las líneas no irán consecutivas, y por lo tanto tendrás un efecto "persiana".

Estoy usando una instrucción LDIR para cada línea del sprite. Sólo estoy transfiriendo 120 bytes en total. Esto no debería ser un problema, ¿no?

[Gandulf]

Había entendido que estabas volcando un buffer a RAM. Si sólo estás metiendo un sprite, ¿cómo lo animas? Es decir, si hay un fondo, tienes que guardar y restaurar este además de hacer la impresión del sprite. ¿En qué momento lo haces? De todas formas en un barrido da tiempo de sobra a meter un sprite de la forma que sea, de forma que o tienes un código muy lento o es un problema de sincronismo vertical del spectaculator, que si usas Vista y Spectaculator 6.30 puedes contar con ello.

Prueba a instalar el Eighty One, pero no se te ocurra descargarte la beta, que no funciona bien, bájate la última estable.

[Rinconete]

Había entendido que estabas volcando un buffer a RAM. Si sólo estás metiendo un sprite, ¿cómo lo animas? Es decir, si hay un fondo, tienes que guardar y restaurar este además de hacer la impresión del sprite. ¿En qué momento lo haces?

Tienes razón me he expresado mal, quería decir que uso un buffer para componer la imagen: restaurar fondo, tomar nuevo fondo, componer (máscara and fondo) or sprite. El buffer es 8 pixels más grande en cada dimensión que el sprite. Cuando se acaba de componer la imagen se copia el buffer a la memoria de vídeo.

De todas formas en un barrido da tiempo de sobra a meter un sprite de la forma que sea, de forma que o tienes un código muy lento o es un problema de sincronismo vertical del spectaculator, que si usas Vista y Spectaculator 6.30 puedes contar con ello.

aunque el código es optimizable creo que este no es el problema

Prueba a instalar el Eighty One, pero no se te ocurra descargarte la beta, que no funciona bien, bájate la última estable.

he probado y no aparece el defecto, aunque creo que el movimiento es más suave en spectaculator (a pesar del defecto que aparece a veces) y emuzwin. También puede ser por el hardware de video del portátil que no es gran cosa.