Ampliación de memoria a 128K

[Sinclair]

¡¡Ondiá, flopping, tela, telita, tela!! La de cosas que se podrían hacer con eso...
antoniovillena, en el ejemplo que has puesto no veo claro el uso del doble buffer, la verdad.

Jejeje, pues a mi me parece lo contrario, el screen de flopping me parece muy normal, en cambio la demo de los mojontwins me parece acojonante ya que a la velocidad que se mueven los sprites no se produce ningún parpadeo en pantalla ni siquiera cuando estos se superponen.

[antoniovillena]

Lo del doble buffer ss algo bastante común en las consolas de hoy en día, pero no sé si lo era tanto en la época del Spectrum.

No lo era tanto porque fue un añadido en los modelos 128K, precisamente se añadió la shadow RAM para poder hacer doble buffering y así evitar los parpadeos. El problema es que la máquina alcanzó su apogeo en los 48K y los juegos empleaban técnicas de pintado de sprites que paliaban en gran medida el parpadeo. Por eso normalmente sacaban juegos compatibles con 48K y 128K, con la diferencia de que en 128K cabían todos los niveles en RAM y en 48K había que darle al play cada vez que pasabas de nivel. No merecía la pena mejorar el pintado en 128K cuando en 48K y sin doble buffer apenas se notaba el parpadeo. Y claro juegos sólo 128K sacaron muy pocos.

Para que comprobéis lo que os digo del truco anti parpadeos tendréis que ver frame a frame lo que ocurre. Si cargáis un típico juego de 48K (por ejemplo Manic Miner) y lo véis frame a frame (ya sea mediante depurador o grabando un video) os daréis cuenta de que los sprites tienen defectos. A veces aparece la cabeza del personaje con el cuerpo que no le corresponde, de una animación anterior o posterior. Esto a 50fps casi no se nota.

La clave está en el pintado y borrado de los sprites. Con doble buffer puedes borrar el sprite del todo y volver a pintarlo con toda la tranquilidad del mundo, ya que si mientras pasa el haz de electrones no pasa nada, se muestra una pantalla que ya está generada y no estamos tocando. En 48K se las ingeniaban para actualizar el sprite sin tener que borrarlo, es decir machacaban poco a poco el sprite anterior. Esto suena fácil pero es más complejo (y más lento) que borrar todo el sprite y pintarlo de nuevo. Pero claro, no tienes alternativa, nunca sabes cuando va a pasar el haz de electrones y como te pille con el sprite borrado o a medio pintar... parpadeo al canto.

[Bubu]

Bueno, pero esto de los parpardeos está totalmente resuelto cuando se programa convenientemente en la rutina de interrupciones y se espera al haz de electrones. Sólo los primerísimos juegos del Spectrum tenían parpadeos, pero a partir de un cierto nivel ya no. Nu sé... se me ocurre p.ej. el Highay Encounter. Mirad la intro que tiene, con muchos sprites dando vueltas por ahí cruzándose unos con otros.
Pero sí, tiés razón con lo de que en el 48 KB había que currarse por software el anti parpadeo. Con esto del doble buffer lo tienes cubierto mediante hardware, que siempre será mucho más fácil y efestivo

[antoniovillena]

¡¡Ondiá, flopping, tela, telita, tela!! La de cosas que se podrían hacer con eso...
antoniovillena, en el ejemplo que has puesto no veo claro el uso del doble buffer, la verdad.

La demo tienes que cargarla en algún modelo de 128K. Si la pruebas en 48K no verás parpadeo porque empleo una técnica de sincronización que me permite pintar hasta 8 sprites sin parpadeo. Pero existe el límite de los 8 sprites. Con un modelo 128K y shadow RAM no existe tal limitación, puedes tirarte el frame entero pintando sprites que nunca tendrás parpadeo.

[Bubu]

Ajolá pudieras contar esa tésnica de sincronización, aunque fuera en un nuevo hilo para dejar éste con el tema de la ampliación de 128 KB. Me gustan muchísimo estas historias : - )

[antoniovillena]

Bueno, pero esto de los parpardeos está totalmente resuelto cuando se programa convenientemente en la rutina de interrupciones y se espera al haz de electrones.

Precisamente en el momento de la interrupción es cuando el haz de electrones se desactiva para volver a subir (retrazo vertical). Desde la interrupción hasta que el haz de electrones pasa por el primer byte de pantalla (ojo no de borde) pasan unos 14400 ciclos. Es cierto que todo lo que pintes en este periodo de tiempo no tendrá parpadeos, pero se queda muy corto, apenas te da tiempo a pintar 2 sprites. Por eso hay que emplear otra técnica.

[Sinclair]

Ajolá pudieras contar esa tésnica de sincronización, aunque fuera en un nuevo hilo para dejar éste con el tema de la ampliación de 128 KB. Me gustan muchísimo estas historias : - )

Por mi parte no hay problema en seguir en este mismo hilo

[Bubu]

Bueno, puedes mostrar 2 sprites en cada INT, y por tanto 8 sprites en 4 INT's, las cuales ocurren bastante rápidas.

[antoniovillena]

Ajolá pudieras contar esa tésnica de sincronización, aunque fuera en un nuevo hilo para dejar éste con el tema de la ampliación de 128 KB. Me gustan muchísimo estas historias : - )

Te lo cuento aquí mismo, no tiene ningún secreto. Normalmente en un spectrum sólo podemos sincronizarnos mediante interrupciones. Sin embargo usando el bus flotante la cosa cambia. El bus flotante es leer del puerto $FF, si mientras está pintando el haz de electrones te devuelve un $ff (50% de probabilidad), un byte de imagen (25%) o un byte de atributo (25%). Si tenemos en cuenta el retrazo horizontal y el borde la probabilidad de un $ff es mayor, porque de los 224 ciclos que dura una línea, 128 es la línea en sí, los 96 restantes son el borde y el retrazo horizontal.

Una forma sencilla de sincronizar con el bus flotante es tras una interrupción empezar a leer del puerto $ff hasta encontrarte con un valor distinto de $ff. Te habrás sincronizado más o menos en el ciclo 14400 (de un total de 69888). Este punto es interesante porque es fácil de detectar y viene muy bien para los juegos con scroll. Lo usa por ejemplo Cobra. La idea es que como sabes que el haz de electrones ya ha pasado y se mueve a una velocidad constante, lo que tienes que hacer es ir un pelín mas lento que el haz de electrones (para no pillarlo) en tu rutina de generación de fondo. Una vez has terminado de generar el fondo (sin sprites) el haz de electrones está aún pintando el borde inferior, más o menos estamos por el ciclo 60000 (o menor si no tu scroll no llega hasta abajo del todo). Luego pintas los sprites y listo. La idea es que el haz no te pilla nunca con la pantalla sin sprites porque vas borrando justo detrás de él y luego aprovechas para pintar los sprites mientras pinta la parte baja de la pantalla, el borde y ocurre el retrazo vertical.

Ahora te explico la técnica avanzada que uso en la demo. Se trata de poner una franja de 32x8 pixeles (una fila de celdas) justo por debajo del área de juego. En esta franja pones unos valores que no sean comunes en una pantalla (como flash) y usas dos tipos de valores. Yo uso $66 y $C0. Ubicando estos valores estrategicamente puedes currarte una rutina que detecte cuando el haz de electrones pasa justo por esa franja mediante lecturas del bus flotante. Es complicado pero funciona, en realidad no necesitas las 8 líneas, te puedes sincronizar en 3 líneas, pero claro necesitas también los atributos y no puedes ocultar esas 3 líneas y que se vean las 5 siguientes porque el color que uso me lo oculta todo (mismo tinta que fondo) para que no se vean los patrones sino una franja de color sólido.

Pues nada, de esa forma aumentas al doble o más el tiempo que tienes para pintar/borrar sprites con la tranquilidad de que no tendrán parpadeo. En lugar de 14400 ciclos puedo tener 25000 o 30000, depende del tamaño del área de juego.

[antoniovillena]

Si os interesa el tema pasaros por este hilo:

http://www.mojontwins.com/mojoniaplus/v ... f=9&t=1461

Se trata de un engine (parecido a la Churrera) para hacer juegos en C sin tener que preocuparse de la parte gráfica. Los sprites se manejan de la misma forma que se manejan los sprites hardware en las consolas, con una estructura mapeada en la memoria donde le dices las coordenadas y los parámetros de cada sprite.