cristus escribió:@Señor Ventura el tipo de memoria que usa? o por como tiene el bus?
La wram obliga al resto del pipeline a adaptarse a su frecuencia cuando es usada específicamente.
Posiblemente el dma funcione realmente a 2,68mhz de forma establecida, pero hace años leí que se especulaba que este (es decir, el bus), tenía el ancho de banda que tenía por culpa de tener que adaptarse a la frecuencia que impone la wram, pero es tan fácil como ver a que velocidad transfiere a una sram a 3,58mhz desde el cartucho, y se habría descubierto el pastel.
Editado: parece que se afirma que el dma si funciona a 3,58mhz pudiendo alcanzar casi 9KB por frame, pero que la frecuencia de la wram la mantiene a 2,68mhz, alcanzando sus poco mas de 6KB por frame. Habrá que indagar un poco mas.
cristus escribió:hace poco se estaba hablando que el problema de super era que no alcanzaba a actualizar la vram
Eso dependerá de lo ambicioso que se sea, porque eso no va a ser así en cualquier caso. Con snes se cometían muchos fallos... se underclockeaba la cpu, se utilizaba la página cero para simular comportamientos de otras cpus, se usaba la cpu para descomprimir datos de la rom porque no pocas veces los samples que usaba el spc700 obligaba a necesitar roms mas grandes (y la solución era, como digo, comprimir en lugar de otorgar roms mas amplias)... todo esto lo juntas, y obtienes como resultado una cpu trabajando mas tiempo del que debe.
Cpu y dma comparten bus, y si la cpu está activa demasiado tiempo, le deja menos tiempo al dma. Ahí tienes un motivo real de por qué se necesitaban emplear bandas negras. También influye la propia potencia del procesador, pero no es correcto decir que era un mal procesador, porque si que proporciona una potencia aceptable, el problema es que
era potente, pero sin margen para hacerle esas perrerías sin costarle un handicap.Ahora, cuando hablamos de accesos a la vram, hay que distinguir entre sprites y planos.
La snes tiene la particularidad, por como almacena los tiles en memoria, de manejar diferentes tamaños según su profundidad de color. Como digo, esto afecta a los planos únicamente.
Ya existió un intenso debate sobre la
imposibilidad posibilidad de enviar tiles de 3BPP ahorrando un 25% de tiempo de transferencia con respecto a 4BPP, y además puede enviar tiles de 2BPP necesitando solo el 50% del ancho de banda.
En definitiva, el problema de no alcanzar a actualizar la vram dependerá mucho de lo que hagas, de como lo hagas, y de cuanto quieras actualizar, porque SI tiene un ancho de banda generoso.
cristus escribió:y por eso se recurria a usar franjas negras, o reducir sprites, tambien animaciones. pero no se como han hecho con otros juegos, sin usar chips de apoyo lograron meter sprites grandes, por ahi un juego de rol se entiende porque va todo pausado.
Este ejemplo si desactiva algunas scanlines, pero se puede mejorar el resultado. Si usas planos a 2 o 3BPP, el rendimiento con las animaciones aumenta.
![[rtfm]](/images/smilies/rtfm.gif "Lee!")
