¿Has hecho algún calculo de cuanta memoria consumiria o la diferencia en rendimiento si se añadieran las rutinas para dibujar tiles a medias y así tener scroll cada dos pixels (un byte)? La que hay ahora seria scroll0, que dibuja los tiles centrados, scroll1 tendría dos rutinas para dibujar tiles, una leería los datos saltándose el primer byte y escribiendo solo 3, y la otra dibujaría solo el primer byte, para scroll 2, una que escriba solo dos bytes de cada tile, scroll 3 seria como scroll1 pero cambiando el orden. Lo puedes poner como ejercicio para subir nota XD
Es bastante más complicado de lo que parece. La rutina actual es extremadamente eficiente gracias al alineamiento y al dibujado de tiles usando interlineado en código gray y filas en zig-zag. Para tener ese rendimiento, está completamente acoplada al dibujo de tiles completos de 4x8 bytes y al alineamiento de pantalla. Sin duda, rutinas que dibujen al byte hay, y se pueden hacer, e incluso se pueden diseñar formas de adaptarlas al uso de esta rutina. Por ejemplo, haciendo una rutina específica para los tiles de borde (que serían los únicos incompletos), al estilo de un clipping para estos tiles. Con eso, se podría incluso seguir usando esta rutina, pintando la parte central del mapa y usando otra rutina diferente para los tiles incompletos del borde. En todos los casos, hay un coste en el rendimiento, casi con total seguridad. Esto, y algunas adaptaciones más (como versiones interrupt-safe e interrupt-fully-unsafe) las tengo pendientes hace mucho tiempo. Como miles de otras cosas, no me da la vida :). A ver si las abordo pronto :)
![No te repitas: mejora tu código unificando y factorizando [ #Z80 #ASM ]](http://i.ytimg.com/vi/yobdYWOMpmM/mqdefault.jpg)
![No te repitas: mejora tu código unificando y factorizando [ #Z80 #ASM ]](/img/tr.png)
![Cómo hacer scroll con cámara: coordenadas de mundo y pantalla [ #Z80 #ASM ]](http://i.ytimg.com/vi/Xzy56byIc04/mqdefault.jpg)
![C++: Gestión Avanzada de Memoria con Placement New [V1_2017][Sesión 10.3]](http://i.ytimg.com/vi/GmIsvHhM9EQ/mqdefault.jpg)
¿Has hecho algún calculo de cuanta memoria consumiria o la diferencia en rendimiento si se añadieran las rutinas para dibujar tiles a medias y así tener scroll cada dos pixels (un byte)? La que hay ahora seria scroll0, que dibuja los tiles centrados, scroll1 tendría dos rutinas para dibujar tiles, una leería los datos saltándose el primer byte y escribiendo solo 3, y la otra dibujaría solo el primer byte, para scroll 2, una que escriba solo dos bytes de cada tile, scroll 3 seria como scroll1 pero cambiando el orden. Lo puedes poner como ejercicio para subir nota XD
Es bastante más complicado de lo que parece. La rutina actual es extremadamente eficiente gracias al alineamiento y al dibujado de tiles usando interlineado en código gray y filas en zig-zag. Para tener ese rendimiento, está completamente acoplada al dibujo de tiles completos de 4x8 bytes y al alineamiento de pantalla.
Sin duda, rutinas que dibujen al byte hay, y se pueden hacer, e incluso se pueden diseñar formas de adaptarlas al uso de esta rutina. Por ejemplo, haciendo una rutina específica para los tiles de borde (que serían los únicos incompletos), al estilo de un clipping para estos tiles. Con eso, se podría incluso seguir usando esta rutina, pintando la parte central del mapa y usando otra rutina diferente para los tiles incompletos del borde. En todos los casos, hay un coste en el rendimiento, casi con total seguridad.
Esto, y algunas adaptaciones más (como versiones interrupt-safe e interrupt-fully-unsafe) las tengo pendientes hace mucho tiempo. Como miles de otras cosas, no me da la vida :). A ver si las abordo pronto :)