Buffers de trabajo intermedios en volcados de pantallas

[Metalbrain]

Os entiendo y os respeto. Siempre habrá gente como vosotros que comparte el código y lo hace libre y gente como yo que no lo comparte porque es mío.

Pero debes reconocer que estuviste tentado hace unos meses:

http://groups.google.es/group/es.comp.sistemas.sinclair/browse_frm/thread/2ce4ddc7...

[Gandulf]

Sí, pero era otro proyecto distinto y que no tiene nada que ver con este. Con lo que me ha costado a mi esta fase 4

Puedo publicar el de Ragnablock si a alguien le interesa, el código no tiene nada de especial en principio, pero como han pasado 2 años no me importaría. Si alguien lo quiere lo cuelgo de algún lado.

Por ejemplo publicar los fuentes varios años después de la salida del juego/aplicación no me suele importar nada. Si.... ya se que soy un poco rarito (raaaaro, raaaaaro)

[sromero]

No quiero desviar más el tema así que he creado un hilo para tratar esto, y me gustaría que os pasaráis (especialmente Gandulf) por él:

http://www.speccy.org/foro/viewtopic.php?p=2233#2233

[sromero]

Puedo publicar el de Ragnablock si a alguien le interesa, el código no tiene nada de especial en principio, pero como han pasado 2 años no me importaría. Si alguien lo quiere lo cuelgo de algún lado.

¡Claro que me interesa!

Estoy segurísimo de que aprenderé muchas cosas de él, y como lo tengas comentado ya ni te cuento X-D

Si algo me permitió aprender ASM de Z80 fue, precisamente, el emulador de Spectrum de Marat Faizullin y el hecho de que tenga los fuentes disponibles en su web, gracias a eso programé mi emulador Aspectrum y por eso es GPL

[TrueVideo]

Por cierto que los rotados no los hago sino que utilizo tablas de valores prerotados, que es mucho más eficiente, y por supuesto utiliza mucha menos memoria que utilizar sprites prerotados (inviable en un juego más o menos largo).

No veo claro esto de las tablas con valores prerotados para sprites. Como construyes un sprite (rotado n veces) mediante tablas de forma eficiente? Podrías detallar un poco el procedimiento?

J

[TrueVideo]

Por ejemplo publicar los fuentes varios años después de la salida del juego/aplicación no me suele importar nada. Si.... ya se que soy un poco rarito (raaaaro, raaaaaro)

A mi tampoco me gusta publicar fuentes, especialmente los antiguos. Así que reclamo un bonus extra en concepto de rareza.

J

[Gandulf]

@TRUEVIDEO
No veo claro esto de las tablas con valores prerotados para sprites

No se construye el sprite. Esa es la diferencia. Por ejemplo en Ragnablock guardaba algunos sprites ya rotados y ponía uno u otro. En un juego grande es inviable.

Imagínate que tienes sprites que se mueven de 2 en 2 pixels. Necesitas 4 tablas de 512 bytes con todos los valores rotados (los precalculas al iniciarse el programa) y la parte que se "sale" de la rotación. A la hora de imprimir un sprite, si tienes que rotarlo N veces te vas a la tabla adecuada y coges el valor de cada byte, ya rotado. Para que sea eficiente el truco consiste en guardarlas en direcciones especiales de forma que para pasar del valor rotado a la parte que se sale sólo haya que incrementar el byte más significativo.

Si ves el código es super sencillo y va como una moto, con sprites muy grandes. Bueno, ya lo vereis cuando saquemos el juego.

EDITADO: Cuando me refiero a valores rotados no me refiero a los datos del sprite, sino a los 256 posibles valores de un byte rotados N veces, por cada valor de rotación una tabla. Son 512 porque hacen falta el valor rotado y la parte que "sale" por el otro lado en la rotación.

[Gandulf]

¡Claro que me interesa!

Tienes un mensaje privado

[TrueVideo]

@Ganduf

Ya suponía que el método sería este, pero me refería a que no veo claro cómo puede ser eficiente con todos los accesos extra por cada byte. Lo digo porque este método podría doblar fácilmente el tiempo de ejecución respecto al enfoque convencional, lo cual sería un problema importante en según qué tipo de juegos.

De todos modos me parece una técnica interesante, aunque quizás un poco bruta. Por curiosidad, cuánto tiempo es necesario -más o menos- para imprimir un sprite de digamos 24x24 (o 16x16 no alineado)?

[Gandulf]

El tiempo te lo tengo que calcular, pero te aseguro que es mucho más eficiente que rotar los bytes.

Imaginate que tienes un sprite gordo de 72 pixels de ancho x 40 de alto, o sea 40 x 9 bytes = 360 bytes como es mi caso (a veces 7 en pantalla como ese). Si tengo que rotar 6 veces el sprite, tendría que realizar un montón de rotaciones para tener el sprite impreso. De esta forma sólo tengo que hacer unos pocos accesos y la velocidad es independiente del número de veces que haya que rotar el sprite.

Lógicamente sólo tiene sentido para sprites no alineados que tengamos que rotar. No es una técnica original, la usan algunos juegos comerciales de spectrum (por ejemplo Cyberun).

[TrueVideo]

El tiempo te lo tengo que calcular, pero te aseguro que es mucho más eficiente que rotar los bytes.

Claro, por descontado que es más eficiente que rotar bytes. Te preguntaba lo del tiempo para poder comparar tu técnica con una de impresión convencional con gráficos pre-rotados. Ahora mismo tengo problemas serios de memoria (incluso trabajando con 128K) y estoy pensando en enfocar la impresión desde un ángulo diferente.. estoy dispuesto a sacrificar velocidad por tamaño, pero sólo hasta cierto punto. Por eso me iría muy bien un cálculo aproximado. No necesito t-estados ni nada, simplemente enchufa un raster y dime cuántas líneas tarda en imprimirse (y el tamaño real, si tiene máscara y si guarda el fondo).

Saludos
J

[Kak]

Sin ganas de chafaros el offtopic xDD puedo prometer y prometo ;) que el The Great Escape en "exteriores" usa esta tecnica de tener una pantalla virtual y copiarla directamente a pantalla cuando es necesario (toda entera).

El HoH y el Batman usan algo similar, pero solo para las regiones que se sobreescriben, supongo que algo similar a lo que comentais de la libreria esa.

[sromero]

TrueVideo, por lo visto los SPRITES o el ZOOM (no estoy seguro de a qué se refiere con tanta palabrería para abogados) también están patentados en USA:

http://www.delphion.com/details?pn10=US03697678

US3697678: METHOD AND SYSTEM FOR SELECTIVE DISPLAY OF IMAGES FROM A VIDEO BUFFER

A system for selectively displaying discrete small portions of a large picture on a television monitor, with adjustable controlling means for continuously varying the boundaries of any one of the small portions being displayed.

(por IBM)

X-D

[Gandulf]

el The Great Escape en "exteriores" usa esta tecnica

Como comentara antes, todos los juegos con scroll vuelcan el buffer que tengan entero (los buenos) porque al scrollar, cambia todo el fondo de pantalla, y por eso no tiene sentido refrescar partes. Juegos con scroll sin buffer los hay, aquellos de la primera época que parpadeaban a gogó.

Lo que no tiene sentido es que por ejemplo en Manic Minner y Jet Set Willy se pegue un volcado de buffer completo y encima usando LDIR. Imagino que era lo que tenía aquella época, que como no se podía leer mucho sobre el tema (alto a los del opensource, me refiero a documentación sobre sprites y técnicas, no a código fuente ) pues la gente hacía lo que se lo ocurría así de primeras. Esos juegos volcando sólo las partes cambiantes mejorarían enormemente la velocidad, aunque bueno, tampoco les hace mucha falta eso

[Gandulf]

@TRUEVIDEO
convencional con gráficos pre-rotados

Bufff, eso es rapidísimo, pero la memoria que ocupa lo hace un poco inviable. Yo programo para 48K siempre (almenos de momento seguiré así) y si usara pre-rotados no me cabrían los sprites en el spectrum. Pero si lo tienes que aplicar a un par de sprites o a unos cuantos y tienes memoria para ello, pues sí, es la opción.

Cuando me dices eso de enchufar un raster me dejas como el del chiste del taller de coches al que le dicen que le han cambiado la "junta de trócolo". Me imagino la funcionalidad de lo que comentas, pero es una aplicación?. ¿un aparato? ?¿

EDITADO: De todas formas te puedo decir exactamente los t-states que consume la impresión de un sprite del tamaño que me dijiste, sin el raster., luego te lo miro