[News] La taille des jeux complets sur eShop

[La Rédaction]

C'est une question importante pour ceux qui ont des cartes SD de 2 Go dans leur console : avec la perspective alléchante d'acheter des jeux sur eShop plutôt que de les commander sur la toile pour les recevoir par la Poste, ou d'aller chez son revendeur, loin en centre-ville, en se payant...

› Lire la suite sur Puissance Nintendo

[ESPERAZA]

c'est la misere!

[Yasuke]

C'est pas un peu faible, vu que la cartouche a une capacité de stockage de 2Go?
Ou bien ça c'est des petits jeux et des jeux genre KH, RE ou MH vont en demander plus?

[-Tetevemasque-]

Quand je pense qu'un jour Myamoto a dit que "NSMB Wii pousse la Wii dans ses derniers retranchements"... à mourir de rire ^^

[Quizzman]

Une fois de plus, prendre la taille d'un jeu pour juger son contenu n'est absolument pas une méthode pertinente. (L'inverse par contre -regarder la taille maximale possible supportée par le système- l'est (puisqu'elle est facteur de limitations), mais c'est une autre histoire).

Faut voir ce qui prend de la place dans un jeu. Souvent, c'est les musiques, les vidéos embarquées, les textures... bref, rarement le jeu lui-même (oui il pèse quelque chose, mais c'est rarement la plus grosse partie de l'ouvrage en terme de place brute).

Qu'un jeu simplissime au niveau de ses textures comme NSMB2 (m'étonnerait même pas qu'il utilise des musiques en Midi en plus) ne pèse que 370Mo ne m'inquiète en aucune mesure sur son contenu (qui peut être bon comme mauvais, je précise, mais ce n'est pas sa taille qui va permettre d'en juger).

Pour rappel, Minecraft ne pèse pas tout à fait 4Mo.

[ESPERAZA]

Oui c'est sur en faisant que 370 il peut etre super beau et se finir en 5h et si la duree de vie etait de 30h il aurai 2G! non? en plus se genre de jeux ne contien pas de videos comme un RE donc c'est normal qu'il prenne moins de place.

[AHL 67]

Oui c'est sur en faisant que 370 il peut etre super beau et se finir en 5h et si la duree de vie etait de 30h il aurai 2G! non?

N'importe quoi. Tu crois sérieusement que la taille d'un niveau de NSMB se compte en Mio ? Apprends la programmation et reviens me dire ça en face.

[Argone]

Nan mais faut arréter de parler de la taille d'un jeu, dans le genre éléments totalement inutile ...

[ESPERAZA]

Il se compte en quoi KB??? je suis pas programmeur. mais quand je fais un album photo, plus j'y mets de photos plus il est gros! la plus il y aurai des niveaux plus ils serai gros! mais bon je peux me trompe c'est clair qu'en programmation j'y connais rien.

[Halouc]

Oui c'est sur en faisant que 370 il peut etre super beau et se finir en 5h et si la duree de vie etait de 30h il aurai 2G!

Non.....

Une map de jeu par exemple n'est qu'un simple fichier. Si chaque map a sa propre musique alors oui le jeu va augmenter de taille, si chaque map a ses propres textures d'herbe alors oui le jeu va augmenter de taille. La taille d'un jeu n'a strictement rien a voir avec la durée de vie, par contre elle peut éclairer sur le degré de finition mais la encore c'est discutable .

Chaque texture d'un jeu est un fichier, si un jeu abuse et abuse d'une texture d'herbe pour faire la pelouse dans chaque map, autant dire que le développeur va faire des économies en terme de place a ce niveau. Par contre le développeur qui veut faire des variantes (pelouse verte, grillé, très grillé), il va utilisé 3 textures et donc augmenté x fois la taille du jeu. Par contre, il faut modéré le nombre de texture car il faut se dire que plus on utilise de texture, plus la ram va être sollicité et plus les différents processeurs auront du boulot.

C'est pareil avec plein d'élément comme la musique. Si tu as une seul musique sur un jeu, ça va prendre moins de place que le jeu qui va mettre une BO complète avec une qualité de son irréprochable.

[ESPERAZA]

ok c'est plus clair comme ca. si chaque niveau de mario utilisait une musique et des endroit different (foret, ville, desert ect) il prendrai beaucoup plus de place.

[Halouc]

ok c'est plus clair comme ca. si chaque niveau de mario utilisait une musique et des endroit different (foret, ville, desert ect) il prendrai beaucoup plus de place.

Oui mais comme je le précise, c'est encore discutable.

Il faut savoir que l'encodage des cinématiques de FF13 sur Xbox360 a été qualifié de "boulot d'amateur" et que le choix du format de compressage est une aberration alors que la console propose nativement. Fin bref, ça démontre que la taille ne veut pas dire aussi boulot de qualité.

The tragedy here is that the CG is a core part of the presentation in FFXIII and it seems to be the case that the company has paid little attention to the poor quality of the final assets on the Xbox 360 version. The Microsoft XDK ships with a VC1 decoder, giving it the ability to playback video files encoded using technology supported by Blu-ray discs and players. Indeed, movie pirates out there get excellent quality VC1 encodes of Blu-ray movies that manage to fit onto a dual-layer DVD and run from the Xbox 360 dashboard.

Decent encoding takes time and effort, but the results can look good - even on challenging material. Combine this with the fact that the game doesn't need the 1080p-sized video the PS3 version boasts, and we have the ways and means with which to attack the compression issue from two different angles.

Square-Enix has bought in the Bink compression system for FFXIII on 360 and its failure in high-motion, colourful scenes does suggest a constant bitrate is being used as opposed to variable bandwidth that allocates more data to maintaining image quality on more complex scenes.

This failure is compounded by the fact that Square-Enix hasn't even made full use of all the disk space it has available. Around 1GB of storage is left empty on discs one and two of FFXIII, and you have to wonder why all that empty space couldn't have been repurposed for higher bandwidth encoding. Perhaps it's because of the background loading taking place while the cut-scenes play out, but regardless, the hit to quality using Bink is often unacceptably bad.

Perhaps Square Enix might like to take some cues from the movie industry: top-tier studios employ compressionists whose sole job it is to make movie encodes look as good as they can possibly be within the confines of the disc space available. The parallel is not without some merit: the same encoding tools Microsoft developed for Blu-ray and HD-DVD movie compression might even be deployed for exactly this kind of thing, assuming that the 360's VC1 decoder is up to scratch.

Failing that, there are any number of h264 decoders out there that could be licensed and ported to the Microsoft console. The bottom line is that if FMV is so crucial to your game, and the storage on offer is limited, care needs to be taken so that every byte of available space makes a difference.

The results in Final Fantasy XIII aren't up to snuff - frankly, the encoding looks amateurish. To give some idea of how this all fares in motion, here's the final comparison video, showing the same scenes from FFXIII running on Xbox 360 and on PS3, in 720p mode

http://www.eurogamer.net/articles/digit ... off?page=3

[AHL 67]

Il se compte en quoi KB??? je suis pas programmeur. mais quand je fais un album photo, plus j'y mets de photos plus il est gros! la plus il y aurai des niveaux plus ils serai gros! mais bon je peux me trompe c'est clair qu'en programmation j'y connais rien.

Exemple : tu veux placer dix dans un niveau. Le bloc, pour être placé, y a pas besoin de créer une image à chaque fois, tu en crées une et basta, les autres ce seront toujours les mêmes. Donc pour placer tes dix blocs tu n'auras besoin que de 3 informations propres à chacun : un code indiquant que ce sont des blocs, et les 2 coordonnées au sein du niveau (éventuellement une 3ème coordonnée pour la profondeur s'ils s'amusent à nous faire des niveaux à la DKC Returns). Ça nous fait donc 3 nombres généralement codés sur 4 octets (si aucune optimisation n'est faite à ce niveau, car c'est possible), donc 120 octets pour les 10 blocs.
Un niveau complet de NSMB ça doit faire quelques milliers de "blocs" de ce genre ( mais aussi sol, ennemis, décors... tout peut être considéré comme "bloc", encore une fois sans compter les optimisations), donc quelques dizaines de kio à tout casser. Même en ajoutant une musique propre à chaque niveau qui boucle sur 10min, comme c'est sans aucun doute du MIDI (le MIDI c'est cool), ça ne fera pas plus de 200 kio de plus par niveau.

Ce qui prend certainement beaucoup de place par contre ce sont les modèles et leurs textures : je rappelle que, malgré le scrolling horizontal, à peu près tout est en 3D ! Et dans pas mal de jeux les petits bruitages ne sont généralement pas compressés, car trop sollicités pour demander au processeur de supporter autant de décompressions.

[Quizzman]

Ouais enfin ça reste des modèles super simples. Même si on est sur 3DS, les polygones sont pas bien compliqués.

[ESPERAZA]

et la resolution du jeu peut faire varier les MB? ex le jeu prendra autant de place sur 3DS et sur WII U?