gynion escribió:@Señor Ventura 10 jugadores tan mastodónticos de baloncesto en un brawler... se me antoja imposible, ni en SNES ni en ninguna de otra consola de la época.
Da igual si es un brawler, o cualquier otro género. Poner personajes grandes depende de la tabla OAM, y del fill rate por scanline. No por ser un beat em up un juego va a quedar por debajo de esos límites.
Y no porque un juego sea un brawler las IA's de los objetos son mas complejas. Insisto en el ejemplo del hack del TMNT hyperstone heist, en cuya versión comercial siempre vimos 4 enemigos simultáneos, y luego resulta que la cpu andaba ociosa, porque realmente podían ponerse camino de 15 enemigos.
Por último, hay que mentalizarse de una vez que el tamaño de un objeto no incide en el cálculo de su IA. 10 objetos de gran tamaño es exactamente igual que 10 objetos de pequeño tamaño, ese detalle no depende de la lógica de una cpu.
gynion escribió:En este juego será posible porque sus características así lo permitirán
De todas formas, en los juegos deportivos de equipos es lo que suele tocar, que haya muchos sprites; muchos es cierto que usaran "truquillos", como en fútbol hacer que las lineas se mantengan en su puesto, para que no se concentren los 21 jugadores simultáneamente en pantalla. Pero vamos, algunos otros juegos deportivos de la época habrá con acumulación destacable de jugadores.
En los scanlines de toda la franja roja, coinciden en línea todos los sprites que conforman todos los personajes de la pantalla.
Un brawler tiene las características que se ven en esa imagen... pero da mas de si. En esta otra coinciden 8 simultánemante en su tamaño máximo en bastants scanlines (y por lo tanto, podría suceder en todos ellos sin ningún problema), luego lo comparamos con los parpadeos del king of the dragons, con su mini tamaño, a partir del 6º personaje en pantalla, y queda claro que eso ocurre porque no se optimiza.
Y digo mas, incluso así no rebasa los límites por scanline, podría perfectamente mostrar otro personaje mas en pantalla, pero tendría que ser la mitad de delgado, poque si no salta el bug del generador de imágenes... 272 pixels exactos.
Con esto queda demostrado que el fill rate, y los límites con el dibujado de sprites, permiten
gráficamente una situación así en cualquier juego, y por lo tanto el mito de que snes no puede mostrar mas de 4 personajes en pantalla queda desmitificado.
Y en otro orden de cosas, como ya se ha comentado anteriormente con el ejemplo del mismo hyperstone heist, no hay por qué presuponer que 8/10 enemigos en pantalla en snes puedan ser demasiados.
-----------------------------------------------------------------------------------------------------------------------------------------
Bien, pasemos a cosas mas serias...
Las gradas del juego y la cancha son el mismo plano, es por esto que los tiles de "ambos planos" pueden ser escalados. Sin embargo ocurre algo muy curioso, solamente los tiles pertenecientes al dibujo de la cancha alteran su perspectiva.
Según el debugger el mismo plano ocupa dos backgrounds. En modo 7 tienes un plano de hasta 256 colores, y otro de hasta 16. En este caso el mismo plano es dibujado en ambos, y debe presuponerse que el segundo plano "bloquea" el area de pantalla perteneciente a las gradas, provocando que solo la cancha altere la perspectiva, pero permitiendo scaling globalmente. De primeras no le encuentro mucho sentido, pero tomo nota.
Mas cosas, el hecho de que los personajes sean todos iguales no se debe a tratar de usar el menor ancho de banda posible, puesto que los frames de animación de cada uno han de transferirse igual, ya que el anterior siempre será borrado... la cuestión sería saber cuánto se está transfiriendo.
Un tile de 16 colores ocupa en memoria 32 bytes, y el patrón de un personaje en su tamaño máximo ocupa 33 tiles, siendo animados en cada frame 32, ya que la cabeza siempre permanece igual, y no necesita actualizarse.
Son 32 tiles x 32 Bytes, que hacen una cantidad exacta de 1024 Bytes, es decir, 1KB para cada frame de animación. Algo debo estar pasando por alto, porque los 8 personajes de tamaño máximo de la segunda foto, estarían demandando 8KB por cada frame, y el límite por cada 1/60 es de 5,72KB... cada muñeco tiene una animación de unos 6 frames por segundo (6/60), pero, ¿que ocurre si cada uno de los 8 jugadores demandan un frame diferente al mismo tiempo?, solamente 2 estarían compartiendo los mismos tiles, y por lo tanto en 6 frames concretos de 60 que dura un segundo, le estarían pidiendo al bus de datos 7KB de datos cuando su límite no llega a 6. Será que son casi las 4 de la mañana, y no puedo ni pensar, pero no le encuentro sentido.
Luego están las animaciones de las gradas, y con el dibujo tan simplificado que tienen la memoria necesaria es prácticamente residual, aunque no haría ni falta servirse del ancho de banda del bus de datos para poner mas frames de animación (o un dibujado mas complejo), ya que se podría usar la memoria RAM principal como caché para transferir las tiles del plano que sean necesarios para animarlo, y así dedicar todo el ancho de banda únicamente a los sprites.
Sea como sea, con 64KB de tiles, o incluso 96 almacenados en la WRAM, habría de sobra para actualizar las animaciones de unas gradas bien detalladas, en vez de unas tan simplificadas y repetitivas como las del juego.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
).