From: Jordi <jb...@ti...> - 2002-10-10 21:12:49
|
On Thu, 10 Oct 2002 23:10:04 +0200, Jordi wrote: >On Fri, 11 Oct 2002 07:46:39 +0200, Alvaro Alea wrote: > >>Dos cosinas, 1=BA que editando basic no vais (ojo vais, vosotros >>afortunados >>poseedores de maquinas con cientos de bogomips.) a notar= ningun >>aumento de >>rendimiento, el emulador va a seguir funcionando a 50 fps y= las >>cosas van >>a seguir apareciendo a la misma velocidad. > >por supuesto, es algo obvio :) pero tambien es cierto que no se >usara >tanta cpu, con lo que el ordenador tendra mas tiempo para hacer >otras >cosas > > >> >>2=BA =BFTeneis idea de como implementar el dirty Screen? >>supone interceptar mem_write, comprobar que esta es escribiendo= en >la >>pantalla y actulizar no solo la pantalla si no ademas una tabla= de >>dirty rectangles. >>no se pero no tengo claro que mejore el rendimiento. >> >>y aun asi, tengo mis dudas de que aumente el rendimiento, al >>menos en windows bajo directX no lo vamos a notar, y en linux= en >>ventana, >>tengo mis dudas (pa mi que el cuello de botella esta por otro lado). > >hombre, se puede hacer de forma muy rapida usando una tabla de= 64 >kas, pero como se que no eres muy amigo de las tablas= precalculadas >... ;) a parte de eso no se me ocurre ninguna otra forma rapida= de >hacerlo :( |
From: Alvaro A. <A_...@te...> - 2002-10-10 22:24:28
|
BUENOS DIAS!!! Y entonces, va Jordi y dice ¿Fwd: Re: Fwd: Re: [Aspectrum-devel] Version de allegro que estamos usando para compilar...? > >>2º ¿Teneis idea de como implementar el dirty Screen? > >>supone interceptar mem_write, comprobar que esta es escribiendo en > >la > >>pantalla y actulizar no solo la pantalla si no ademas una tabla de > >>dirty rectangles. > >hombre, se puede hacer de forma muy rapida usando una tabla de 64 > >kas, pero como se que no eres muy amigo de las tablas precalculadas > >... ;) a parte de eso no se me ocurre ninguna otra forma rapida de > >hacerlo :( ¿Y luego que haces? recorres las 6912 direciones de memoria para calcular el(los) rectangulos a blittear, para cuando la rutina en C que realize eso haya acabado de calcular el o los rectangulos, todabia te queda el redibujar esos trozos y el blit en si, y habras consumido mucho mas tiempo que si hubieses redibujado todo y echo el blit completo, pero bueno, siempre podeis demostrarme lo contrario :-) -- Como dije antes, nunca me repito _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Jordi <jb...@ti...> - 2002-10-10 23:36:24
|
On Fri, 11 Oct 2002 09:21:47 +0200, Alvaro Alea wrote: >=BFY luego que haces? recorres las 6912 direciones de memoria= para >calcular >el(los) rectangulos a blittear, para cuando la rutina en C que >realize eso >haya acabado de calcular el o los rectangulos, todabia te queda= el >redibujar >esos trozos y el blit en si, y habras consumido mucho mas tiempo= que >si >hubieses redibujado todo y echo el blit completo, pero bueno, >siempre podeis >demostrarme lo contrario :-) supongamos que los dirty rectangles vayan en grupos de 32x32= (sirve para cualquier tamanyo divisor de los tamanyos de pantalla,= cambiando algunos numerillos). Eso haria que tuvieramos la pantalla en 48 rectangulitos (digamosle rectangulitos[49], porque el ultimo rectangulo es para las zonas de memoria que no son pantalla) creamos un array de 64 kas (memoria del spectrum, digamosle dirty[65536]) donde todos los valores sean 48 (=3Dno son pantalla),= excepto las zonas de pantalla: el byte 16384 corresponde al rectangulo 0,0 -> por tanto metemos= un 0 el byte 16385 corresponde al rectangulo 0,0 -> por tanto metemos= un 0 .... el byte 16388 coresponde al rectangulo 0,1 -> metemos un 1 y asi hasta llenar toda la pantalla el ultimo byte corresponde al 7,6 -> metemos un 47 entonces, cuando hacemos un write en memoria, despues del write,= hacemos rectangulitos[dirty[direccion_escrita]]=3D1; entonces, al final de cada frame se recorren los 48 rectangulitos= (no son tantos) y se dibujan solo las partes de la pantalla que= requieren repintado p.d. esto seria una forma rapida de implementarlo, pero... 1) seria util para cuando se implemente contencion de memoria y dibujo "exacto" en pantalla??? personalmente creo que no, pero= puedo estar equivocado :) 2) iria mas rapido?? personalmente creo que si (el update de= pantalla suele ser una cosa bastante lenta), pero no seria la primera vez= que creo que algo iria mas rapido y a la hora de la verdad es mas= lento 3) vale la pena?? yo creo que no ;) ya que si quisieramos= velocidad punta optariamos por hacerlo en assembler (ahora es cuando me= agacho para esquivar las cuchilladas de Santi XDDDDDDDDD) ala, me voy a dormir y espero no despertarme con un cuchillo de= los del cobra en el esternon.... o donde sea que se claven XD bye :) Kak |
From: Alvaro A. <A_...@te...> - 2002-10-11 22:56:02
|
BUENOS DIAS!!! Y entonces, va Jordi y dice ¿Re: Fwd: Re: Fwd: Re: [Aspectrum-devel] Version de allegro que estamos usando para compilar...? > On Fri, 11 Oct 2002 09:21:47 +0200, Alvaro Alea wrote: > >¿Y luego que haces? recorres las 6912 direciones de memoria para > >calcular > >el(los) rectangulos a blittear, para cuando la rutina en C que > >realize eso > rectangulitos (digamosle rectangulitos[49], porque el ultimo > creamos un array de 64 kas (memoria del spectrum, digamosle > el byte 16384 corresponde al rectangulo 0,0 -> por tanto metemos un 0 > el byte 16388 coresponde al rectangulo 0,1 -> metemos un 1 > entonces, al final de cada frame se recorren los 48 rectangulitos (no > son tantos) y se dibujan solo las partes de la pantalla que requieren > repintado Hum, la idea no esta nada mal. > p.d. esto seria una forma rapida de implementarlo, pero... > 1) seria util para cuando se implemente contencion de memoria y > dibujo "exacto" en pantalla??? personalmente creo que no, pero puedo > estar equivocado :) bien, aqui puede que si y puede que no, si dibujamos toda la pantalla y luego hacemos el blit a memoria de video, pues no(respuesta simple no muy meditada). En cambio si en lugar de hacer rectangulinos, hacemos grupos de scanlines, y tras cada grupo lo bliteamos a la memoria de video, entonces seria muy util, sobre todo en gente que este usando el aspectrum en un monitor de por ejemplo 150Hz pues casi casi podria decirse que ve el en el monitor el rayo de electrones. > 2) iria mas rapido?? personalmente creo que si (el update de pantalla > suele ser una cosa bastante lenta), pero no seria la primera vez que > creo que algo iria mas rapido y a la hora de la verdad es mas lento > 3) vale la pena?? yo creo que no ;) ya que si quisieramos velocidad > punta optariamos por hacerlo en assembler (ahora es cuando me agacho > para esquivar las cuchilladas de Santi XDDDDDDDDD) -- Nada contribuye tanto a la paz del alma como no tener ninguna opinión. _ Grettings of __ _| |___ __ _ Al...@as... LiNUX USER #66734 Saludos / _` | / -_) _` | http://pagina.de/alea A_...@te... de \__,_|_\___\__,_| MS Messenger: alv...@ho... Para obtener Llave Publica GnuPGP un mail con subject: enviar clave pub |
From: Jordi <jb...@ti...> - 2002-10-12 09:15:22
|
On Sat, 12 Oct 2002 09:52:28 +0200, Alvaro Alea wrote: >bien, aqui puede que si y puede que no, si dibujamos toda la >pantalla y luego >hacemos el blit a memoria de video, pues no(respuesta simple no= muy >meditada). > >En cambio si en lugar de hacer rectangulinos, hacemos grupos de >scanlines, y >tras cada grupo lo bliteamos a la memoria de video, entonces= seria >muy util, >sobre todo en gente que este usando el aspectrum en un monitor= de >por ejemplo 150Hz >pues casi casi podria decirse que ve el en el monitor el rayo= de >electrones. es eso, con la tabla se puede meter cualquier distribucion para evitar repintar trozos de pantalla, solo que es eso, si se hace= el update de pantalla a la vez que se emula (para tener en cuenta efectos "raster" y pintado con timing bien pensado para que quede= antes del rayo , y emulacion de memoria contendida, no se hasta= que punto servira. es que son muchas cosas juntas ;) |