mad3001 escribió: ↑19 Feb 2022, 14:45
¿Vas a echarle un vistazo y "acelerar" la versión que pasaste a Dandanator?
Hecho.
¿Lo podeis actualizar en la web del dandanator?
adjunto nuevo archivo comprimido con la version MLD y DSK. Están solo en Ingles y uso el compresor zx0
por lo que al arrastrar el mld al generador de roms no detecta la scr del multiloader pero el MLD solo ocupa 64k.
y de paso he conseguido aceleralo otro poquito modificando tambien las rutinas de pintado de sprites invertidos ....
https://mega.nz/file/2N9B0IxT#jU5TuG-Uf ... eiItk9Jc3g
como culturilla general.
el juego es una pasada a nivel optimización de codigo usa las mismas rutinas de impresion con codigo automodificable para casi todo.
osea usa la misma rutina para pintar los tiles de la pantalla de primer plano asi como los sprites.
en pintar el fondo de la pantalla la rutina original tarda unos 357.000 t-states.
la rutina especifica super optimizada que he creado solo para pintar la pantalla tarda 178.000 t-states en pintar el mismo fondo de la pantalla sin modificar la estructura de los tiles osea practicamente la mitad de tiempo
despues en la rutina de pintado de sprites he echo varios cambios sin alterar la extructura de la rutina original para que pueda seguir automodificandola el juego.
por ejemplo
hay una parte en que los sprites hablan, y en la aparacion de la galleta se le aplica una mascara adicional para que aparezcan rayados como con un efecto de niebla que usa:
ld a, e
and #AA
ld e, a
pero que normalmente estan con 4 nops para el resto de sprites ...
nop
nop
nop
nop
pues estos 4 nops que parece que no hacen nada gastan 16t-states
asi que he cambiado la modificación que hace de estos "4 x nops" por "2 x jr $+2"
quedando asi:
jr $+2
jr $+2
al ejecutar el primer jr se salta el segundo gastando solo 12 tstates lo que ahorra 4 t-states por byte pintado en la rutina de sprites no es mucho pero al ser en un bucle de bajo nivel, dependiendo del tamaño del sprite nos ahorra 4-states por byte del sprite .....
otra modificacion que he echo en esta ultima version ha sido añadir una tabla de rotacion para las mascaras y los sprites
el pintado de sprites rotados consiste en una rutina tambien automodificable que se usa tambien para tiles en primer plano rotados.
pero que rota los datos y las mascaras en tiempo de ejecucion
para rotar un byte su mascara y pintarlo la rutina emplea 457t-states por byte pintado en el bucle horizontal.
he creado una tabla de rotacion
y cada vez que pinta un byte rotado en vez de rotarlo lo que hago es
guardo el valor de hl, uso hl para localizar en la tabla el valor rotado que necesito y recupero hl
y en hacer lo mismo dentro del bucle horizontal, osea rotar la mascara, rotar el byte del sprite, hacer un and con la pantalla y pintarlo en pantalla solo uso 72 t-states y me ahorro 380 tstates por cada byte rotado ....
realmente cuando en la pantalla no hay excesivos sprites o tiles en primer plano
por ejemplo de la primera pantalla que no tiene carga de sprites, el juego tardaba unos 380.000 tstates en hacer un bucle completo de main
y unos 700.000 t-states para la pantalla de abajo que tiene 2 mudokon para salvar, dos lasers, y tres guillotinas en movimiento.
pues en esta pantalla ahora tarda unos 500.000 llegando a ahorrar unos 200.000 lo que equivale a 3 fotogramas.
en una pantalla sin carga de sprites y trampas el rendimiento ha subido aproximadamente un 50%
en una pantalla con la maxima carga de sprites y trampas calculo que ronda el 35%
ahora realmente cuando pulsas X , Abe corre
saludos