Sexy MotherFucker escribió:En la descripción que va haciendo en el vídeo dice "This trick is achieved with masking sprites".
Ajá, pero... ¿qué es exactamente eso? No puedes quitar de un plumazo un trozo del sprite aunque sea 8x8 porque se notaría y tendrías que estar detectando colisiones por sub-sprite y no por sprite. Enmascararlo con el enventanado solo conseguiría formas irregulares, como el contorno del baúl, si se hace por HDMA (es posible) pero tendría que estar calculada la forma irregular para cada elemento que tape a un sprite, y eso podría ser factible, pero es un trabajo de locos: para cada escenario tendría pre-calculado qué cosas tapan y tendría un HDMA enmascarando esa porción y que iría cambiando en cada frame según el baúl se fuera desplazando por la pantalla con el scroll.
Señor Ventura escribió:El juego incluye un marcador que mide el uso de la cpu, y esta siempre por encima del 70%, asi que todo cuadra.
Bueno, no sé qué cuadra exactamenete... el uso de CPU está muy alto en otros juegos también y eso tampoco explica cómo se hacen los efectos.
Señor Ventura escribió:Sobre el streaming de tiles a 256 colores, vale que pesan 64 bytes, pero para un scroll multi direcconal, el DMA cumple de sobra a no ser que quieras hacer un sonic a toda pastilla, y mas aun cuando los sprites seguramente estén instalados en la vram, y no dependan de actualizar tiles al vuelo (de hecho sus animaciones son limitadas, y caben de sobra).
No es un streaming de tiles, creo que eso ya te lo he comentado cientos de veces: las tiles se transfieren 1 sola vez, todas del tirón a VRAM cuando se cambia de escena. El scroll se hace cambiando el tilemap, que son unos cuantos bytes por frame,
Las animaciones de los sprites no se suelen meter todas en VRAM porque entonces para animar al personaje tendrías que estar cambiando el TileNumber cada frame; si las animaciones fueran muy básicas sí se podría hacer (aunque no he visto ningún juego que lo haga), pero en este caso precisamente son demasiado complejas para que residan en VRAM. Los sprites sí se suelen enviar a VRAM en cada frame según cada postura de aninmación, y para ahorrar ancho de banda (qué aquí sí podría ser crítico si actualizas demasiados), la postura de animación se suelen actualizar cada x frames, es decir, que se mantiene al personaje en una postura de la animación 2~3 frames y luego se actualiza a la nueva postura; en ese lapso de 2~3 frames se aprovecha para actualizar otros sprites.
Señor Ventura escribió:Editado: ¿En snes un tile de 16x8 pixeles a 16 colores en el modo hi-res también ocupa 64 bytes?.
Pues depende de cómo lo mires; efectivamente el tile 16x8 4BPP ocupará 64 bytes para el campo par, pero para duplicar la resolución vertical tendrás que tener otra tile igual en otro lado de VRAM que será la que se use cuando se dibuje el campo impar. Porque si solo usas la misma tile para los dos campos tendrías un modo pseudo-hires, ya que no estarías duplicando realmente el número de líneas de pantalla, sino haciendo que la SNES saque por la señal de video 2 campos entrelazados partiendo del mismo frame.
Si el modo HiRes es en horizontal, los píxeles pares se obtienen de la sub-screen y los impares de la main-screen, por lo que igual que antes, tendrías 2 tiles 16x8 4BPP, una con los píxeles pares y otra con los impares.
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[rtfm]](/images/smilies/rtfm.gif "Lee!")
![[hallow]](/images/smilies/nuevos/hallowen.gif "calabaza")
