[Ejercicio técnico] Trasteando con un debugger

Buenas...

Pues no es que sea muy experimetado con los debuggers, pero estoy dedicándome a echar un vistazo al uso de la vram en los juegos para saber cuanto espacio quedaba libre en aquellos que parecían ir al límite por como comprimían gráficos (calidad de los escenarios del art of fighitng 2), o por como dejaban de pequeños el tamaño de los personajes (samurai showdown).

La cuestión es que aunque estoy dando con programas bastante completos, los cálculos hay que hacerlos muy a ojo. ¿No hay ninguno que te indique cuanta memoria se usa en el momento? (video ram, ram, ram del spc, etc).

Aún con todo, me estoy llevando una pequeña sorpresa con un par de ellos:



Art of Fighting 2.
He escogido a dos de los personajes mas grandes (mr big y jack), que además coincide en que el escenario del segundo es uno de los que menos repetición de tiles tiene (por lo que tiende a ocupar mas vram).



Lo que me estoy dando cuenta, es que calculando, queda libre sobre un 20% de la vram, y eso sin contar las direcciones de memoria sueltas entre bloques de datos, que siempre computan, pero que a ojo no se aprecian tanto.
¿Que significa esto?, pues que quedaba espacio de sobra para "malgastar" tiles en los escenarios para que lucieran mas como el original... o limitarse a mejorar los escenarios de forma notable, y hacer los personajes bastante mas grandes, o no tocar el tamaño y proporcionarles bastantes frames de animación.
Según veo (y sin que mi juicio sea verdadero), diría que unos escenarios bien recreados, con unos personajes un poco mas grandes, y haciendo que el zoom-out llegue un poco mas lejos (para que se note bien el efecto entre zoom-in y zoom-out), hubiera sido perfectamente posible.


Street Fighter Alpha 2
En este la intención ha sido la misma, coger a los dos personajes mas grandes, con un escenario que interpreto que es bastante generoso con la no repetición de tiles, y analizar la escena en un momento muy puntual, a ver como está todo.



Según la imagen, lo que da a pensar es que el uso de la vram tiene que tener una optimización brutísima, para que con esa profundidad de color, esos escenarios, y esas animaciones, pueda verse todo así de grande.
...pues nada mas lejos de la realidad. He contado 4 bloques bastante gordos de espacio sin usar, y de hecho veo que optimización poca, porque hay muchas direcciones de memoria sueltas entre bloques de datos que están por ahí desperdiciadas.
Calculando a ojo, diría que en torno al 16/20% de la vram está sin usar, y no creo equivocarme mucho. Vamos, que si se ponen tontos podrían haber mejorado las animaciones... y si alguien no confía en el DMA para transportarlos a tiempo, siempre puedes dejar ahí las animaciones del escenario, cosa que siempre resulta vistosa, y le añade complejidad al asunto gráfico.

Vamos, que menuda sorpresa me he llevado con esto.


Samurai Showdown
Lo mismo que los anteriores. He escogido a cham-cham y earthquake, y ha salido el escenario de este último, que además creo que es uno de los escenarios con msa profundidad de color, y que exije menos repetición de tiles debido a su estilo "pseudo-fotografía".



Con este me he llevado un pequeño chasco. A ojo, calculo que en en la escena de la foto queda libre en torno a un 10% de la memoria... pero es que me estoy dando cuenta de que la gestión de la memoria en este juego es muy anárquica. Cuento muchos minibloques vacios ahí camuflados entre cadenas y cadenas de datos.
Diría que un 10%, pero seguramente sea un poco mas. El caso es que si se pretende aumentar el tamaño de los luchadores, tal vez un haohmaru podría tener un tamaño como el de la recreativa, y todo con esas animaciones, sin que falte un solo golpe o movimiento, y con esa calidad de escenarios... pero un earthquake lo veo jodido. Todo depende de cuanta memoria se esten llevando los escenarios, porque con un 10/15% del total de la memoria, en el caso de que los personajes estén ocupando actualmente tal vez un 10 o un 12%, tal vez si se podría hacer algo intermedio (no tan grandes como en el original, o como en la megaCD, pero si de un tamaño parecido al de megadrive, y con un earthquake bastante gigante).

Me la voy a jugar. Creo que la lacra de la versión megadrive está en el cartucho, y que no incluyeron a earthquake para no meter memorias mas grandes, no porque la vram no diese para mas (si alguien puede echarle un vistazo, a ver que ve, tal vez nos saque de dudas).


Fatal Fury Special
Mismo procedimiento. Pillo por un lado a axel hawk, y por el otro a big bear, con un escenario que no es que esté muy comprimido, pero que tampoco es que sea una maravilla del grafismo.



Aquí directamente me encuentro bastante confundido. Encuentro menos espacio libre del que esperaba, seguramente mas de un 5%, pero en el sentido de que tal vez esté bastante cerca del 10% de memoria libre sin usar. Lo que ocurre es que detecto un comportamiento un poco extraño, como si hubiera espacio ocupado, aunque sin datos, ¿como si estuviese reservado? (como los dummies en las grabaciones de cd's), ¿es eso posible?.
Algo de espacio hay para mejorar cosas, sobre todo animaciones... y hombre teniendo en cuenta que big bear no es precisamente pequeño, creo que al menos las animaciones de los personajes menos grandes si podría haber sido mucho mas rica.
De todos modos, estoy seguro de que aquí hay gato encerrado, y se puede hacer mas de lo que parece, sobre todo teniendo en cuenta los ejemplos de los títulos anteriores, porque este fatal fury special no tiene nada que no tengan los otros.




Lo dejo aquí con estos 4 ejemplos, porque de científico esto no tiene nada hasta no dar con una herramienta que hable mas claro, y diga con cifras que es lo que está pasango. Analizar una vram de muchos cientos de pantallazos no es algo para ir haciendo a ojo, ni mucho menos.

A ver si al menos el hilo da para recopilar información sobre debuggers, y herramientas varias.