No están muert@s, no; ¡están contra las cuerdas! 😀 Bromas aparte, es la primera vez que veo la teoría del doble buffer aplicada con todo detalle; habrá que esperar a la continuación para saber por qué no ha funcionado como se esperaba.
Hay que esperar al barrido de pantalla después de intercambiar los buffers. Curioso que puedas crear una pantalla mas pequeña en el Amstrad, una de verdad y no dejar de dibujar ciertas zonas.
Y, ¿por qué motivo crees que hay que esperar al raster después de intercambiar los buffers? Según lo que hemos explicado en esta sesión, ¿Por qué tenemos más parpadeo al no esperar?
@@ProfesorRetroman Porque al volver inmediatamente al bucle del programa, te pondrías a dibujar los sprites en la pantalla que se esta mostrando actualmente. En el Atari ST (no STe) cuando cambias el registro de la memoria de video, este no lo utiliza hasta la nueva interrupción del barrido, por lo que puedes cambiarlo cuando quieras y después esperar, no se si en el Amstrad va igual o primero debes esperar el barrido y después cambiarlo para no mostrar los dos buffers en un mismo barrido.
Sí y no. Tienes una parte correcta en tu razonamiento y otra que no lo es :). En Amstrad el cambio de zona de memoria de video mostrada no se produce hasta que se inicia el dibujado de un nuevo fotograma. Por lo tanto, el cambio no es inmediato. Hasta aquí, correcto. Sin embargo, la zona de memoria de video que modifico con mi código no depende de esté hecho. Tengo 2 zonas y soy yo quien las administra. Por tanto, si cambio los buffers y empiezo modificar el frame anterior, que aún se estaría viendo en pantalla, el efecto esperable sería similar a no usar double buffer (como antes), en el peor caso. Es decir, si aún estuviera pasando el raster por la zona que estoy modificando, me pillará a medias de borrar y dibujar uno de los Sprites, pero no 7 u 8 como ahora parpadean. Mi código no se ha vuelto misteriosamente más rápido que antes 😉
![Dominar los detalles del doble buffer en Amstrad [ #Z80 #ASM ]](http://i.ytimg.com/vi/OyhjwTNwfPc/mqdefault.jpg)
![Dominar los detalles del doble buffer en Amstrad [ #Z80 #ASM ]](/img/tr.png)
Una clase maestra muy productiva y didáctica. Gracias
No están muert@s, no; ¡están contra las cuerdas! 😀 Bromas aparte, es la primera vez que veo la teoría del doble buffer aplicada con todo detalle; habrá que esperar a la continuación para saber por qué no ha funcionado como se esperaba.
Hay que esperar al barrido de pantalla después de intercambiar los buffers. Curioso que puedas crear una pantalla mas pequeña en el Amstrad, una de verdad y no dejar de dibujar ciertas zonas.
Y, ¿por qué motivo crees que hay que esperar al raster después de intercambiar los buffers? Según lo que hemos explicado en esta sesión, ¿Por qué tenemos más parpadeo al no esperar?
@@ProfesorRetroman Porque al volver inmediatamente al bucle del programa, te pondrías a dibujar los sprites en la pantalla que se esta mostrando actualmente. En el Atari ST (no STe) cuando cambias el registro de la memoria de video, este no lo utiliza hasta la nueva interrupción del barrido, por lo que puedes cambiarlo cuando quieras y después esperar, no se si en el Amstrad va igual o primero debes esperar el barrido y después cambiarlo para no mostrar los dos buffers en un mismo barrido.
Sí y no. Tienes una parte correcta en tu razonamiento y otra que no lo es :). En Amstrad el cambio de zona de memoria de video mostrada no se produce hasta que se inicia el dibujado de un nuevo fotograma. Por lo tanto, el cambio no es inmediato. Hasta aquí, correcto. Sin embargo, la zona de memoria de video que modifico con mi código no depende de esté hecho. Tengo 2 zonas y soy yo quien las administra. Por tanto, si cambio los buffers y empiezo modificar el frame anterior, que aún se estaría viendo en pantalla, el efecto esperable sería similar a no usar double buffer (como antes), en el peor caso. Es decir, si aún estuviera pasando el raster por la zona que estoy modificando, me pillará a medias de borrar y dibujar uno de los Sprites, pero no 7 u 8 como ahora parpadean. Mi código no se ha vuelto misteriosamente más rápido que antes 😉
@@ProfesorRetroman dejas siempre a las personas con ganas de más, totalmente intrigadas.