NintendojoFR : Le forum

Rayy a écrit :

Aptarus a écrit :Euh une image en frame buffer est non compressée il me semble donc chaque pixel est codé indépendamment. Un filtre ne rajoutant pas des pixels à l'image de sortie, je vois pas l'influence (en non compressé, une image c'est nbr de lignes x nbr de colonnes x log2(nombre de couleurs de la palette), j'ai quand même retenu ça de mon cours de compression d'images...).

(en revanche augmenter la déf OU la palette de couleurs, oui, ça changerait)

Qui plus est, même avec compression (type : jpeg), ça n'empêcherait pas de rajouter des filtres à une image, yaurait des erstazs de compression c'est tout. Un filtre, c'est pas une image supplémentaire.

Ou alors j'ai pas la bonne déf d'un frame buffer.

Ah il me semblait pourtant que des choses comme l'anti aliasing s'appliquaient sur le rendu envoyé dans le frame buffer et que ça faisait augmenter la taille des données dans le frame buffer. C'est pour ça que j'ai parlé de filtre. Mais là tu me mets le doute. :o

Invité a écrit :hum, c'est possible d'avoir des liens vers la fiche technique de la Wii?

GC's ARAM runs at 81MHz and was 16MB in size of type SDRAM.
Wii's ARAM runs at 487.5MHz and is 24 MB in size of type 1T-RAM MoSys.

They essentially moved the GC's ultra fast main memory onboard into the gpu.

The GC's main memory is 24MB of 487.5MHz 1T-RAM.
The Wii's main memory is 64MB of GDDR3, clock speed unknown.

Nintendo has just recently released an SDK that supports OpenGL2.0. The GC's SDK supported OpenGL1.1 and the initial Wii SDK was OpenGL1.2.

Nintendo includes more hardware banging API's in both called the GX libraries. The Original GC TEV was able to Handle 8 Textures thru 16 Stages in a Single Pass thanks to the GPU's internal 3MB cache... Each Stage can apply multiple "Functions" to the Texture - examples of TEV stages would be bump-mapping or cel-shading... By comparison the Xbox "Hardware Shaders" could handle 4 textures and 4 Stages... The advantages of onboard gpu cache were carried over into the Xbox 360's gpu (also made by ATI) in the form of 10MB of embedded memory in MS's 360 gpu.
The enhancements to the Wii are unknown but I would expect a little more of everything, if not doubled. Again these are fully programmable shaders, not pre-packaged hardware shaders. By this nature, most developers never took advantage of it.

The Nintendo GC's cpu improved upon SIMD capabilities over traditional G3-class processors by adding 38 SIMD instructions. These are vector processing commands. The Wii cpu has an addition 50+ commands over the GC chip. What they are for are unknown so far. The GC version removed the 64-bit integer processing unit in your typical G3-class processor and added 2 32-bit processing units hence could process 2 at once at the cost of precision...that was not needed for your typical game. Again, enhancements in the math-processing capabilities of the cpu are unknown, but assumed to be enhanced.

Now that the Wii is a commercial success, a couple of middleware engines are being ported to the Wii to take advantage of these features...FINALLY. One company is even porting the Unreal 3.0 engine for a game. Note: Red Steel was made with the UnReal 2.5 engine.

When looking at the Wii hardware physically, the Hollywood package was also done on a 90nm wafer (as was Broadway and Cell), however, Hollywood is propotionally over twice as big when the die-shrink from 180nm is taken into account when compared to the Flipper of the GC. The DSP inside Hollywood is a Nintendo design and I believe it is there that contains some physics-processing capabilities...

In the end, the Wii is not simply GC x 1.5... In some cases it's GC x 1.5, 2.0, x 3.0. I believe the issue with the backwards compatibility may be due to the extra speed of the ARAM that probably throws the opening animation video out of sync in some way. Factor 5, when they were Nintendo exclusive developers, developed a Divx codec for the GC and has licensed that codec to other developers. It may even be part of the SDK... I assume this codec does not suffer from the compatibility issue of custom video/audio playback that the developers of BMX:XXX employed.

Me_Marcadet a écrit : Je pensais aussi que les filtres comem l'AA et l'AF avait une influence sur le framebufer, mais quandj 'y reflechis c'est peut etre bien une cionnnerie :o

Ca change pas que les screens qu'on a montré sont depourvus de dithering (a cause du 16bits) et sont en hd. Chose impossible a realiser sur wii, meme en optimisant a mort un moteur.

c'est très difficile de trouvé quoi que se soit sur la Wii

keo one a écrit :