[quote="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.[/quote]
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é. [spoiler]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
[quote="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.[/quote]
Exemple : tu veux placer dix :qblock: 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 ( :qblock: 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.
[quote="ESPERAZA"]et la resolution du jeu peut faire varier les MB? ex le jeu prendra autant de place sur 3DS et sur WII U?[/quote]
Indirectement. La résolution en elle même ne change rien, ce qui va changer c'est les modèles (qui sont forcément plus complexes) et les textures, principalement. Après ptet que certains effets devront être plus poussés (comme l'antialiasing), mais ça va jouer sur les performances, pas sur la taille même du fichier.
Après dans la pratique, ça fait pas forcément une différence monumentale, surtout pour un jeu ultra minimaliste comme New Super Mario Bros. Pour exemple, la version Wii fait 377Mo. Et la version DS, 32Mo (mais là, c'était vraiment des modèles hyper simples).
De 32Mo ils sont quand meme passe a 370Mo. si c'est proportionnel on aura du 4G pour la version WII U. pourquoi les PS1, PS2 et PS3 ont tant de problemes d'antiaiasing? a cause du trop peu de memoire quelles contiennent?
[quote="-Tetevemasque-"]Quand je pense qu'un jour Myamoto a dit que "NSMB Wii pousse la Wii dans ses derniers retranchements"... à mourir de rire ^^[/quote]
Lol, j'avais jamais lu cela je crois. Il a bien rie de nous. Ce jeu n'utilise même pas 10% de la capacité de la console.
Et ces tailles, n'empêche, me font rire. 377 Mio, même si ça représente pas la durée de vie, on voit qu'ils changent pas grand chose dans leurs travaux du jeu comparé au dernier NSMB.
DKCR, prenait 3, x go, je ne sais plus. Mais ce jeu est beau, bien réalisé, avec quelques cinématiques, etc. Bref, il y a une différence avec le strict minimum des NSMB.
32 MO pour le premier O_O. Ouff, sur une capacité de 1 go pour la DS je crois ? ... Ils exagèrent. Ils font vraiment le minimum. Dire qu'à l'époque NES, ils boostaits certaines cartouches de jeux parce qu'ils voulaient rentrer plus de choses. Maintenant, ils boostent les capacités de stockage, mais font des jeux qui utilisent quasiment rien de cela...
Oui enfin attention, les 32 Mo c'est non compressé (l'équivalent au 4,7Go d'un DVD par exemple). Il existe différentes tailles de mémoire pour les cartouches DS, 32Mo en est une.
Après personne ne s'amuse à compresser des jeux DS vu que leur taille est déjà adaptée à leur support. Probablement qu'on pourrait gagner quelques Mo mais pas grand chose de significatif.
Pour l'anti-aliasing, il existe plusieurs méthodes (FXAA, MLAA, MSAA, ...). Certaines sont plus efficaces et/ou moins coûteuses en ressources que d'autres, mais toutes sont liées à la puissance de la machine.
Sur PS1 c'est facile, il n'y en a pratiquement pas. Sur PS2 si je dis pas de bêtises c'est assez rare (la résolution ne le demande pas. En fait la plupart des jeux "deviennent" moches quand on y joue sur des écrans récents parce que la résolution n'est pas adaptée). La PS3 n'a pas trop de problèmes d'aliasing, pas plus que la 360 en tout cas (à part peut-être sur quelques jeux à droite à gauche). Alors certes, tu obtiens un bien meilleur AA sur les PC, mais eh, c'est parce que les PC d'aujourd'hui sont bien plus puissant que les gens actuelles de consoles.
[quote="Jyvékas"]Et ces tailles, n'empêche, me font rire. 377 Mio, même si ça représente pas la durée de vie, on voit qu'ils changent pas grand chose dans leurs travaux du jeu comparé au dernier NSMB.[/quote]
De nouveau, la taille ne veut rien dire, ni sur la durée de vie, ni sur le travail effectué par derrière. Tu peux avoir 4Go de code de merde et 100Mo de très bon code pour faire la même chose. D'ailleurs, généralement (même si pas systématiquement), en informatique, de deux codes pour faire la même chose, c'est le plus petit qui est à privilégier (bon en fait le plus rapide. Mais c'est souvent le plus petit puisqu'il y a moins à lire).
Dans le cas présent, compte tenu du contenu du jeu, je trouve même plutôt ça pas mal de faire ternir ça dans 370Mo. 4Go auraient été beaucoup plus étonnant, voir inquétants vis-à-vis de l'optimisation du contenu.
Après, probablement que le jeu fait à peu près la même taille parce qu'il réutilise le moteur de NSBMW pratiquement à l'identique. Et donc, les ressources utilisées sont les mêmes, la seule chose qui change est le code lui-même du jeu (les niveaux et power-ups en gros).
Si avec la puissance de la WII on avait des cartouche de 384MO et 512 MO comme sur N64 on aurai les meme graphisme? les temps de chargement seraient reduits?