susso escribió:Interesante hilo, por si acaso dejo un link de optimizaciones que de vez en cuando echo una ojeada:
http://wikiti.brandonw.net/index.php?ti ... timization
Enviado con Tapatalk
Que bueno!! Gracias.
Moderador: Sir Cilve Sinclair
susso escribió:Interesante hilo, por si acaso dejo un link de optimizaciones que de vez en cuando echo una ojeada:
http://wikiti.brandonw.net/index.php?ti ... timization
Enviado con Tapatalk
zx81 escribió:climacus escribió:antoniovillena escribió:Sí, usa sprites prerrotados. Concretamente 4 rotaciones por sprite (siendo el desplazamiento de 2 pixeles). Y no, no es nada complicado, tan sólo tienes que hacer que tu rutina pinte el fondo rotado sin sprites pero con el mismo orden. Lo importante es coger es la idea.
Ya decia yo que iba muy deprisa todo! Ya me has picado para hacer una rutina de sprites prerrotados.
Creo que el raster va linea a linea de izquierda a derecha. Osea, que en vez de pintar tile a tile completo hay que pintar el primer scan del tile de la izquierda, el primer scan del de su derecha y asi sucesivamente, no?
Pero creo recordar que en Cobra se vuelca el fondo a base de PUSHes, por lo que el proceso es a la inversa...
El raster va, efectivamente, de izquierda a derecha y de arriba a abajo. Para pintar sin que se vea, puedes ir por detrás del raster, o si te da tiempo, aprovechar momentos en medio. Una línea de raster dura 224 t-estados de CPU en el 48k (228 en los demás). El primer pixel se pinta en pantalla 14336 t-estados después de la interrupción. Antes de eso está el borde, lo mismo que tras 57248 t-estados, que es donde empieza el borde inferior (recuerda, todo lo que digo son timings del 48k). Un frame completo son 69888 t-estados.
Cada línea de raster necesita los primeros 128 t-estados de los 224 que dura, así que al final de cada una te quedan 96 t-estados, difíciles de aprovechar, pero posible en teoría. Para hacerlo por PUSH, podrías esperar al estado 57248 y así tendrías 26976 t-estados para actualizar (gestión de la interrupción aparte).
El arkanoid, por ejemplo, dibuja la bola alrededor del t-estado 400 y la borra sobre los 57000. De esa forma, el movimiento de la bola es absolutamente suave.
susso escribió:Espera, espera.. Tienes más saltos y más returns. Hay más ciclos.
climacus escribió:Vaya tela. La verdad es que me he hecho comodo usando la shadow screen. Pero esto me parece de lo mas interesante. Nunca me habia dado por contar estados...
Muchas gracias. Cacharreare con el asunto.
antoniovillena escribió:susso escribió:Espera, espera.. Tienes más saltos y más returns. Hay más ciclos.
No, son los mismos ciclos pero te ahorras 3 bytes.climacus escribió:Vaya tela. La verdad es que me he hecho comodo usando la shadow screen. Pero esto me parece de lo mas interesante. Nunca me habia dado por contar estados...
Muchas gracias. Cacharreare con el asunto.
Gracias zx81 por explicárselo. ¿Qué usas la shadow screen de los modelos 128K?
antoniovillena escribió:susso escribió:Interesante hilo, por si acaso dejo un link de optimizaciones que de vez en cuando echo una ojeada:
http://wikiti.brandonw.net/index.php?ti ... timization
Interesante. Pero podrían optimizar esto:Código: Seleccionar todo
foo:
ld hl, data
call bar ; Run routine once
call bar ; .. twice
call bar ; .. three times
bar:
ld a, (hl) ; .. fourth and final time
inc l
and $0F
out (c), a
ret
Por esto otro:Código: Seleccionar todo
foo:
ld hl, data
call bar1
bar1:
call bar2
bar2:
ld a, (hl)
inc l
and $0F
out (c), a
ret
Código: Seleccionar todo
ld hl,bar2
push hl
push hl
push hl
ld hl,data
bar2:
ld a, (hl)
inc l
and $0F
out (c), a
ret
climacus escribió:Sí. En todos los juegos que he hecho para 128k uso la shadow screen. Es muy cómodo y aunque tienes menos memoria al ir paginando la pantalla, merece la pena. Lo malo es que te despreocupas demasiado de las cosas importantes de la vida, como una gestión óptima de la pantalla...
climacus escribió:Esto no optimizaría más?Código: Seleccionar todo
ld hl,bar2
push hl
push hl
push hl
ld hl,data
bar2:
ld a, (hl)
inc l
and $0F
out (c), a
ret
Son 43 ciclos (quitando la rutina común) y 6 bytes.
wilco2009 escribió:Realmente ingenioso, aunque ilegible.
wilco2009 escribió:Realmente ingenioso, aunque ilegible.
La única observación es que la pila es 2 bytes más grande que en la solución de antonio que tiene dos calls anidados, y 4 bytes más grande que en la inicial que llama a las subrutinas secuencialmente.
Cierto es que la memoria de la pila es memoria temporal y luego se recupera.
En cuanto a cliclos de ejecución no hay color, aunque a mi me salen 28 ciclos menos en total no 43.
Código: Seleccionar todo
ld hl,exit
push hl
ld hl,bar2
push hl
push hl
ld hl,data
bar2:
ld a, (hl)
inc l
and $0F
out (c), a
ret
exit:
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 11 invitados