Karoshi MSX Community
06 de Julio de 2021, 12:41:45 am *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: 1 2 3 [4] 5 6
  Imprimir  
Autor Tema: Evitando la "Regla del 5º Sprite" (antes "Snippets")  (Leído 37534 veces)
0 Usuarios y 1 Visitante están viendo este tema.
WYZ
Visitante
« Respuesta #45 : 17 de Octubre de 2006, 10:23:57 pm »

Muy didáctica esa demo JL. Si es que no tiene uno mas remedio que hacerse fan tuyo! Cheesy
En línea
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #46 : 18 de Octubre de 2006, 08:24:09 am »

Jltursan, te voy a mandar un emilio para que veas una cosilla, ok?  Wink
En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
jltursan
Karoshi Forum's Guru
*******
Mensajes: 1516


¿Que es lo que has aprendido hoy?


WWW Email
« Respuesta #47 : 18 de Octubre de 2006, 09:40:41 am »

Como comentan ARTRAG y Robsy, hay un error que afecta a la rutina 1 (la de ARTRAG), que hace que cuando se ponen en linea sólo 5 sprites haga cosas raras, de momento si se fuerza a que los 8 sprites estén en linea todas funcionan; aunque queda pendiente la revisión de la rutina 1, claro.
Luego a ver si saco un rato y comento un poco las diferentes rutinas.
En línea

Doom dee doom dee doom
ARTRAG
Visitante
« Respuesta #48 : 18 de Octubre de 2006, 10:08:29 am »

Como comentan ARTRAG y Robsy, hay un error que afecta a la rutina 1 (la de ARTRAG), que hace que cuando se ponen en linea sólo 5 sprites haga cosas raras, de momento si se fuerza a que los 8 sprites estén en linea todas funcionan; aunque queda pendiente la revisión de la rutina 1, claro.

Actually the differences between my approach and the others should appear exactly when you have only few sprites on the same line (like 5).
E.g. with only 5 sprite per line, routine 1) should guarantee a flicker rate of 10 missing frames per second (missing means that the sprite
is NOT displayed in those frames)

A fixed scheme of rotation, with 8 sprites on the screen, should give only a flicker rate of 25 missing frames per second
because the 5h sprite have 50% of prob to fall in a plane lower than the other 4.
En línea
MsxKun
Karoshi Forum's Guru
*******
Mensajes: 1554


Kimochi-ii


WWW Email
« Respuesta #49 : 18 de Octubre de 2006, 02:01:56 pm »

Muy currao, me quedo con la ultima opcion  Grin
En línea

--

Cindy Lauper She Bops!
WYZ
Visitante
« Respuesta #50 : 18 de Octubre de 2006, 02:35:51 pm »

Todos conocemos la regla del 5º sprite, (no es esa que suele hacer el freaky MSXero de comprar 5 o mas botes de sprite, ponerlos en linea horizontal  y pagar solo 4, que si, lo he visto hacer y no ha colado ) lo que me gustaría saber bien es que le ocurre al VDP para que exista esa restricción. ¿Alguien se anima a explicarlo?
En línea
ARTRAG
Visitante
« Respuesta #51 : 18 de Octubre de 2006, 03:03:28 pm »

As far as I know, during the rendering of each line, each
sprite is managed by an independent area in the VDP chip.
The VDP sprite units work in parallel on each rendered line
in oder to compute where the sprites should overlay the background.
As the VDP area costs, reducing the number of sprite units
decreases the overall cost of the chip.
Moreover, less VDP unit you have, less bandwith you need
in the transfer between the VRAM and the VDP during the
screen rendering. This allows the use of slower memory chips

« Última modificación: 18 de Octubre de 2006, 03:22:47 pm por ARTRAG » En línea
WYZ
Visitante
« Respuesta #52 : 19 de Octubre de 2006, 09:17:25 am »

Ok, gracias por la explicación Artrag, pero aun no me queda del todo claro porque el VDP no renderiza el 5º sprite.  Undecided
En línea
ARTRAG
Visitante
« Respuesta #53 : 19 de Octubre de 2006, 09:36:03 am »

There is no sprite unit to process it.
En línea
nerlaska
Karoshi Excellent Member
******
Mensajes: 1102


Programador


WWW Email
« Respuesta #54 : 19 de Octubre de 2006, 10:21:44 am »

basicamente .. la cosa está en que la velocidad del VDP para renderizar un scanline no da para más. Llega para eso .. para renderizar 4 sprites a la vez.
Todo es cuestión de eso. De velocidad.


En línea

MSX4EVER2GETHER
www.nerlaska.com
pentacour
Karoshi Lover
***
Mensajes: 177


mgalious@hotmail.com
WWW Email
« Respuesta #55 : 19 de Octubre de 2006, 10:36:32 am »

Buenas, ahora que tengo un ratillo me vuelvo a dejar caer por aquí (para decir una xorrada), pero es que me ha hecho gracia recordar hayá por los '80 descubriendo los sprites, que quería hacer un suelo para un juego, y me hice mi bucle superchulo para poner 20 sprites en línea. Después de repasar mi bucle una y otra vez para ver porqué solo me salían 4 me dio por leer el manual de basic y vi la explicación. En aquella época pensé: pues vaya restricción más tonta  Huh

Saludos
En línea
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #56 : 19 de Octubre de 2006, 10:42:41 am »

Joe, pentacour!, cuanto tiempo!!  Wink. Re-bienvenido, ya sabes que estás en tu casa Cheesy
En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
jltursan
Karoshi Forum's Guru
*******
Mensajes: 1516


¿Que es lo que has aprendido hoy?


WWW Email
« Respuesta #57 : 19 de Octubre de 2006, 11:57:37 am »

¡ATENCION!, el texto a continuación puede ser extremadamente nocivo para la salud del programador....

Citar
EL reloj maestro utilizado por el VDP es el de la frecuencia de la ráfaga de color * 3. A pesar
de que los resultados obtenidos han tenido como referencia la versión NTSC, para la versión PAL
se obtendrían resultados similares.
La frecuencia de la ráfaga de color 3.579545 MHz, por lo que la frecuencia del reloj maestro es:

Fmaestro =  Frafagacolor * 3
        =  3.579545 MHz * 3
        = 10.7386 MHz

El periodo del reloj maestro viene dado por:

Tmaestro = 1/Fmaestro
        = 1/10.7386 MHz
        = 93.12 ns (nanosegundos)

Cada acceso a memoria emplea 4 unidades del reloj maestro; así pues el tiempo de acceso a la memoria
viene dado por:

Tmem    = Tmaestro * 4
        = 93.12 ns * 4
        = 372.5 ns = 0.3725 us

El tiempo empleado en trazar una linea horizontal, comprendida entre el comienzo de la misma y el comienzo de la siguiente está especificado en el manual del chip como Thorz = 63,695 us. Así, el número total de veces en el que la memoria del VDP puede ser accedida en una linea de barrido horizontal viene dado por:

Mhorz  = Máximo numero de accesos a memoria en una linea horizontal
       = Thorz/Tmem
       = 63.695 us/0.3725 us
       = 171 accesos de memoria por linea horizontal

Ahora ya sabemos cuantos accesos de memoria están disponibles para el refresco de pantalla y los accesos de la CPU conjuntamente.

A continuación, habrá que encontrar cuantos accesos a memoria son necesarios para construir una linea horizontal en los modos gráficos I y II. Todos los accesos que queden libres se supone que pueden ser empleados por la CPU.

Cada linea horizontal está compuesta de hasta seis planos de información gráfica (de menor prioridad a mayor prioridad de visionado):

1. Color de fondo (obtenido del registro #7)
2. Información del patrón y color.
3. Sprites (mínimo = 0, máximo = 4)

Veamos cuantos accesos de memoria se necesitan para obtener los datos necesarios de los tres "planos" descritos arriba.

Primero, el color de fondo no necesita acceder a memoria ya que este valor está contenido en los 4 bits más bajos del registro #7 del VDP.

A continuación viene la información del patrón. Hay 32 carácteres por linea y cada uno de ellos requiere los siguientes accesos para obtener los datos necesarios para generar su patrón de píxeles:


1. Leer el número de caracter de la Tabla de Patrones de Nombres (PNT)
2. Leer el patrón del caracter de la Tabla de Generación de Patrones (PGT)
3. Leer el color de la Tabla de Color de Patrones (PCT)

Como se puede ver, se necesitan tres accesos por cada caracter y por tanto, el número total de accesos requeridos en una linea horizontal para que el plano de caracteres sea construido es de:

Mchar = 32 carácteres/linea horizontal X 3 accesos memoria/caracter
      = 96 accesos memoria por linea horizontal dedicados al plano de patrones

Por último tienen que procesarse los sprites. El 9918A permite hasta cuatro sprites en una linea, siendo el sprite #0 el de mayor prioridad de visionado.

Para determinar que sprite es visible en una linea horizontal dada, la posición Y de los 32 sprites debe de ser leida desde la tabla de atributos de sprite (SAT) en VRAM y comparada con la linea actual de barrido. Durante la comparación, el bit Mag del registro 1 del VDP debe de ser tenido en cuenta, ya que la magnificación es siempre en las dos direcciones.

Si la posición Y del sprite es tal que debería aparecer en esa linea horizontal, entonces el número del sprite (0-31) se almacena en uno de los cuatro registros temporales (SR0-SR3), si aún queda alguno libre. SR0 se utiliza primero y SR3 es el último. SR0 representa el sprite que estará en primer plano y SR3 el sprite que aparecerá bajo todos los demás.
En el peor de los casos (en términos de velocidad), los primeros 28 sprites, 0-27 no serían dibujados en una linea horizontal dada, mientras que los 28-31 si que lo serían. En ese caso, la posición Y de los 32 sprites debería de ser leida (!). Así pues para los cálculos subsiguientes se va a asumir que las posiciones Y de los 32 sprites van a tener que ser leidas. A partir de esto definimos el número de accesos de memoria necesarios para chequear que sprites deben de ser presentados en una linea como:


Msprite_test = 32 accesos a memoria (1 posición Y por sprite)

Tras determinar que sprites deben de ser presentados, los datos de los cuatro sprites (de nuevo, el peor caso) a presentar debe de ser obtenida. Para cada sprite, hay 4 bytes (posición Y, posición X, número de patron y color/EC) que deben de ser leidos de la SAT. Cuando el bit Size del registro 1 del VDP vale 1, indicando sprites de doble tamaño (16x16), dos bytes de patrones deberán de ser leidos desde la tabla de generación de patrones. Una vez más, este es el peor caso. Por lo tanto, se necesitarán seis ciclos de memoria por cada sprite que sea presentado. Así pues, vamos a definir el número máximo de ciclos necesario para obtener los datos de los cuatro sprites en una linea como:

Msprite_data = 4 sprites por linea x 6 accesos a memoria/sprite
             = 24 accesos a memoria

Ahora, recapitulemos el número total de accesos requerido para presentar cuatro sprites por linea y obtendremos lo siguiente:

Msprite = Número total de accesos de memoria por linea por sprite
   = Chequear que sprites estan en esa linea + Accesos a los datos de ese sprite
   = Msprite_test + Msprite_data
        =     32       +     24
        = 56 accesos a memoria

Por fin podemos calcular el número de accesos de memoria empleados para refrescar una linea horizontal de pantalla. Este número viene dado por:

Mdisplay = Mchar + Msprite
         =  96   +   56
         = 152

Ahora vamos a calcular el número de accesos a memoria disponibles para la CPU:

Mcpu  = Accesos a memoria durante una linea horizontal - Accesos a memoria empleados en la presentación
      = Mhorz - Mdisplay
      =  171  -   152
      = 19 Accesos a memoria disponibles para la CPU

Si la CPU puede acceder a la memoria cada 5,95 us, entonces el número total de accesos permitidos por la CPU durante una linea horizontal viene dado por:

Mcpu_horz = Tiempo linea horizontal/Tiempo acceso a memoria
          = 63.695 us/5.95 us
          = 10.7 Accesos a memoria de la CPU por linea horizontal

Si se redondea 10,7 a 11, esto nos daría que hay 8 accesos a memoria (19-11=8) disponibles.

Estos 8 accesos libres podrían haberse usado para presentar un quinto sprite por linea, ya que un sprite emplea un total de siete accesos (1 para el chequeo de Y y 6 más si se presenta). Sin embargo, eso nos dejaría con sólo un acceso libre para la CPU.

Resumiendo, los sprites emplean un poco más de 1/3 del ancho de banda de la presentación. Desafortunadamente, los diseñadores del chip no incluyeron ningún método para desactivar los sprites y así poder conseguir 1 de cada 4 accesos a memoria disponibles para la CPU.

Traducido libremente a partir de este texto, que por cierto, es una lectura muy recomendable Wink
En línea

Doom dee doom dee doom
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #58 : 19 de Octubre de 2006, 12:04:24 pm »

La leche  Shocked, gracias por el trabajo jl  Wink
En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
nerlaska
Karoshi Excellent Member
******
Mensajes: 1102


Programador


WWW Email
« Respuesta #59 : 19 de Octubre de 2006, 02:46:51 pm »

Que alguien les pase ese texto a los del BLUEMSX!!!!
En línea

MSX4EVER2GETHER
www.nerlaska.com
Páginas: 1 2 3 [4] 5 6
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!