Juegos e, muy facil

Monster Hunter 3

Cursed Mountain

Dead Space Extractio(maravilosas físicas)

Resident Evil DarkSoide Chronicles

Silent Hill Shatered Memories

etc..

Muchos de ellos aparte de los gráficos soportan HDR+AA, algo solo posible a partir de las x1000 de ATI, y tambien despliegan muy buenas físicas gracias al uso de Havok por ejemplo, tan buenas que de seguro usan Havok FX y no el Havok Hydracore.

La unica razon por la que los juegos con buenos gráficos se han visto algo rezagados con respecto a la velocidad con que empezaron a salir en 360 y ps3 es simplemente porque esas concolas tienen cpus multicore muy poderosos a diferencia de Wii, lo que simplifica el trabajo, y en Wii se tiene que usar programacion GPGPU como opencl o cuda para usar el Hollywood para proposito general, lo que no es tan simple como suena y es costoso usarlo de esa forma; sin embargo, los tiempos estan cambiando y ahora la programacion GPGPU es mas sencilla que antes, habitual y su costo se esta reduciendo.

Con la programacion GPGPU puedes obtener rendimientos muy altos, de entre 100 y 250 veces mas performance que un simple cpu de un solo nucleo pero poderoso. Claro que eso depende de la calidad de la programacion, por lo que si progrman de forma simple, obtendran rendimientos de solo 2 o 5x.

 Con respecto a que lo del tema grafico en wii ha llegado algo tarde, si te refieres a que saldra una nueva wii o algo asi, de hecho es too lo contrario pues de acuerdo con el presidente de nintendo, el hardware de Wii aún tiene mucho que dar y tendran que pasar 3, 5 o hasta 8 años a partir de ahora(2009)para que ya no exista forma de exprimir su hardware mas haya de lo que ya ha sido exprimido

http://www.guias-trucos-juegos.com/noticias/satoru-iwata-no-cree-en-wii-hd-a-corto-plazo-3473/

"

La clave, como ya ha especificado en otras declaraciones, es que los desarrolladores se sientan cómodos con el hardware actual y con suficientes ideas para explotarlo. Sólo cuando estas ideas empiezen a flojear se contemplará la creación de uno nuevo, mientras tanto podemos tener Wii para rato:

“Mientras los desarrolladores sigan sintiéndose a gusto con la habilidad que tiene la tecnología actual para seguir desarrollando productos sorpresivos para los usuarios no necesitamos hardware nuevo. Si un día ellos empiezan a demandar algo nuevo porque el hardware no puede satisfacer sus necesidades, entonces es cuando decidiremos lanzar una nueva consola. Quizá dentro de tres años, cinco o puede que ocho”.

"

 Tampoco hay que olvidar el hecho de que CAPCOM antes dijo que una version de RES 5 en Wii no iba a ser posible pues este no podia ni correr la pantalla de presentacion, luego sale el Dark Side Chronicles por Cavia y el director de RES 5 ahora creeque si es posible dado a los gráficos y las iluminaciones que se emplearon en este ultimo. Claro esta que cuando hicieron el comentario de que Wii no podia con RES 5 lo hacía sin usar las herramientas adecuadas o engine inadecuado, si hubiera empleado el Gamebryo LighSpeed y probado el Floodgate de este sus comentarios hubieran sideo distintos en aquel entonces; tampoco hay que olvidar que poco despues de que el director de RES 5 dijera que si considera ahora posible RES 5 en Wii, capcom menciono que llevaria su MT Framework a Wii.

Las ventajas de usar software gpgpu(solo posible a partir de las aTI radeon x1000(R520 o R580)) es el que puedes realizar los calculos aritmeticos y flotantes en el GPU en lugar de hacerlo en el cpu, lo que sería usar el gpu como un coprocesador matematico muy poderoso. La ventaja de esto es que se podrían usar técnicas como el vertex displacement mapping, pues el displacement mapping requiere de altos calculos flotantes, tanto asi que hasta un cpu de ultima generacion del 2005 tendría problemas, sin mencionar que el costo en bandwidth sería muy costoso tambien. Pero si esos calculos necesarios para el displcement mapping se llevan a cabo en el GPU, se le quita trabajo al cpu y se ahorra bandwidth. Solo lean bien las patentes de displacement mapping de nintendo(tienen validez hasta el 2020) y se daran cuenta.

De nuevo, usar el Hollywood para proposito general implica mayor dificultad de programacion y mayor costo, es por eso que apenas ahora vemos avances significativos en wii en cuanto a cuestion grafica.

Aproposito, no es necesario que la placa de Hollywood diga GPGPU para entender que el Hollywood puede ser usado para proposito general, ya que hasta las ati y nvidia de hoy se les sigue llamando gpus a pesar de ser creadas para ser usadas para proposito general tambien.

Cuando digo que el Hollywood tiene un GPGPU, me refiero a un GPu capaz de proposito general. casi todo mundo usa GPGPU para referirse al software y no al hardware y siguen llamando, erroneamente a mi laudo, GPUs a las tarjetas graficas capaces de proposito general.

Todos sabemos que ati dijo que solo habiamos visto la punta del iceberg en Wii en el pasado E32006 donde vimos el smash y el mario. Cuando se le preguntaron detalles tecnicos o los quizo dar y solo dijo que no consideraba justo compara directamente el Hollywood con el Xenos pues eran chips distintos para propositos distintos.

Si lo piensan bien, el tema sobre GPGPu es la respuesta a lo que se referia ATI y de como se puede llevar a cabo el displacement mapping d forma eficiente. Tambien me llevo a analizar mas detalladamente una de las patentes de displacement mapping y descubri que nintendo planeaba usar en el futuro el vertex displacement mapping pues menciona algo sobre vertex cache y vertex texture fetching, lo que fue incluido en las ATI HD 2000 series como la 2900 para el evrtex displacement.

Patent Storm
http://www.patentstorm.us/patents/6980218/fulltext.html

"
US Patent 6980218 - Method and apparatus for efficient generation of texture coordinate displacements for implementing emboss-style bump mapping in a graphics rendering system

US Patent Issued on December 27, 2005
Estimated Patent Expiration Date: November 28, 2020
Estimated Expiration Date is calculated based on simple USPTO term provisions. It does not account for terminal disclaimers, term adjustments, failure to pay maintenance fees, or other factors which might affect the term of a patent.

Command processor 200 receives display commands from main processor 110 and parses them—obtaining any additional data necessary to process them from shared memory 112. The command processor 200 provides a stream of vertex commands to graphics pipeline 180 for 2D and/or 3D processing and rendering. Graphics pipeline 180 generates images based on these commands. The resulting image information may be transferred to main memory 112 for access by display controller/video interface unit 164—which displays the frame buffer output of pipeline 180 on display 56.

FIG. 5 is a logical flow diagram of graphics processor 154. Main processor 110 may store graphics command streams 210, display lists 212 and vertex arrays 214 in main memory 112, and pass pointers to command processor 200 via bus interface 150. The main processor 110 stores graphics commands in one or more graphics first-in-first-out (FIFO) buffers 210 it allocates in main memory 110. The command processor 200 fetches: command streams from main memory 112 via an on-chip FIFO memory buffer 216 that receives and buffers the graphics commands for synchronization/flow control and load balancing, display lists 212 from main memory 112 via an on-chip call FIFO memory buffer 218, and vertex attributes from the command stream and/or from vertex arrays 214 in main memory 112 via a vertex cache 220.

Command processor 200 performs command processing operations 200a that convert attribute types to floating point format, and pass the resulting complete vertex polygon data to graphics pipeline 180 for rendering/rasterization. A programmable memory arbitration circuitry 130 (see FIG. 4) arbitrates access to shared main memory 112 between graphics pipeline 180, command processor 200 and display controller/video interface unit 164.

FIG. 4 shows that graphics pipeline 180 may include: a transform unit 300, a setup/rasterizer 400, a texture unit 500, a texture environment unit 600, and a pixel engine 700.

Transform unit 300 performs a variety of 2D and 3D transform and other operations 300a (see FIG. 5). Transform unit 300 may include one or more matrix memories 300b for storing matrices used in transformation processing 300a. Transform unit 300 transforms incoming geometry per vertex from object space to screen space; and transforms incoming texture coordinates and computes projective texture coordinates (300c). Transform unit 300 may also perform polygon clipping/culling (300d). Lighting processing 300e also performed by transform unit 300b provides per vertex lighting computations for up to eight independent lights in one example embodiment. As discussed herein in greater detail, Transform unit 300 also performs texture coordinate generation (300c) for emboss-style bump mapping effects.

Setup/rasterizer 400 includes a setup unit which receives vertex data from transform unit 300 and sends triangle setup information to one or more rasterizer units (400b) performing edge rasterization, texture coordinate rasterization and color rasterization.

Texture unit 500 (which may include an on-chip texture memory (TMEM) 502) performs various tasks related to texturing including for example: retrieving textures 504 from main memory 112, texture processing (500a) including, for example, multi-texture handling, post-cache texture decompression, texture filtering, embossing, shadows and lighting through the use of projective textures, and BLIT with alpha transparency and depth, bump map processing for computing texture coordinate displacements for bump mapping, pseudo texture and texture tiling effects (500b), and indirect texture processing (500c).
"