El mentidero - NO POSTEAR

Hilo de recopilación de datos de interés, artículos y documetos de difícil acceso, entrevistas con información de primera mano, etc. La intención es acotar los datos para su verificación.


1). ¿Realmente admite la gamecube compresión de texturas?
2). ¿Tiene la gamecube un motor de geometría y transformación de vértices por hardware?
3). ¿Cuales son las estimaciones de potencia teórica que podría alcanzar una gamecube según datos contrastados?
4). ¿Es posible Doom 3 en una gamecube?
5). ¿Es posible el chronicles of riddick en una gamecube?
6). ¿Tenía algún tipo de ventaja la gamecube sobre la xbox al poseer un pipeline gráfico mas corto?
7). En relación a esto, se ha mencionado un e-mail que pone de manifiesto las diferencias de rendimiento entre el rogue squadron de la gamecube y una supuesta demo para xbox que hipotéticamente existió y que corría a 12fps, ¿realmente existe ese dato?
8). ¿Existe algún tipo de librería oficial que ofrezca una documentación técnica extensiva del hardware de la consola?
9). ¿XBOX era mas potente que gamecube?
10). ¿Cual es la diferencia entre los pixel shaders del NV2A de la XBOX y el TEV del Flipper de la Gamecube?.
11). ¿Cuales son las coincidencias entre los pixel shaders del NV2A de la XBOX y el TEV del Flipper de la Gamecube?.
12). ¿Le da ventaja a la gamecube la mayor velocidad y menor latencia de sus memorias para un mayor aprovechamiento de su ancho de banda?.
13). ¿Es cierto el dato de que la Gamecube puede texturizar 8 veces un polígono dentro de un mismo paso?
14). ¿Tiene la Gamecube hardware dedicado para sacar imágenes 3D estereoscópicas?
15). ¿Existió una trilogía de los tres primeros Rogue Squadron en Wii?





-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



1). ¿REALMENTE ADMITE LA GAMECUBE COMPRESIÓN DE TEXTURAS?.

Fuente oficial (nintendo):
https://www.nintendo.co.uk/Support/Nint ... 19165.html

Enlaces adicionales sobre sus especificaciones (todas coinciden en la implementación de la descompresión de texturas por hardware):
http://www.gamecubicle.com/system-gamecube-specs.htm
http://www.gnn.ch/videogames/Nintendo/g ... ndex.shtml
https://www.gamespot.com/articles/ninte ... 0-2619269/
http://www.eurasia.nu/mirrors/www.segat ... /overview/


Full text of “Nintendo Gamecube SDK documentation S3TC”:
https://archive.org/stream/GCN_SDK_Docu ... n_djvu.txt


¿Y por qué la descomprensión de texturas S3TC, siendo parte de los directX, y careciendo la gamecube de ese estándar, forma parte de las funciones por hardware de su GPU?.
S3 graphics ltd fué una compañía que entro en el mercado del hardware de pc con una tarjeta gráfica, la S3 savage 3D, y esta incluía en su funciones la descompresión de texturas (enlace adicional), que mas tarde acabaría convirtiéndose en un estándar, incluyéndose como parte de los direct X 6 gracias a que puede ser adquirida su licencia, que es justo lo que hizo también Nintendo, y que recientemente, en el 2014, volvió a renovar con la compañía propietaria.

Nintendo renueva la licencia de la tecnología de texturas S3TC utilizada en Gamecube:
”La textura de compresión S3TC utiliza un avanzado algoritmo de compresión que consigue multiplicar por seis la compresión de texturas complejas”.
https://juegosadn.eleconomista.es/ninte ... -no-26086/


Entonces, ¿Cuál es el desempeño de la descompresión de texturas bajo este algoritmo?.
Según IGN:
"Another important part of Flipper's design is the S3 texture compression. There is physical metal found in the chip that decompresses stored textures at a 6:1 ratio. So, while they might take up 20MB of memory, they could theoretically be equivalent to 120MB of textures".
https://www.ign.com/articles/2001/01/17 ... 1-graphics

En conclusión, todo parece indicar que finalmente el siguiente dossier contiene los datos verificados:
Imagen


¿La caché de texturas también permite trabajar con texturas comprimidas, y enviarlas tal cual ?
Si. La Gamecube tiene 1MB de caché para texturas, que admite una compresión con un ratio de 6:1 para texturas de 24 bits, lo cual la hace equivalente a una caché de 6MB. Del mismo modo, su bus de datos hacia las unidades de texturizado alcanzarían el equivalente a 62,4 GB/s.
"1MB may seem like a paltry amount of texture cache, but Flipper can use S3TC texture compression, with a compression ratio of 6:1, effectively turning that 1MB into 6MB".
https://www.extremetech.com/computing/7 ... deux?print

Imagen


¿Alguna declaración de alguien que hable en concreto sobre que la Gamecube tenga compresión de texturas por hardware?:
Si, Julian Eggebrecht: "GameCube and Xbox will also look very similar because they both have the same texture compression on chip -- they both use S3TC."
http://www.nintendoworldreport.com/news ... -interview



2). ¿TIENE LA GAMECUBE UN MOTOR DE GEOMETRÍA Y TRANSFORMACIÓN DE VÉRTICES POR HARDWARE?.

La disposición del núcleo de la GPU de la gamecube, y la función de cada una de sus partes, es bien conocida, y está bien documentada, siendo la identificada como "XF" la encargada de calcular y transformar la geometría.

Enlace:
http://www.eurasia.nu/mirrors/www.segat ... /overview/

Imagen
PLL: Phase Lock Loop
eFB: Embedded Frame Buffer
eTM: Embedded Texture Memory
TF: Texture Filter
TC: Texture Coordinate Generator
TEV: Texture Environment
RASx: Rasterizer
C/Z: Color/Z Calculator
PEC: Pixel Copy Engine
SU: Triangle Setup
CP: Command Processor
DSP: Audio DSP
XF: Triangle Transform Engine
NB: Northbridge - all system logic including CPU interface, Video Interface, Memory Controller, I/O Interface


¿Cual es el rendimiento del motor de geometría?, ¿cuales son sus puntos fuertes y cuales son sus puntos débiles?:

Enlace a un artículo de difusión libre con mucha información al respecto (pendiente de confirmar):
https://disruptiveludens.wordpress.com/ ... ube-y-wii/

Resumen:
-El SDK de Nintendo habla de 32,4 millones de polígonos calculados por el motor de geometría (sin luces aplicadas). (pendiente de confirmar)
-El rasterizador no puede representar mas de 10 millones de polígonos, por lo que es un desperdicio no aplicar dos fuentes de luz como base de cualquier entorno gráfico, pero esa cifra se ha superado en algún juego. (pendiente de confirmar)
-Una vez que comienza la etapa de la geometría, los datos que definen el entorno no pueden manipularse hasta el final de esta, y por ese motivo se afirma que las deformaciones de los coches del burnout 3 no pueden reproducirse en una gamecube sin la supervisión de la cpu, que a la postre se le achaca ser insuficiente. Sin embargo eso no significa que no existan soluciones intermedias, como los efectos en la capacidad de cálculo y transformación a cambio de precisión gracias a la compresión de vértices. (pendiente de confirmar):

Vertex Compression:
Gamecube supports vertex compression, as it allows vertex data to be represented by bytes (8-bits) or shorts (16-bits) instead of floating point numbers (32-bits) if the particular game engine can get away with using less accurate polygon positioning. The transformation unit automatically unpacts the integer data, and converts it to floating point values before processing it.
https://www.gamekult.com/forum/t/reside ... u/28915/19

Esta información aparece en el libro "Level of Detail for 3D Graphics", página 161, línea 9:
"The XBOX integrates programmable vertex processing on the same NV2A as its pixel pipelines, as does the Gamecube on its "Flipper" GPU".
https://books.google.es/books?id=M-gl4a ... he&f=false



3). ¿CUALES SON LAS ESTIMACIONES DE POTENCIA TEÓRICA QUE PODRÍA ALCANZAR UNA GAMECUBE SEGÚN DATOS CONTRASTADOS?.

"EA of Canada got they’re hands on some development kits, and in February this year they had announced performance figures of 22M/sec@60 FPS. Now cut the FPS rating in half, and you’ve doubled the poly count. And 30FPS, with 44M polygons on the screen that’s nothing short of awe inspiring".
http://www.oocities.org/gamecube_mapped ... orial.html


Rogue Squadron III: Rebel Strike (GameCube, 2003) - 200,000 polígonos por frame (12 million/seg, 60fps):
-Factor 5 who is developing Star Wars: Rogue Squadron is already doing 12 million polygons/second, and the developer claims they are only using 50 percent of Gamecube's power. Factor 5 indicated they could get 20 million polygons/second per second with all effects. Effects stands for texture layers, and not polygonal lighting.
https://dctradio.webcindario.com/gamecube.html
https://forum.beyond3d.com/posts/1151206/



4). ¿ES POSIBLE DOOM 3 EN UNA GAMECUBE?.

Una pregunta tan controversial no se puede responder directamente, porque no hay respuesta. En su lugar puede recavarse información y sacar conclusiones en base a esta.

Esta información aparece en el libro "Advances in Visual Computing: 5th International Symposium", página 112, publicado en el 2009:
[i]"There is a surge in the polygon count per frame. The polygon count in 3DMark05 is about a few Million polygons/frame in contrast to 10-30K polygons/frame in yesteryear games like quake 3 or Doom 3".

https://books.google.es/books?id=zVlsCQ ... nt&f=false

Sin embargo, según carmack el número de polígonos por segundo varían enormemente dependiendo de la escena (que no escenario), así que se puede presuponer que los 30K polígonos por frame mencionados en aquel simposio en realidad podría ser una cifra bastante conservadora:
"Polys/s varied hugely by scene, but the XBOX was simplified a bit from PC".
https://twitter.com/ID_AA_Carmack/statu ... 0392659970

Pero según este análisis de gamespot, hablan de escenarios con un bajo recuento de polígonos, cosa que podemos apreciar todos, así que se puede interpretar que la enorme variación en la geometría dependiendo de la escena que menciona carmack, podría referirse a una cantidad proporcional con respecto a las cifras dadas por el libro anteriormente mencionado, y no a un incremento potencial de las mismas.
"The polygons that are used for the models and environments in the game are actually very low in count".
https://www.gamespot.com/the-chronicles ... 200-91059/

En definitiva, cuesta encontrar información sobre la geometría de los escenarios, así que, ¿hay alguna referencia mas por ahí?
Epic: "The models will have a rough limit of 3000 with 512x512 being the default texture size. Getting player models into the game is going to be very similar to what current UT modelers will be familiar with".
https://www.doomworld.com/forum/post/133659

Es decir, que si tenemos en cuenta que no era corriente dedicarle solo 2500 polígonos a los personajes cuando podías permitirte gastar 100.000 polígonos solo para el escenario, cobra sentido la afirmación de que los escenarios del doom 3 tenían unos 30k polígonos, y que en ocasiones podría incrementarse bastante, cifra que ahora mismo es una incógnita, así que le pongo la marca de rigor, y a otra cosa. (pendiente de confirmar)

Por otro lado, algunos modelos de enemigos doblan esa cantidad, y parece ser que el enemigo final alcanza los 8000 polígonos (claro, que los escenarios de combate son mas cerrados y simplificados cuando estos aparecen). Me he encontrado con esa información hace unas horas, pero he debido cerrar esa pestaña y ya no lo encuentro, así que le pongo la pertinente señal para verificarlo mas adelante. (pendiente de confirmar)

¿Y que piensa John Carmack de un posible port del Doom 3 a gamecube?:
"Would have been challenging and involved compromises, but something preserving the flavor could probably have been done".
https://i.ibb.co/hL1tLhj/doom3carmack.jpg
https://twitter.com/ID_AA_Carmack/statu ... 6833799174

Y un dato que confirma lo que dice, de una entrevista recogida en un libro llamado "John Carmack archive - Interviews", del 2008, página 138 en adelante:
-Los personajes están compuestos por entre 2000 y 6000 polígonos.
-El entrevistador menciona: "GeForce1/GeForce2/Radeon7500. All wouldbe able to run DOOM3 at lower resolutions with fewer per pixel lights perframe", y john carmack no le pone ningún pero a la ATI 7500.
https://fabiensanglard.net/fd_proxy/doo ... rviews.pdf

LA GPU de la GC estaría situada por debajo de esa ATI 7500, e incluso por debajo de una ATI 7500 LE en velocidad y ancho de banda, pero con algunas ventajas adicionales como una RAM mucho mas rápida, y un color combiner muy socorrido (TEV).
"it's a 162 MHz GPU superficially similar to ATi's own Radeon 7500 for the PC".
https://tvtropes.org/pmwiki/pmwiki.php/ ... doGameCube
https://technical.city/en/video/Radeon- ... meCube-GPU
https://technical.city/es/video/Radeon- ... meCube-GPU



5). ¿ES POSIBLE EL CHRONICLES OF RIDDICK EN UNA GAMECUBE?.

"Normal mapping begins with the creation of anextremely detailed model with a polygon count inthe hundreds of thousands versus 1,500 polygonsfor a standard in-game model".
https://gamestylearchive.files.wordpres ... iddick.pdf

Entonces, ¿es plausible que este juego mueva entre 1 millón y 1,5 millones de polígonos por segundo?
Si se sigue cumpliendo la tónica de mantener un número de polígonos para los escenarios proporcional al número de polígonos de los personajes, podemos afirmar que en base a 1500 polígonos para el modelo de riddick los escenarios no pueden ofrecer un conteo de polígonos excesivamente alto, mas aún viendo que las imágenes concuerdan con esa tendencia. (pendiente de confirmar)

Un análisis del juego que remarca la baja poligonización de los escenarios:
“While there are moments where the low polygon nature of the world sticks out, on the whole the graphs are good enough that you can immerse yourself in the world”.
http://www.highprogrammer.com/alan/rant ... thena.html

Otro análisis, esta vez de gamespot:
“The polygons that are used for the models and environments in the game are actually very low in count”.
https://www.gamespot.com/the-chronicles ... 200-91059/



6). ¿TENÍA ALGÚN TIPO DE VENTAJA LA GAMECUBE SOBRE LA XBOX AL POSEER UN PIPELINE GRÁFICO MAS CORTO?.

De anandtech:
"The benefit of a shorter pipeline is of course, an increased number of instructions that can be processed in those limited number of clocks".
https://www.anandtech.com/show/858/2

Cita de un fragmento de entrevista a factor 5, cuyo enlace a la fuente original parece estar ya caído:
“On the rendering side, the GameCube has exceptional texture handling so we designed the engine to take full advantage of that pipeline...It supports all the usual cool buzzword effects, dot3, anisotropic lighting, etc”.
https://www.neogaf.com/threads/could-do ... st-1171511

Esto podría explicar por qué la gamecube llegó a alcanzar 12 millones de polígonos con texturas de 8 capas y 8 luces a 60 fps, y que la xbox nunca alcanzase semejantes cifras. (pendiente de confirmar)



7). EN RELACIÓN A ESTO, SE HA MENCIONADO UN E-MAIL QUE PONE DE MANIFIESTO LAS DIFERENCIAS DE RENDIMIENTO ENTRE EL ROGUE SQUADRON DE LA GAMECUBE, Y UNA SUPUESTA DEMO PARA XBOX QUE HIPOTÉTICAMENTE EXISTIÓ Y QUE CORRÍA A 12FPS, ¿REALMENTE EXISTE ESE DATO?.

Por un lado tenemos que está oficalmente confirmado que existió un port del rogue squadron para la xbox, y que fué cancelado cuando llevaban un 50% de desarrollo:
"Initially, Factor 5 was brought on board by LucasArts to create a reworked Rogue Squadron trilogy for the original Xbox. The project would have been made up of Rogue Squadron, Rogue Leader, and Rebel Strike, remastered to work on the Xbox as a complete anthology. However, the title was cancelled when Factor 5 was only halfway done, with problems with the environment at LucasArts cited as a concern".
https://gamerant.com/star-wars-rogue-sq ... led-games/

En base a esto parece factible que finalmente si que se hubiese hecho una demo del rogue squadron partiendo de la versión gamecube.

¿Y donde se encuentra la referencia que menciona la existencia de ese e-mail?.
Internet es muy grande, y esa información es muy concreta. Yo mismo leí ese e-mail, pero de momento no se puede considerar contrastado. (pendiente de confirmar)



8). ¿EXISTE ALGÚN TIPO DE LIBRERÍA OFICIAL QUE OFREZCA UNA DOCUMENTACIÓN TÉCNICA EXTENSIVA DEL HARDWARE DE LA CONSOLA?.

Si. Aquí mismo:
https://www.davidgf.net/downloads/gcwii/gx.pdf#page=1

Otro enlace mas (este podría estar en construcción, o abandonado, pero sigue conteniendo información bastante poco común):
http://hitmen.c02.at/files/yagcd/yagcd/index.html



9). ¿XBOX ERA MAS POTENTE QUE GAMECUBE?.

Palabras de Julian Eggebrecht:
“When I said that X-Box and GameCube are on par power-wise I really meant it”.
http://www.nintengen.com/2007/09/wii-is ... ecube.html



10). ¿CUAL ES LA DIFERENCIA ENTRE LOS PIXEL SHADERS DEL NV2A DE LA XBOX Y EL TEV DEL FLIPPER DE LA GAMECUBE?.

Lo principal es entender que no hacen cosas diferentes, puesto que tienen la misma naturaleza: Son una referencia a los llamados "color combiners", y lo que eso significa es que en su forma mas básica todo lo que hace uno en cuanto a matemática del color (NV2A), lo hace el otro (TEV).
La diferencia está en el modo de trabajar, y en que de hecho el TEV si es mas limitado que los pixel shaders del NV2A, aunque por contra también dispone de alguna ventaja que no tiene el NV2A (como por ejemplo intercalar la lectura de una textura con su operación en el combinador), de forma que para algún cierto tipo de resultados, en esta sería obligado recurrir al multipaso, mientras que en la gamecube podrías hacerlo todo incluso en un único paso. (pendiente de confirmar)
https://forum.beyond3d.com/posts/975270/

¿Un ejemplo del uso de texturas que realizan todas sus tareas dentro de los 4 pasos por ciclo, mientras que en la xbox presumiblemente tendrían que ejecutar un segundo paso?.
Pues si lo hay: El efecto del agua del super mario sunshine.
http://blog.mecheye.net/2018/03/deconst ... -sunshine/

Lo leí hace tiempo pero básicamente es un scroll de tres texturas diferentes, cada una con su corrección de color, y la aplicación de un canal alpha para la simulación de las refracciones. En xbox no llevaría menos de 6 capas hacer algo así. Es decir, dos pasos.
El artículo también comenta como solventaros el impedimento de detectar la lejanía y altura del agua para saber que resultado darle a las refracciones según la posición de la cámara gracias a un sistema de LOD's para las texturas, y así ahorrarse métodos de texturización que incluyan esa información sobre sus tres ejes, cosa que hubiera sido mas demandante para el hardware. Muy interesante de leer.

¿Y cual es esa limitación del TEV con respecto al NV2A en cuanto a su capacidad con los color combiners?.
Parcialmente la diferencia está en la programabilidad de esas funcoiones matemáticas, pero mas que en una supuesta mayor obligación de completar esas tareas de una forma fija (es decir, no pudiendo idear nuevos formas de lograr diferentes resultados gráficos en cuanto a combinación de texturas, léase bump mappings, refracciones de calor, iluminación, etc), la limitación está en que si se pueden programar shaders para el TEV, lo que ocurre es que se usa la caché L2 de la cpu, lo cual tiene un impacto en el rendimiento por la latencía de tener que acceder a esa memoria, por tener que compartirla con el G3 provocando que este no pueda usar tanta caché, y presumiblemente por la disponibilidad de un tamaño mas reducido para llevarlo a cabo (porque la caché es una memoria reducida). (pendiente de confirmar)

¿Y ya está?, ¿no hay alguna limitación mas a la hora de hacer operaciones con texturas?
Parece ser que existen pegas para conseguir normals de una manera directa, de ahí que para el efecto del agua del super mario sunshine tuviesen que recurrir a trucos adicionales porque con normal mapping parece ser que se tienen en cuenta las coordenadas basándose en los tres ejes (x, y, z), y obviamente para ese juego no se pudo contar con esa ventaja. (pendiente de confirmar)

Sobre el uso de la caché L2 de la cpu para el uso y almacenamiento de shaders programables en GC: (pendiente de confirmar)
-En este enlace no se menciona concretamente que se pudiesen almacenar pequeños programitas (shaders) para que el TEV pudiese hacer la matemática del color con las texturas, pero menciona que el flipper si podía usar y/o compartir la caché L2 para sus propias tareas:
"Iban contra el tiempo de ahí a incluir soluciones que eran parches como la inclusión del bus Flipper-Gekko y la capacidad del primero de operar sobre la Cache L2 del segundo para acelerar ciertos procesos gráficos".
https://disruptiveludens.wordpress.com/ ... -feedback/

FALTA EL ENLACE QUE MENCIONA ESPECÍFICAMENTE EL USO DE LA CACHÉ L2 DE LA CPU POR PARTE DE LA GPU PARA ALMACENAR Y USAR LOS SHADERS SIN INTERRUMPIR EL PROPIO FUNCIONAMIENTO DE LA CPU



11). ¿CUALES SON LAS COINCIDENCIAS ENTRE LOS PIXEL SHADERS DEL NV2A DE LA XBOX Y EL TEV DEL FLIPPER DE LA GAMECUBE?.

Una pista que le da veracidad al hecho de que se pueden elaborar shaders completamente programables en gamecube:
Según Julian Eggebrecht: The TEV pipeline is completely under programmer control, so the more time you spend on writing elaborate shaders for it, the more effects you can achieve.
http://www.nintendoworldreport.com/inte ... y-speaking

Una observación desde el medio mas documentado y legitimado para considerar que no son afirmaciones hechas a la ligera, ni mas ni menos que la web del emulador "DOLPHIN":
While it has some fixed-function parts, Flipper features a programmable TEV (Texture EnVironment) unit that can be configured to perform a huge variety of effects and rendering techniques - much the same way that pixel shaders do. In fact, the TEV unit has very similar capabilities to the DirectX 8 pixel shaders of the Xbox!".
https://es.dolphin-emu.org/blog/2017/07/30/ubershaders/



12). ¿LE DA VENTAJA A LA GAMECUBE LA MAYOR VELOCIDAD Y MENOR LATENCIA DE SUS MEMORIAS PARA UN MAYOR APROVECHAMIENTO DE SU ANCHO DE BANDA?.

Concretamente, una de las grandes virtudes de las memorias 1T-SRAM es la eficiencia para la lectura de posiciones de memoria no concatenadas, haciendo que el acceso sea mas rápido, y que el aprovechamiento del ancho de banda se desperdicie en mucha menor medida con respecto a las arquitecturas que montan memorias normales, como la xbox o la ps2.
"Xbox’s overall system memory bandwidth is lower than that of GameCube, since the latter uses a segmented memory design where certain small pools of memory go very fast, while others run at slower data rates. Xbox overall has 6.4GB/sec of peak system memory bandwidth, which compares pretty well with current PC 3D cards, whose peak data rates are around 7.3GB/sec. But, DDR memory is typically about 75% efficient, so the effective bandwidth will more likely be more in the neighborhood of 4.8GB/sec".
https://www.extremetech.com/computing/7 ... deux?print

Es decir, que la xbox tiene un ancho de banda aprovechable de alrededor de 4,8GB/s por culpa de su memoria ram (dependiendo de como estén alineados los segmentos de memoria para ser leídos), y de la cual tiene que reservar una cantidad para la cpu, para su sistema de sonido, y no se si alguna cosa mas, mientras que la gamecube dedica a cada parte de su hardware un ancho de banda específico, consiguiendo en última instancia un rendimiento razonablemente equiparable, con un ancho de banda conjunto de casi 3,9 GB/s (del cual habría que deducirle algo por el mismo motivo, aunque en mucha menor medida, por quedar el aprovechamiento del ancho de banda entre la CPU y la GPU intacto al no haber memorias de por medio, y por ser el ancho de banda entre la GPU y las memorias considerablemente mas eficaz gracias a la rapidez de estas). Fuerza bruta vs eficiencia. (pendiente de confirmar)

Imagen



13). ¿ES CIERTO EL DATO DE QUE LA GAMECUBE PUEDE TEXTURIZAR 8 VECES UN POLÍGONO DENTRO DE UN MISMO PASO?.

Se asume que la Gamecube puede aplicar 8 capas de textura a un polígono en un solo paso mientras que la XBOX solo puede aplicar 4 capas de textura por paso, pero he llegado a leer que en realidad existe una ligera penalización.

De forma vaga recuerdo que para texturizar 8 capas a un polígono en la XBOX se requieren 2 pasos completos, mientras que en la Gamecube es algo parecido a 1,2 pasos en lugar de en 1 paso. (pendiente de confirmar)


Fragmento del libro "The Video Games Textbook: History • Business • Technology" (página no indicada, párrafo 1):
"so essentially PS2 [had] to render 1,000 polygons eight times over whereas Gamecube only [had] to render 1,000 polygons one time for the same effect (IGN staff, 2000a, para. 19)".
https://books.google.es/books?id=IExnDw ... ns&f=false



14). ¿TIENE LA GAMECUBE HARDWARE DEDICADO PARA SACAR IMÁGENES 3D ESTEREOSCÓPICAS?.

Parece ser que si. Según gamespot, durante una entrevista a Satoru Iwata, este comentó la existencia de una funcionalidad gráfica de la máquina que hubiera permitido poder conectar unas gafas para ver las imágenes en 3D, al estilo de lo que ahora es oculus, y toda la gama de dispositivos de "realidad virtual".

"The Nintendo GameCube system actually had 3D-compatible circuitry built in. ... It had the potential for such functions," Iwata told an interviewer. "If you fit it with a certain accessory, it could display 3D images. ... Nintendo GameCube was released in 2001, exactly 10 years ago. We'd been thinking about 3D for a long time, even back then".
https://www.gamespot.com/articles/gamec ... 0-6286296/

En este otro medio recogen las siguientes declaraciones, también de Satoru Iwata:
"To tell you the truth, GameCube is secretly designed to load graphical circuits which display graphics for right and left eyes respectively, for a future possibility of realizing 3D gaming experience" Nintendo already "had interest in this technology,"

Ambos enlaces parecen confirmados desde que la propia nintendo desde su página web publica una entrevista hablando del tema, y mas concretamente sobre el desarrollo del luigi's mansion para las 3D estereoscópicas:
https://www.nintendo.es/Iwata-pregunta/ ... 18558.html

Al parecer tenían un prototipo de gafas 3D funcionales, pero eran caras de producir, y la resolución parecía ser insuficiente:
https://www.gamasutra.com/view/news/122 ... nce_SP.php

Este pequeño artículo parte de la scene con un pequeño prototipo que podría desbloquear esa funcionalidad:
http://www.retro-system.com/ActiveShutter3D.htm

Para finalizar, la wiki del emulador Dolphin habla en profundidad sobre el tema, y su, al parecer implementación de las 3D estereoscópicas dentro del programa:
https://wiki.dolphin-emu.org/index.php? ... c_3D_Setup

Incluso hay vídeos en youtube:
https://www.youtube.com/watch?v=SDFQzrQ-GZA
https://www.youtube.com/watch?v=oeLdKTnlUvU



15). ¿EXISTIÓ UNA TRILOGÍA DE LOS TRES PRIMEROS ROGUE SQUADRON EN WII?.

Si. Según Julian Eggebrecht habían rehecho el motor del juego, y considera que hubiera sido el juego técnicamente mas impresionante de todo el catálogo de Wii.

"La trilogía en Wii estaba terminado, pero una vez más, este proyecto de Star Wars de Factor 5 se archivó".

"Se había creado un motor gráfico completamente nuevo, que hacía que el juego funcionara a 60 imágenes por segundo y una fidelidad visual de la que Eggebrecht sigue estando orgulloso. "Creedme, si lo hubiérais visto funcionar en Wii a 60, sería -y creo que no estoy exagerando- el juego tecnicamente más impresionante que habríais visto en Wii"
".

https://forum.beyond3d.com/threads/rogu ... st-1151206
Escribo para felicitarte por el post. No puedo añadir info, pero la que hay resulta muy interesante, la verdad ;)
Me gusta la iniciativa del hilo [ok]

Me leere el tochopost con sus fuentes con ganicas :)

Me encanta esta cita de Jhon Carmack refiriendose a si es posible portar Doom3 a GC: "Would have been challenging and involved compromises, but something preserving the flavor could probably have been done"

Es lo mismo que pienso con esos what if y pajas mentales tan comunes de esa epoca; si, era posible portar un buque insignia de una consola a otra, no seria lo mismo técnicamente, pero mantendrá la esencia si se curra lo suficientemente en ello. El RE4 es un ejemplo de esto.
2 respuestas