garbagecrystal escribió:darksch escribió:garbagecrystal escribió:@darksch 10 Gb no son por llevar un binario extra
En un empacado de estos perfectamente no es el clásico EXE a pelo. Van otros metadatos y puede que algún asset para que los use la plataforma específica.
10GB no son nada sobre 116 si hablamos de compresión, vamos que no lo lleva.
Esto no funciona así, el binario que tú dices es el programa que ejecuta la consola, el resto son assets. Los assets específicos se instalan o no según la máquina en la que esté el juego.
No hay ningún motivo por el cual poder ejecutar el binario en una One o en una OneX conlleve 10 GB. La diferencia es en cantidad o tamaño de assets, compresión y si hay o no repetición de assets por motivos de velocidad de carga.
Si FH5 ocupa lo que sea en Xbox Series es lo que hay. Comprimir han comprimido hasta donde no han podido hacerlo.
Supongo que lo que algunos esperan de la compresión de texturas es que de golpe todo baje un 10, 25, 50% de tamaño. Pero no es así, aunque el formato teóricamente lo permita. Porque esos formatos luego tienen que acabar en VRAM en un formato legible por la GPU, así que hay que descomprimirlos. Y al descomprimirlos te comes ese ancho de banda, y aún no has empezado a leer la textura.
Me parece lógico que en un juego que depende mucho de hacer stream de datos entre I/O y VRAM (y que además luego accede obviamente a esos datos en VRAM) no puedas depender de grandes tareas de descompresión en términos de ancho de banda, por lo que hay que encontrar un equilibrio.
Otra cosa es que me digas un juego que va mapa por mapa, ahí aún, porque en el momento de cargar el mapa puedes hacer ese trabajo.
Así que sí, cuenta que el juego está comprimido, tanto como se puede comprimir. Que mañana pueden optimizar un poco más y podar algún GB? No te digo que no, pero dudo mucho que esto ocupe lo que ocupa por no querer hacer "un pase de BCPack" en el pipeline de los assets.