Disculpa la tardanza, he estado un poco liado estos días como para poder estar demasiado tiempo escribiendo un post tan complejo como este.
Vamos allá....
Jimmyhoo escribió:son lor argumentos de rusty/erp no mios, pero estas mal interpretando y lo que dices se le pregunto en el tema del link que deje(aunque a lo largo de todo el tema no solo la pagina ligada), el no dijo que fuese "imposible" dijo que el resultado era de muy baja calidad como para ser aceptable a pesar de haber dedicado un tiempo razonable a intentarlo, aunque tambien menciono que otro tema que surgio era que el publico en GC para el juego era menor por lo que se tomo la decision de cancelar el port, y si muchos ports hacia GC se cancelaron por cuestiones de costo/beneficio pero eso no significa que fuese
tambien menciono que burnout3 no se pensaba sacar en esa generacion
burnout3 no funciona con renderware sino con un engine reescrito(probablemente basado en renderware pero con unr endering distinto)
aunque la T en T&L significa transformacion, en 3D la tranformacion se refiere a mover un vertice en sus coordenadas xyz no a una deformacion en fisica, si el soporte de GC tiene algun requerimiento especial, como espera un buffer que no va a cambiar(por ejemplo un modelo cuyos vertices no cambien mucho), entonces el cambio se tiene que hacer en CPU en GC en PS2 pasa a VU1 y ahi ps2 tiene ventaja, es una conjetura pues rusty no menciono especificamente eso sino que simplemente tuvieron que hacer en CPU cosas que xbox y ps2(usando el VU1 no la cpu central) podian hacer mucho mas rapido, eso tomalo como quieras, pero el rusty/erp como desarrollador estuvo en involucrado en proyectos de DC, GC y PS2(y quizas tambien xbox)y por eso se considera que si dijo que no se poda(aceptablemente) entonces no, pero
no he revizado fuentes de comparativas, pero mucha gente menciona que burnout2 se ve mejor en PS2 que GC, una busqueda rapida en youtube y veo que eso es correcto por lo que eso de "mejor que ps2" no se donde lo habras leido
https://www.youtube.com/watch?v=79URW3AkJPYno se en burnout1 voy a asumir que en ahi corre mejor en GC como dices, pero dado que cada nuevo burnout era mejor y mas demandante que el anterior asumo que tenian menos conocimiento de ps2 cuando lo hicieron ya que es considerada una maquina muy dificil al principio
Entonces no tiene nada de mito, el hecho de considerar a gamecube como una consola que no iba a brindar muchas ventas fué determinante para no perder el tiempo optimizando nada.
Siempre hay formas de lograr un resultado sin emperrarse en que funcione de una única manera, y la deformación de los vehículos, mejor o peor llevada, se puede adaptar a la arquitectura de un hardware concreto, mejor que obligando a que funcione como funciona en otro hardware.
Sobre el burnout 2, en el vídeo que muestras hay que apreciar un detalle antes de entrar en conclusiones sobre cual es gráficamente mas potente.
Se trata de que el vídeo está capturado con un cable de peor calidad en la versión GC. La parte de la izquierda, indicada en un circulo, pertenece a la versión PS2, y la parte derecha, tambien indicada en un circulo, pertenece a la versión GC.
Date cuenta que hablamos de texto, y ya se ve peor. Si la opinión de la gente que piensa que se ve mejor en PS2 se basa en este vídeo, creo que tenemos un problema... y es que, mira lo que pasa cuando capturas bien la imagen:
https://youtu.be/YCAGgE2i008?t=5652Sobre el burnout 1, aquí si vemos una comparativa con señales de vídeo equivalentes, y ya se deja notar que en la versión GC funciona al doble de resolución vertical, y a un frame rate claramente mejor (en PS2 le meten un blur guarro para disimularlo).
https://youtu.be/9v5NosQE8Tk?t=46Jimmyhoo escribió:lo que dices es correcto, en muchos casos un port que no es base puede convertirse en un mal port, pero no se puede generalizar tampoco y no creo que sea el caso con burnout3(sobre todo viendo el 2)
pero no nos olvidemos tampoco que GC se hizo especialmente para ser facil de trabajar utilizando hardware especifico para todas las cosas que en PS2 se tenian que programar a mano(sobre todo al principio), muchos articulos de la epoca hacian incapie en que nintendo estaba muy confiada pues dado que pudieron ver las especificaciones y funcionamiento de ps2 mientras diseñaron GC, la hicieron especificamente para evitar los problemas potenciales que tenia despues de todos los problemas tecnicos que tuvieron con n64(solo que tambien querian un bajo costo)
no me vas a decir ahora que es mas sencillo trabajar en ensamblador en los VU de ps2 para mandar a GS(que es de funcion fija con funciones muy especificas y sin muchas de las funciones complejas de sus competidoras) y administrar la eDRAM que no tiene un lugar especifico para cada cosa contra mandar instrucciones a flipper, al TEV(que es fixed function pero muy potente) y usar buffers especificos y separado para cada cosa
rusty tambien habla pestes de las herramientas que ps2 tenia al principio y menciona que GS tenia un bug que evitaba usar altas resoluciones en ps2 sin recurrir a un workarround que luego vino documentado formalmente mucho tiempo despues, de hecho rusty menciona que GC es muy facil de trabajar para "desarrollar" juegos mientras que en ps2 es ir a "programar" juegos siendo un mayor reto como desarrollador
Tiene sentido, porque en PS2 casi toda la potencia en TFLOPS se concentra en su cpu, por lo que todos los elementos gráficos que se centren en ella serán sumamente programables, mientras que la GPU de la GC tiene unas funciones gráficas ya definidas (excepto el TEV, que es programable), y de ahí no te puedes salir.
Por eso salieron cosas como shadow of the colossus en PS2 (con incluso un pseudo hdr por software), pero con un frame rate terrible de 14 fps, y un recuento bajísimo de polígonos (a pesar de los 18.000 por frame que llevaban algunos de los enemigos).
Sin embargo, también se han visto efectos de HDR por software en GC, no es que sea algo que esté vetado para su cpu xD
Jimmyhoo escribió:Señor Ventura escribió:Ahora ya nos entendemos, pero al menos no niegues las evidencias. En GC no se optimiza nada para su plataforma, luego para el RE4 si es excusa, porque el juego está hecho para GC, pero si el burnout 3 no trabaja en GC como trabaja en PS2, entonces se habla de falta de potencia.
Seamos objetivos, ¿no?.
¿Es en serio?
el que niega aqui la evidencia eres tu, para empezar Shinji Mikami decia que se iba a "cortar la cabeza" o algo asi si RE4 salia en ps2 o en alguna otra plataforma no os olvidemos de los famosos "Capcom Five" , asi que RE4(en su forma final) tuvo su largo desarrollo en GC sin considerar nada mas, luego RE4 fue porteado por otro estudio(aunque anunciado poco antes de la salida en GC) para salir meses despues el mismo año
burnout3 es el tercer juego de una serie de esa misma generacion con juegos en las plataformas de la epoca(menos dreamcast) y se hizo con un engine propio hecho por programadores con experiencia en todas las consolas para un juego multiplataforma y se determino que en GC el resultado no era aceptable por no poder procesar lo que habia, vamos ni punto de comparacion, RE4 no es un port pensado en ps2 , mas bien tiene toda la pinta de un port lo mas rapido posible para salir en la epoca navideña de ese año
Por partes.
Esto no puedo afirmarlo ahora porque no encuentro ningún enlace, y no me apetece peinar google al menos hasta que no termine este post, y edite luego la información... pero el cabreo de shinji mikami venía precisamente porque capcom durante una buena parte del desarrollo del juego estuvo llevando ambas versiones en paralelo, así que, no, en ps2 no fué un port en plan rapidito. Las diferencias entre ambas versiones del juego se deben a que GC tiene mas capacidad para meter texturas y polígonos a mayor resolución. Al cesar lo que es del cesar.
Sobre el burnout 3, después de que el tal rusty haya dicho que en GC no dieron mucho crédito al desarrollo del juego por "potencialmente falta de clientes", no creeremos que se le dió bola al engine en gamecube con el mismo empeño que en las otras dos, ¿no?.
Por lo tanto, me reitero, con la versión PS2 del RE4 si es excusa que fuese un port, pero con la versión GC del burnout 3 no parece aceptarse que el no tenerle mucha fe a sus ventas fué muy negativo a la hora de querer gastar tiempo en ajustar un buen motor para esa arquitectura. Yo creo que mas claro, agua.
Jimmyhoo escribió:Señor Ventura escribió:Es justo a lo que me refiero, es que hasta hay juegos con peores texturas en GC que en PS2, y no se cree nadie que es un problema de capacidad.
el SDK de GC maneja las texturas directamente en S3 en el disco, el mismo renderware tiene formato especifico para almacenar las texturas coprimidas en cada sistema, si GC puede 6 texturas donde ps2 puede 1 y todo esto sin problema alguno como tu argumentas ¿entonces donde esta?
El problema está en: "cutre ports".
Caben mas texturas en la ram de la GC que en la ram de la PS2. No creo que sea algo muy rebatible.
Jimmyhoo escribió:Señor Ventura escribió:Lo del agua del baldurs gate es el ejemplo perfecto de la desidia que comento cuando hablamos de ports para GC. El agua en GC no está ni implementada, cuando tienes ejemplos de deformación del agua en juegos mucho mas demandates que este, y aplicados a entornos mucho mas amplios.
entornos mas demandantes puede ser pero no por ello un juego mas demandante en general necesariamente, baldur gate es un juego muy bruto en cuestion de poligonos e iluminacion en comparacion con otros juegos y no olvidemos que fue pionero en tecnicas de "mega texturing", fracciones de texturas del mapa cargando dependiendo donde estas en el mapa de un archivo gigante, ahora son algo mas visto con implementaciones mejores y soporte en hardware, pero empezaron en esa epoca y son la insignia de los juegos que del motor de snowblind que no son precisamente pocos, quizas esa sea una de las razones por las que GC tiene esos problemas, una combinacion entre el buffer cambiante de texturas comprimidas, quizas hasta problemas de lectura del disco, es un juego con mucho para debatir el por que, ahora que dificlmente podemos hablar de port baratos, la version de GC tiene animaciones retrabajadas
La velocidad de acceso y lectura del mini dvd de la GC es superior al del dvd de la ps2, y una cache de texturas equivalente a 6MB comparado con la VRAM de la PS2, así que por aquí no está el problema.
Podría ser que no todo quepa en los 2MB de frame buffer, pero sucede que la PS2 solo tiene 1MB, asíq ue por aquí tampoco veo el impedimento.
Tal vez sea una cuestión de ancho de banda interno... pero, ¿realmente algún juego que use al máximo un hardware de aquella época exceda el ancho de banda de la GC?.
Lo que si parece claro, es que la escena de aquel lago por si misma no tiene nada que una GC no pueda hacer, así que algo se ha hecho sin tener en cuenta a la GC, y por el que luego la han dejado colgada a la hora de recibir ese fecto gráfico del agua... me inclino mas por esto.
Jimmyhoo escribió:el T&L en GC o mas propiamente el de flipper es estatico, es decir no es programable y carece de vertex shader, cualquier transformacion en los vertices corre a cargo de la CPU y eso pesa, eso aplica para el agua de Baldurs gate y para la deformacion de los autos en burnout3, la CPU de GC es buena pero no se puede comparar a la VU1 de la PS2 para vertex shading, no digo que no se pueda usar, claro que se puede pero le resta CPU para otras cosas, si el juego no usa cambios en los vertices(como las naves de RS 2 y 3), entonces GC puede empujar poligonos y tener CPU para lo demas si no enotnces puede tener problemas segun el juego, los argumentos de rusty son bastante solidos, realmente no has mostrado nada en contra de lo que dice
Parece ser que el pipeline del TEV es completamente programable, en anandtech hay bastantes referencias a artículos y entrevistas a programadores que desmienten el argumento de que la GC necesita la cpu para el T&L.
Julian Eggebrecht: He was probably referring to the TEV pipeline. Imagine it like an elaborate switchboard that makes the wildest combinations of textures and materials possible. The TEV pipeline combines up to 8 textures in up to 16 stages in one go. Each stage can apply a multitude of functions to the texture - obvious examples of what you do with the TEV stages would be bump-mapping or cel-shading. 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. We just used the obvious effects in Rogue Leader with the targeting computer and the volumetric fog variations being the most unusual usage of TEV. In a second generation game we’ll obviously focus on more complicated applications."¿Y quien es Julian Eggebrecht?, pues ni mas ni menos que el presidente y programador jefe de uno de los juegos mas impresionantes de toda su generación. Vamos, que sabe de lo que habla, sabe lo que dice, y para rematar lo ha demostrado con la mayor prueba posible: un juego que hace gala por hardware de todos esos efectos (así que no son teorías).
En otras palabras, que la iluminación dinámica a base de vertex shaders del rogue squadron está hecho con soporte del TEV del flipper (la cual, hay que señalar que sucede con muchas fuentes simultáneas).
Es decir, que según julian eggebrecht, sucede sin necesidad de ningún apoyo de la cpu. Y además, está el detalle de que la gamecube
SI tiene pixel shaders, pero su uso en esta ocasión si parece estar limitado aquí a una iluminación fija.
En el PN03 ves una iluminación global de varias fuentes con una precisión que efectivamente es por pixel, pero que es estática. Y luego ves una iluminación por vértice para los rayos laser, que es dinámica... y tanto los pixel shaders, como los vertex shaders,
son por hardware sin ayuda de la cpu.No se si tras esto desecharás la idea de seguir usando el argumento de que la GC no puede usar T&L sin ayuda de la cpu, pero creo que ya va siendo hora de derribar ese mito.
Jimmyhoo escribió:XD
vamos no me compares automodelista con burnout3
https://www.youtube.com/watch?v=EWnmUaxtB7Isobre la iluminacion de automodellista...
¿cual de estas 2 imagenes te parece que tiene una iluminacion mas compleja?
mejor evita utilizar automodellista o cualquier otro juego de ese estilo grafico para hablar de "precisión" en iluminacion
No estoy comparando el automodelista con burnout 3. Estoy señalando un juego (GT cube) con un estilo gráfico pseudo cell shading, con una iluminación y un sombreado de dos capas haciendo uso del vertex shading.
Es decir, que eso es T&L por hardware, de la misma forma que la transformación de la geometría de los coches del burnout 3 requerirían del hardware de la gamecube: es decir, T&L por hardware.
O dicho de otro modo,
ahí tenían en criterion una base sobre la cual trabajar a la hora de adaptar su engine para el cubito, pero no les apeteció investigar el TEV, sino hacerlo a base de CPU.Yo creo que se ve bastante claro que los problemas de rendimiento se deben a que no quisieron investigar, y trataron de hacer por software hasta las cosas que se podían hacer por hardware. Para mi tiene sentido que ese sea el motivo por el que en criterion se encontraron con un problema a la hora de trasladar el juego a GC, no se que te parecerá a ti.
Jimmyhoo escribió:Señor Ventura escribió:Que manía con que estoy confundido, o que no se lo que digo.
no es que sea mania es que lo dejas patente, lo siento pero asi es, la imagen que pusiste de zelda lo desmuestra, no tienes ni idea de lo que trajiste
¿Y eso que quiere decir?, ¿que como una cosa está mal, entonces todo está mal?.
Tu también te equivocaste entonces al decir que la GC no puede usar texturas/buffer de 32 bits porque excede su espacio.
La realidad es que la GC no usa texturas/buffers de 32 bits, sino que usa texturas/buffers de 24 bits porque está hecha así:Y esto puede parecer algo malo, pero lo cierto es que en términos de optimización, el espacio reservado en la EDRAM no malgasta en información de transparencias, y eso en proporción equivale a tener mas memoria disponible.
Aquí tienes un hilo bastante interesante al respecto:
https://forum.beyond3d.com/threads/why- ... ing.25142/Luego, la conclusión es, que la EDRAM queda muy optimizada para guardar texturas sin desperdiciar espacio que no sea para el propio dibujo de la textura, y que las transparencias tienen que venir por otro lado porque no hay ni rastro de canal alpha en texturas/buffers de 24 bits. ¿Estamos de acuerdo?, o no estamos de acuerdo...
Jimmyhoo escribió:solo repites lo mismo, tu te crees que para dar dos pasadas aunque sea un solo poligono tienes que quemar 50% de todo el fillrate,, hitman blood money matrix path of neo muestran millones de poligonos y efectos como normal maps(dot3) matrix path of neo simplemente no tiene comparacion con enter the matrix hablamos de normal maps y eso es algo que le cuesta a GC, matrix path of neo usa hasta 19 pasadas, pero seguramente vas a decir que Dave Perry esta mintiendo
basicamente de acuerdo a ti ps2 no puede nada, lo unico que parece es que nunca has jugado a ningun juego de la consola
si el juego es mejor en GC que ps2 es por que GC es mas potente
si el juego es mejor en ps2 es por que esta mal hecho en GC pero bien hecho en ps2
Tengamos una cosa clara, bump mapping y normal mapping son la base del DOT3, y DOT3 es lo que implementa la gamecube por hardware. Hasta ahí ya te puedes poner como quieras, que no le va a penalizar como si le va a penalizar a la PS2 implementar una cosa así (porque estaría obligada a hacerlo por software). Otra cosa sería decir que la PS2 no pueda mostrar texturas a base de normal mapping, bump mapping, o cualquiera de otras técnicas para este tipo de texturas, pero eso no se ha dicho... lo que si se dice, es que chupa cpu, chupa fill rate, y no hay demasiada memoria para texturas como para usar varias para mezclar en una sola.
Por eso ves ese tipo de texturas en pasillos, y con pocos polígonos, en el matrix path of neo.
Es decir, que ya puedes ponerte como quieras, pero el matrix path of neo no mueve millones y millones de polígonos con normal mapping. Estoy intentando buscar a ver si alguien ha puesto datos, pero de momento no lo encuentro... ahora, lo que si te puedo decir, es que los niveles que incluyen ese tipo de texturas en el juego, son muy simplificados en geometría.
Es que simplemente no tiene sentido afirmar que pueda ser de otro modo, porque a la PS2 le mete unas hostias tremendas al fill rate cualquier cosa que requiera multipassing (incluso 1 textura + glowing le mete una mordida al número de triángulos que es impresionante).
Jimmyhoo escribió:si si todos son cutreports..
de RS, hablas de bump mapping(en el caso de RS es emboss) y ¿a saco? la x-wing fue ripeada del juego y no contiene bump maps por ningun lado los bump maps estan en la superficie de la estrella de la muerte y no son de alta resolucion ¿si estas consiente de cuantas texturas diferentes estan ahi y lo mucho que se repiten? por lo visto no, tampoco hay "descenas de fuentes luz", los rayos de la nave emite luz pero las explosiones no, si vas al minuto 2:35 puedes ver cuando destruyen las torres como las pequeñas explosiones son sprites y no emiten luz aunque esten sobre la superficie de la estrella de la muerte, volviendo a la parte que traes( la de la trinchera) se puede ver como no se generan sombras sobre la trinchera, tampoco sobre la nave(la nave si genera sombras pero solo sobre si misma), de hecho la nave solo se ilumina en base a la luz global(cosa que tambien se aprecia en otras escenas dentro de la estrella de la muerte en otras misiones y en la secuela), RS3 es mejor en cuanto a poligonaje(las escenas de naves o la batalla en endor)
Por partes.
Efectivamente las texturas del x-wing no son con bump mapping. Suelen destinarse a las texturas de los escenarios, pero que el escenario de la estrella de la muerte se preste por definición a repetirse con las texturas, no significa que ociurra igual en otros escenarios del juego.
Sobre las fuentes de luz, efectivamente no hay decenas de ellas, sabía que no lo pasarías por alto, pero si llegan a haber claramente en torno a la docena en varios puntos del juego.
Y efectivamente, las explosiones no tienen fuente de luz, pero también es cierto qeu no hubieron juegos como este en toda su generación
![[rtfm]](/images/smilies/rtfm.gif "Lee!")
No he tenido tiempo de buscar mas, así que de momento habrá que conformarse con un ejemplo de varias fuentes de luz simultáneas:
Sobre las sombras de la trinchera, la nave
SI genera sombras sobre el escenario... si te fijas en la parte derecha, justo en la parte superior del muro, verás las sombras de los tie-fighters, y del x-wing:
Jimmyhoo escribió:12 millones es una buena cifra, solo que grand prix challenge de ps2 usa hasta 18 millones dependiendo la escena, esto por los reflejos en tiempo real y al doble de resolucion de RS, pero seguro que vas a decir que en melbourne house son unos mentiros y que no se puede hacer multipass en ps2 XP
Ya te lo he dicho antes, el grand prix funciona a 30fps, así que no son 18 millones de polígonos, son picos de no mas de 9 millones. Y no funciona al doble de resolución del rogue squadron porque este funciona a 480p.
Por lo demás, es un juego muy contenido precisamente para eso, para poder meter tanta carga poligonal en pantalla. Hay ejemplos mas reseñables en la propia consola.
Jimmyhoo escribió:en cuanto al video de hitman con dead rising, no era mi intencion compararlo, era el primer video que vi de hitman 4 de ps2 en la escena del desfile dead rising de wii es penoso sobre todo siendo wii una consola tan avanzada, tmbien he visto otras comparativas de wii con ps2 y psp que dejan mal para a wii, pero eso tambien revela que aun en una consola bien vendida a la que se le dedica tiempo puede llenarse de juegos que no la explotan correctamente
Y tanto.
Mismamente, esto es extrapolable a un doom 3:
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[poraki]](/images/smilies/nuevos/dedos.gif "por aquí!")