Buffers de trabajo intermedios en volcados de pantallas

Todo sobre la creación, diseño y programación de nuevo software para
nuestro Spectrum

Moderador: Sir Cilve Sinclair

Avatar de Usuario
Metalbrain
Freddy Hardest
Mensajes: 590
Registrado: Lun May 07, 2007 8:17 am
Ubicación: Sevilla
Contactar:

Mensaje por Metalbrain » Vie Oct 05, 2007 12:09 am

Gandulf escribió: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
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Vie Oct 05, 2007 1:28 am

:lol: :lol:

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 :P :P :P

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)
Un saludo,

Gandulf

Avatar de Usuario
sromero
Nonamed
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia
Contactar:

Mensaje por sromero » Vie Oct 05, 2007 9:45 am

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
NoP / Compiler

Avatar de Usuario
sromero
Nonamed
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia
Contactar:

Mensaje por sromero » Vie Oct 05, 2007 2:20 pm

Gandulf escribió: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 :)
NoP / Compiler

Avatar de Usuario
TrueVideo
Jack The Nipper
Mensajes: 195
Registrado: Mié May 23, 2007 8:34 am
Ubicación: BCN
Contactar:

Mensaje por TrueVideo » Vie Oct 05, 2007 5:00 pm

Gandulf escribió: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

Avatar de Usuario
TrueVideo
Jack The Nipper
Mensajes: 195
Registrado: Mié May 23, 2007 8:34 am
Ubicación: BCN
Contactar:

Mensaje por TrueVideo » Vie Oct 05, 2007 5:04 pm

Gandulf escribió: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
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Vie Oct 05, 2007 5:22 pm

@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.
Última edición por Gandulf el Vie Oct 05, 2007 5:43 pm, editado 1 vez en total.
Un saludo,

Gandulf

Gandulf
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Vie Oct 05, 2007 5:38 pm

¡Claro que me interesa!

Tienes un mensaje privado
Un saludo,

Gandulf

Avatar de Usuario
TrueVideo
Jack The Nipper
Mensajes: 195
Registrado: Mié May 23, 2007 8:34 am
Ubicación: BCN
Contactar:

Mensaje por TrueVideo » Dom Oct 07, 2007 12:28 am

@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
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Dom Oct 07, 2007 3:22 am

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).
Un saludo,

Gandulf

Avatar de Usuario
TrueVideo
Jack The Nipper
Mensajes: 195
Registrado: Mié May 23, 2007 8:34 am
Ubicación: BCN
Contactar:

Mensaje por TrueVideo » Dom Oct 07, 2007 9:37 am

Gandulf escribió: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
rst 0
Mensajes: 25
Registrado: Mié May 09, 2007 10:32 am

Mensaje por Kak » Dom Oct 07, 2007 11:02 am

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.

Avatar de Usuario
sromero
Nonamed
Mensajes: 1221
Registrado: Mar Abr 17, 2007 12:35 pm
Ubicación: Valencia
Contactar:

Mensaje por sromero » Dom Oct 07, 2007 11:33 am

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
NoP / Compiler

Gandulf
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Dom Oct 07, 2007 11:48 am

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 :P ) 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 :)
Un saludo,

Gandulf

Gandulf
Nonamed
Mensajes: 1067
Registrado: Lun May 07, 2007 10:06 pm

Mensaje por Gandulf » Dom Oct 07, 2007 12:02 pm

@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
Un saludo,

Gandulf

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: Bing [Bot] y 3 invitados