Re: [Aspectrum-devel] Nueva version.

[Kak <jb...@ti...>]

On Wed, 9 Oct 2002 20:07:31 +0200, Alvaro Alea wrote:
>Yo habia pensado en la siguiente solucion:
>cuando se declara el hardware se pone si se quiere emular el=
 port FF
>o no
>0xFF =3D si
>0x00 =3D no
>
>luego en el bucle, en lugar de hacer:
>hwopt.port_FF=3D0xFF
>hwopt.port_FF=3D0x00
>
>como hago ahora hacer:
>hwopt.port_FF|=3D0x01
>hwopt.port_FF&=3D0xFE

si, pero el problema es este: haces.
la cosa esta en que si el port 0xff no se lee, estas haciendo=
 cerca 
de 384 operaciones extras por frame (2 por scanline) para que=
 solo un 
0.5% de los juegos saquen beneficio, mientras se penaliza al=
 99.5% de 
juegos que no usan el port 0xff con 384 operaciones mas por=
 frame.

ya te digo, a mi en principio me da igual hacer un metodo u otro,=
 
pues creo que en mi ordenador ira bien de las dos formas ;)
la cosa esta en que si se quiere hacer rapido para ordenadores=
 mas 
lentos, la tabla es lo mas rapido. Si me apuras por el tamanyo de=
 
memoria que ocupa ;), se podria dividir por 4 y "aproximar" al=
 tstate 
mas proximo: como todas las instrucciones duran mas de 4 tstates=
 no 
tendria que suponer ningun problema, y de todas formas si se hace=
 
como esta ahora ese error tambien esta presente, puesto que=
 cuando 
decimos que emule por N tstates, en realidad suele emular por 
excederse de 0 a 15 tstates


>Y ya ta, de todas maneras, pa mi que el error no esta=
 exactamente en
>esto,
>tendra que ver con esto, pero no es esto, por que probe a=
 comentar
>mi trozo
>en la parte del IN y descomentar tu trozo y sige dando saltitos
>cuando no hay
>enemigos.

entonces quizas sea cosa del cambio de plataforma, pues a mi la 
version con mi trozo no me salta :(
tambien se nota mucho en el sonido, ya que se acelera bastante=
 cuando 
no hay ningun bicho por ahi.

>ademas tengo un problema MUY GRAVE con los tiempos, explico:
>
>Segun el FAQ de ESC css el tiempo es asi:
>
>Interupcion
>16 lineas que pueden ser de retrazo, o pueden ser de borde=
 superior
>(supongo
>que esto es debido a que las teles se comen un trocito de
>pantalla
>48 lineas de borde superior
>192 la zona grafica
>48 bueno no estoy seguro, pero aprox, del borde inferior
>8 del retrazo vertical.
>
>total 312
>
>Aqui ya la empezamos a cagar por que segun eso hay 64 lineas=
 antes
>de empezar
>a dibujar el primer pixel, pero segun los ajustes que yo hice a=
 ojo
>con el
>aquaplane para que el horizonte se dibuje bien solo tiene que=
 pasar
>48.
>
>ademas esta el impreciso echo de que siempre oi que la int se
>producial al
>comienzo del dibujar el frame, no en medio del retrazo vertical,=
 asi
>que pa
>mi que se han colao y esos 16 van con los 8 del final.
>
>
>luego dice:
>la linea horizontal se divide en:
>128 lineas de la zona grafica
>24 lineas del borde derecho
>48 lineas del retrazo horizontal (el fallo va a estar aqui=
 acuerdate
>que me
>dijiste que cambiase el 48 por 24 y yo lo hice a ojos cerrados,=
 la
>version
>que sace tiene 48 estados t menos cada linea grafica )
>24 lineas del borde izquierdo
>
>(ojo con el orden, es importante, empieza las lineas en en=
 borde
>grafico)

cierto!
de hecho con esto ahora mismo acabo de recordar porque meti 48 :)=
 la 
cosa esta en que el dibujado del "grafico" dura 128 tstates, cosa=
 que 
deja 96 tstates para el resto. Entonces dividi eso por 2, y lo=
 asigne 
a cada banda del retrace. 

podria ser que el fallo de velocidad fuera por esto, pero=
 entonces no 
entenderia porque en mi version funciona bien y en otras no :(

De todas formas como no mostramos todo el borde (solo 8 pixels=
 por 
lado) no tendria que suponer ningun problema. Con los bordes 
superior/inferior pasa algo similar: no mostramos todo el borde=
 con 
lo que se pueden asignar lineas a partes no visibles. 




>total 224 que si lo multiplicamos por 312 dan los 69880 estados=
 t
>por frame.
>
>Ahora la volvemos cagar, dice asi que 224*64 t estados tras la
>interrupcion es cuando se empieza a pintar el pixel (0,0),=
 gueno,
>pues en mi
>opinion 224*64 es cuando se deberia empezar a pintar el borde
>izquierdo
>de la linea del pixel (0,0), y 24 estados t mas tarde se=
 empezaria a
>pintar
>el pixel (0,0) o de lo contrario la interrupcion se generaria=
 en
>medio de una
>linea, lo cual no tiene mucho sentido, ademas de que me faltan=
 24
>tstates
>al principio y me sobran al final. 

mmm... en principio se empieza a pintar al final del=
 correspondiente 
scanline:

basandome en los sources antiguos...

o sea, primero pasan 64 lineas donde no se pintan graficos 
(TSTATES_PER_LINE*TOP_BORDER_LINES)

despues se emula 1 linea completa (TSTATES_PER_LINE), da igual=
 que 
sean 24,48 o 200 de borde: lo que cuenta es TSTATES_PER_LINE

y entonces, una vez ya esta emulada, se pinta la linea con el 
DisplayScanline
bueno, segun veo el displayscanline esta antes de emular la linea=
 y 
no despues... supongo que seria mejor tenerlo al final de emular=
 la 
linea.
De todas formas, da igual cuando empiece el 0,0 ya que no=
 dibujamos 
con "precision de pixel", sino de linea. Mientras acertemos donde=
 
empieza la linea y donde acaba, el resultado deberia estar bien.

y una vez hecho esto 192 lineas, se pintan 56 mas (cosa que hacen=
 312 
lineas en total para el 48)



yo diria que los calculos (dejando a banda el error ese de los=
 24/48) 
estan bien, y incluso con ese error, el resultado a la hora de=
 pintar 
no deberia diferir, ya que no usamos para nada el 24/48, sino que=
 
usamos el TSTATES_PER_LINE.
entonces el que estaria mal emulado por culpa del 24/48 seria el=
 port 
0xff

Bye :)
Kak