Último mensaje de la página anterior:
Chema escribió:pser1 escribió:De todas formas, nos conviene mas analizar el motivo real por el que los sprites se mueven a velocidad *tan* dependiente del número
de ellos que pululan por pantalla.
pere
Mmmm ¿qué método usas para dibujarlos? sé que es un xor, me refiero a cómo es la lógica para irlos actualizando, cuándo esperas por el refresco de pantalla...
No he visto la versión de Dragon (ya podíais poner un video ) pero pintando sprites tan pequeños con xor debería de haber muchos, pero muchos muchos, para que se notase ralentización, porque imagino que esperas al sincronismo vertical y pintas todo (o lo intentas) en el período de blank, ¿no?
Ahí debería haber ciclos de reloj de sobra para pintar, no sé, como media docena al menos. En el Oric eran como 5.6us (el reloj es de 1MHz, así que 5600 ciclos). Si no te da tiempo, entonces actualizará cada 2 frames, a 25Hz y ahí sí que debería haber ciclos de sobra.
Igual estás muy cerca del límite (no sé qué otras cosas se hacen por frame ni el tiempo que llevan) y con uno o dos sprites puedes ir a 50Hz y con más saltas a 25Hz, que es la mitad de velocidad y eso es lo que notas.
Hola Chema,
si emplean el sistema de hacer EOR para pintar y de nuevo para borrar ...
El sistema que utiliza el motor AGD es realmente rebuscado, las rutinas Spritexx parece que trabajan linea a linea las 16 lineas del sprite
borrando primero la 'antigua' y añadiendo a continuación la 'nueva', esto es peor que dibujar dos sprites a la vez ya que los punteros a
pantalla y a los datos son diferentes para cada ocurrencia del sprite (antiguo, nuevo). En z80 usan el opcode "exx" 32 veces, 16 para
cada uno de ellos, realmente terrorífico para el sistema 6809!
Creo que hablan de 25 frames por lo que deben dedicar dos interrupciones FS antes de actualizar y posiblemente la versión 6809 no está
esperando dos cuadros ... ya abriré un hilo nuevo, publicaré el fuente de Foggy completo y podremos comentar directamente sobre el código
saludos
pere