Jump to navigation
Comparativa: Final Fantasy XIII

Article XBOX360 PS3

Comparativa: Final Fantasy XIII

El cuento de nunca acabar. [18 comments]

Comparativa: Final Fantasy XIII
Análisis técnico: Apple iPad

Article

Análisis técnico: Apple iPad

Digital Foundry explora el nuevo contendiente en la guerra de las portátiles. [3 comments]

Análisis técnico: Apple iPad
digitalfoundry blog

Análisis de rendimiento de Blur

March 11th, 2010

No hemos sabido mucho de Bizarre Creations desde el lanzamiento de The Club y la posterior compra por parte de Activision, así que la oportunidad de probar la beta multijugador de su próximo juego, Blur, era una ocasión irresistible.

Su último título para Xbox 360, Project Gotham 4, era un precioso juego con resolución 720p nativa, 30FPS estables y anti-aliasing 2x multisampling, rematado con excelentes efectos de post-proceso que ayudaban a mejorar la sensación de velocidad y el realismo de la simulación.

Con Blur, el enfoque se vuelve mucho más arcade, con toques de Mario Kart y WipEout en el uso de armas, power-ups y un intenso combate entre vehículos. De todas formas, el trabajo de Bizarre en conseguir un aspecto visual sólido y unos efectos impresionantes no ha variado ni un ápice.

Así que... ¿cómo se comporta la beta a nivel de rendimiento?

La respuesta es "notablemente bien". Desde el principio hasta el final, no importa lo que está ocurriendo en pantalla: Blur mantiene una tasa de 30 frames por segundo sin ni un solo frame caído, y sin ninguna fluctuación en la gráfica, lo cual iguala el anterior récord que ostentaba Dante's Inferno.

A nivel de tecnología, apreciamos una pequeña mejora en el formato del framebuffer, comparado con PGR4. El juego mantiene la resolución nativa de 720p, pero el anti-aliasing sube hasta el máximo que puede ofrecer Xbox 360, 4x MSAA. Aunque el nivel de geometría de los fondos es un poco bajo en la beta, la verdad es que el ojo se centra mucho más en la gran cantidad de vehículos que hay en pantalla en cualquier momento.

En resumen, Blur es tan sólido como podíamos esperar de un juego de Bizarre Creations, y tenemos ganas de echarle el guante al código final en todos los formatos. Blur se publicará el próximo 28 de mayo para Xbox 360, PlayStation 3 y PC.

1 comentario

God of War III: demo vs. versión final

March 9th, 2010

En 2005 Sony Santa Monica redefinió las limitaciones técnicas de toda una generación de consolas con el épico God of War. Cinco años más tarde, el equipo ha vuelto a hacerlo con su debut en PlayStation 3: God of War III es, tal y como esperábamos, magnífico.

¿Pero el juego ya lo habéis probado, verdad? Durante el pasado E3 en Europa se pudo jugar de forma aislada antes de que el código fuera distribuido de forma masiva con God of War Collection, y la demo fue recientemente colgada para todo el mundo en la PlayStation Network.

Tras probar la versión final de God of War III es obvio que el juego no sólo es impresionante, sino que la demo no es para nada representativa del resultado definitivo. De forma comprensible, hay mucho contenido que no está en la versión de demostración, pero es que además se han añadido nuevos efectos gráficos y se ha mejorado de forma considerable el rendimiento.

Para no hacer ningún tipo de spoiler en la comparativa no vamos a mostrar nada que no estuviese presente en la demo, pero ver los efectos añadidos y las mejoras de rendimiento generan muchas preguntas sobre cuánto ha podido exprimir el equipo de Sony Santa Monica el hardware de PS3 durante los últimos meses de desarrollo de God of War III.

Quizás el cambio más obvio del juego sea el extensivo retoque del esquema de iluminación, que ahora es mucho más rico y realista. Las zonas más oscuras del nivel de la demo parecen representar ahora de forma más precisa el efecto de la luz ambiental en el escenario.

Un sistema de motion blur realista y que afecta por separado a cada objeto también ha sido añadido. Le da al movimiento del juego un aspecto más creíble, aunque tiene el efecto adverso de que no parece demasiado limpio en las capturas de pantalla.

Es interesante dejar constancia de que el equipo de Sony Santa Monica ha hecho muchos cambios gráficos más, algunos francamente evidentes y otros mucho más sutiles. Las modificaciones en el Titán son visibles desde el primer momento, con el obvio incremento de detalle en la textura de la piel.

Otros ajustes más pequeños en el nivel también son aparentes. En las siguientes capturas podéis apreciar como el equipo ha añadido efectos de sombreado adicionales que no estaban en la demo.

El efecto de fuego en el carruaje de Helios también tiene mucho más detalle ahora, y se puede distinguir claramente como la principal fuente de luz que afecta al escenario ha variado entre las versiones demo y final del juego.

También es interesante ver como el propio Helios parece sutilmente diferente comparado con su aparición en la demo. El efecto de dithering en el pelo está mucho más reducido en la versión final. ¿Podría ser debido a la nueva técnica de anti-aliasing aplicada a God of War III? Según los posts en internet de la propia Sony Santa Monica, God of War III usa una implementación de anti-aliasing morfológico, utilizando las SPUs. Esto permite un suavizado de bordes muy superior, y es otro ejemplo de cómo descargar ciertas tareas realizadas normalmente en el chip gráfico puede ofrecer incrementos tanto de calidad como de rendimiento.

Teniendo en cuenta lo impresionante de la mejora visual que ha tenido el juego, es alucinante que no sólo se limiten a la calidad visual: Sony Santa Monica, además, ha conseguido todo esto haciendo que el juego sea más rápido y suave. En el siguiente vídeo podéis ver varios clips tomados de la demo de God of War III. Luego se han tomado esos mismos fragmentos pero con la versión final.

Las conclusiones extraídas del vídeo son claras: se aprecia una importante mejora en el frame-rate en las mismas escenas. En nuestro análisis de la demo del E3 nos preguntábamos por qué el juego funcionaba con un frame-rate desbloqueado cuando, en los momentos con más acción, seguíamos sobre una cifra cercana a los 30FPS. Viendo la versión final, la mejora de rendimiento habla por si misma, aunque todavía hay un pequeño judder causado por el frame-rate variable, efecto que se mitiga un poco gracias a la calidad del sistema de motion blur.

14 comentarios

FFXIII ocupa mucho menos en Xbox 360

March 2nd, 2010

La página web Ve3tro.com ha revelado el tamaño de la instalación NXE al disco duro de los tres DVDs que componen la versión para Xbox 360 de Final Fantasy XIII.

Según dicha web - que ha publicado capturas de pantalla como muestra de ello - el disco uno ocupa 5.9GB, mientras que el segundo y tercero ocupan 5.8GB y 6.6GB respectivamente. Esto suma un total de 18.3GB, cifra muy diferente al total de 39.4GB que ocupa la versión japonesa de PS3, haciendo que la versión para Xbox 360 tenga un tamaño de algo menos de la mitad que la de PlayStation 3.

Hay algunos datos interesantes que se desprenden de esta información. Debido al sistema de protección anticopia, lo máximo que se puede utilizar en un DVD de Xbox 360 son 6.8GB, lo cual significa que contando los tres discos Square Enix ha dejado de usar 2.1GB que tenía disponibles, así que esperamos que las omisiones que la versión para Xbox 360 sean mínimas, sino inexistentes.

El menor tamaño de FFXIII se puede explicar fácilmente con el uso de una compresión más agresiva en las numerosas secuencias CGI que componen el juego. Del total de 39.4GB que ocupa la versión japonesa de FFXIII en PS3, un vistazo rápido a la estructura de datos del Blu-ray sugiere que 32.6GB están dedicados exclusivamente a las secuencias de vídeo, mientras que los 6.8GB restantes se usan para el resto de apartados.

Pese a que tener todo el juego en único disco es obviamente beneficioso, la versión para Xbox 360 tiene cambios mínimos de disco, debido a la naturaleza lineal del propio FFXIII. Pocas localizaciones son revisitadas, así que hay poca necesidad real de instalar el juego en el disco duro, a no ser que sea para evitar el molesto ruido del lector DVD de Xbox 360.

En términos de otros elementos a comparar, las versiones occidentales del juego siguen estando bajo embargo. La comparativa definitiva de Digital Foundry al respecto se publicará cuando se levante el embargo la semana que viene.

2 comentarios

Digital Foundry vs. el ApocalyPS3

March 2nd, 2010

Se acabó el pánico. De forma tan repentina como se estropearon, las consolas PlayStation 3 "fat" de todo el mundo han vuelto a la vida, puesto que sus relojes internos han pasado sin problemas al 1 de marzo de 2010. Sony puede respirar tranquila: no se necesitará un parche o una actualización de firmware (por ahora, al menos) ni tampoco habrá que reparar grandes cantidades de consolas, con el brutal coste económico que eso conllevaría. Todo se queda como estaba antes; todo vuelve a la normalidad.

Pero, ¿qué es lo que realmente ha pasado? ¿ocurrirá otra vez? A lo largo de la debacle, Sony se ha referido a ella de forma errónea como un problema de "conectividad de red", y echó la culpa exclusivamente a la pobre PSN.

Pero a medida que los jugadores iban compartiendo su experiencia y se unían en diferentes foros se hizo patente que el problema era mucho más serio: las consolas que estaban desconectadas de internet también mostraban el mismo problema que las que accedían a la PSN. El error no tenía nada que ver con el servicio online, sino que estaba causado por una pieza específica del hardware que PlayStation 3 tiene en su interior.

El reloj interno de PS3 se encuentra totalmente invisible al usuario final y se usa para sincronizar con la PSN, así como para marcar temporalmente los trofeos y los certificados de activación del contenido descargable. Ayer, con ese reloj interno configurado en un día que no existía debido a una confusión con los años bisiestos, la mayoría de juegos con soporte para trofeos no funcionaban ni online ni offline, no se podía acceder a la PSN y los certificados de activación para el contenido descargado se invalidaron. Los afectados se encontraron con una consola que no podía reproducir videojuegos.

A primera hora de la tarde de ayer, usuarios de PS3 en la red IRC #Efnet aseguraron haber encontrado el problema. Una pequeña CPU ARM Syscon dedicada a tareas menores en la PS3 es conocida por tener un problema con los años bisiestos. Ese mismo chip tiene una historia detrás: es el mismo que ha causado problemas similares en dispositivos como los Zune o algunas Blackberry. En aquellos casos, Microsoft y RIM supieron actuar con diligencia. Sony, desgraciadamente, no.

La verdad es que la solución del problema era relativamente fácil. Al igual que ocurre con las placas base de PC que exhiben problemas en la memoria de la CMOS, el ApocalyPS3 se podía solucionar abriendo la consola, quitando la pila con forma de botón y dejando que la energía se disipara de forma interna. Si diez minutos después volvías a poner la pila y cerrabas la consola todo volvía a la normalidad. Genial si tienes la suficiente confianza en ti mismo como para abrir un sistema electrónica y tienes los destornilladores Torx necesarios para desmantelar la PS3. No tan genial si eres un simple jugón, o si quieres mantener la garantía (si tu PS3 "fat" todavía tiene garantía, claro).

Ahora mismo el problema se ha solucionado solo y Sony puede introducir cuando quiera un parche para el controlador ARM en una futura actualización de firmware. Internamente, seguro que la compañía está aliviada de haber esquivado la bala. Una recopilación no-oficial hecha por la comunidad muestra que de once modelos de PS3 disponibles en el mercado, ocho de ellos usan el chip con bug, resultando en una cantidad inmensa de usuarios afectados.

PS3 SKU ¿Afectada por el bug del ApocalyPS3?
CECHA01
CECHA01
CECHC04
CECHE01
CECHG01
CECHG04
CECHH01
CECHK01
CECHK04
CECHL01 No
CECHL04 No
CECHP01 No

Esto no son solo miles o decenas de miles de unidades, son con total seguridad varios millones a nivel mundial. Aunque con una actualización obligatoria de firmware se podía solucionar el problema, es difícil pensar en cómo podría haber manejado la situación Sony si muchas de ellas estuviesen en casas sin conectividad a internet.

Por suerte no se han necesitado medidas desesperadas. Enciende tu PS3 y todo vuelve a la normalidad. El tipo gordo de YouTube puede seguir "owneando noobs" y aquel usuario del blog europeo de PlayStation puede revisar su estimación sobre que el ApocalyPS3 era el equivalente al "11 de septiembre multiplicado por mil". De todas formas, lo más preocupante de todo este asunto fue la falta de información fiable o útil por parte de la propia Sony.

Aunque indicaron que los usuarios del modelo Slim estaban a salvo en su post inicial del blog, nunca reconocieron que las consolas offline también fallaban. Las actualizaciones prometidas en el Twitter de Sony fueron escasas, y tampoco ofrecían información que resultara de alguna utilidad.

Aunque la causa real del problema era de dominio público a media mañana, Sony instó a los usuarios a no "creer información sobre este asunto a no ser que provenga de una fuente oficial de Sony", pero fueron incapaces de dar información útil hasta media tarde, cuando ya se había confirmado que el causante del problema era el reloj interno. La falta de información y la ambigüedad de la que dieron sobre la raíz del problema o cómo arreglarlo es decepcionante, por decir algo suave.

Claramente hay lecciones que aprender de todo este episodio, y será interesante ver cómo maneja Sony la resaca de todo este incidente.

21 comentarios

Geohot, más cerca de piratear la PS3

February 22nd, 2010

El hacker del iPhone, George Hotz, dice haber prosperado respecto a sus primeros intentos de piratear la PS3 y reconoce que ahora ya tiene acceso completo a GameOS, la parte de la consola donde se ejecuta el XMB y que opera una capa por debajo del código del juego.

"Creo que esto supera el último obstáculo técnico respecto al hack de la PS3", ha escrito Hotz en su blog.

El hack original de Geohot para PS3 se concentró en el ataque y el análisis en el llamado "Hypervisor" del chip Cell, el código "guardián" encargado de supervisar las operaciones generales del sistema y de prevenir los ataques que siguen comprometiendo a la PSP.

Sin embargo, y a pesar de la gran cobertura mediática de los logros de Hotz, no han parado de surgir dudas sobre su utilidad debido a que las técnicas principales de encriptación de la PS3 seguían siendo seguras.

La PlayStation 3 dedica un SPU entero a desencriptar código y las claves de desencriptación nunca entran en la RAM principal, haciendo imposible obtenerlas utilizando la típica técnica de volcado de memoria. Pero en OtherOS, con Linux instalado y su exploit activo, Hotz tenía un sistema mucho más vulnerable a su disposición.

"En OtherOS, los 7 SPUs están parados", explica Hotz. "Puedes decirle a una SPU (y lo dejaré como un ejercicio para el lector) que cargue metldr, de esa carga a otra carga de tu elección, y de ahí desencriptar lo que elijas, todo desde PKGs hasta SELFs. Incluyendo las de futuras versiones".

Los SELFs se describen mejor cuando decimos que son los equivalentes de la PS3 a los .EXE de PC —contienen código de juego, mientras que los PKGs son los contenedores en los que se entregan las instalaciones de juegos, juegos de PSN y DLC. Piensa en ellos como ficheros ZIP encriptados. Podemos asumir que "metldr" es el código que la PS3 utiliza para lanzar la SPU de seguridad dedicada a desencriptarlos.

Aunque no lo ha confirmado públicamente, se cree que Geohot no sólo ha establecido su desencriptador basado en Linux, si no que también ha desencriptado GameOS, elevando las posibilidades de que se pueda parchear el firmware de la PS3 para ejecutar código homebrew directamente desde el XMB.

Hotz en persona admite que nunca escribiría código para permitir directamente la piratería, y mientras se han hecho intentos para mejorar el primer hack, de momento todo es bastante caótico.

En resumen, si algo sale de esto, es muy posible que Sony haga intentos de actualizar su firmware para evitar el hack.

Es una incógnita cómo responderá Sony. En un hilo publicado en los foros de la comunidad YellowDog Linux, un empleado de Fixstar —la empresa responsable del codificador acelerado por Cell CodecSys h264— reconoce que ha escuchado de una "fuente fiable" que OtherOS podría quitarse de la PS3 en su próxima actualización.

Sin embargo, este post se ha eliminado, y todo el asunto al respecto de quitar OtherOS suena muy poco amigable hacia el consumidor.

Lo más probable es que Sony actue para cerrar el agujero de Geohot de una forma elegante, reduciendo el número de consolas susceptibles al hackeo a medida que la gente actualiza su firmware.

6 comentarios

La técnica anti-aliasing de The Saboteur

December 11th, 2009

Si hay un elemento que hemos visto numerosas veces en las comparativas multiplataforma que hemos hecho hasta ahora es, sin duda, la implementación de técnicas de anti-aliasing en la actual generación de consolas HD.

El caso más habitual es que la versión para Xbox 360 de un juego tenga suavizado de bordes, mientras que la versión para PlayStation 3 lo desactive por completo, sea menor o use la técnica Quincunx específica de nVidia, la cual suaviza los bordes pero también "emborrona" toda la textura en el proceso.

Ninguna de estas opciones es particularmente atractiva (aunque el Quincunx tiene su utilidad en determinados escenarios), y tampoco lo es hacer que toda la pantalla sea más borrosa, como hacen algunos desarrolladores (lo que en DF llamamos "el efecto vaselina"). Pero en juegos recientes, como Brütal Legend o Overlord II, se han intentado aplicar otras técnicas - buscar sólo los bordes y hacerlos más borrosos, manteniendo el detalle de la textura. Es mejor que nada, pero no es suficiente.

La versión para PS3 del The Saboteur de Pandemic es diferente. Es especial. Intenta algo nuevo que nunca habíamos visto en una consola o en un PC, y los resultados son espectaculares. En el mejor de los casos se obtiene un suavizado de bordes mejor que en el anti-aliasing 16x multisampling, produciendo un efecto mejor que el conseguido con GPUs de gama alta pero sin comprometer el rendimiento. Compáralo, por ejemplo, con el máximo del hardware de Xbox 360: 4x MSAA.

Empecemos con una rápida comparativa del efecto en ambas versiones del juego. Es interesante dejar claro que tanto la versión para Xbox 360 como PC de The Saboteur no tienen ningún tipo de soporte para anti-aliasing. Es algo exclusivo para los poseedores de la versión de PS3, cuya razón explicaremos más adelante. Aunque la total ausencia de AA en la versión para Xbox 360 es decepcionante, a efectos de este artículo nos beneficia para poder ver un antes y un después que ilustre mejor la técnica aplicada en PS3.

¿Cómo lo han hecho? En los comentarios de un post del PlayStation Blog americano, Tom French, de Pandemic, habla sobre "usar las SPUs para hacer un filtrado FSAA a pantalla completa". Los procesadores satélite del Cell son perfectos para hacer cálculos rápidos de pequeños grupos de datos, lo cual hace que sean ideales para la tarea de procesar todo el framebuffer en busca de bordes y a continuación suavizarlos.

Algunos usuarios del foro de Beyond3D no tardaron en empezar a investigar. Es una técnica inicialmente impulsada por Intel, que se explica de forma excelente en varios ejemplos de este post, el cual muestra el potencial real de esta técnica, y cómo se compara con el método de Brütal Legend de suavizado de bordes. No hay punto de comparación: el denominado anti-aliasing morfológico (o MLAA) visto en The Saboteur está a años luz de todo lo que hemos visto cuando se usa en condiciones óptimas.

Al ser una técnica experimental no todo es perfecto. Cuando los bordes en el juego tienen un ancho de un pixel o menos, la técnica de detección no acaba de funcionar. Pandemic analiza el framebuffer al completo - incluyendo los elementos del HUD - lo cual provoca artefactos en la superposición de los textos. En este juego probablemente es inevitable: cuando la GPU empieza a dibujar el siguiente frame, las SPUs están ocupadas con el AA, y para que se de esa situación hay que analizar el frame al completo.

Pandemic no ha hablado demasiado sobre la técnica de AA, aunque sus desarrolladores han filtrado algunos detalles en los foros de NeoGAF. Según ellos, el filtro se aplica a la luminosidad de cualquier escena. Es una forma muy inteligente de mantener la velocidad pero, al mismo tiempo, algunos colores - rojo y negro, por ejemplo - tienen niveles similares de luminosidad, con lo cual el filtro detecta la mayoría de los bordes pero pierde otros. Adicionalmente, en algunos casos se producen problemas de "pelusa" en los bordes, lo cual sin más aclaraciones de los desarrolladores son difíciles de explicar. ¿O quizás es simplemente el efecto de procesar una pantalla con motion blur?

Lo que tenemos en The Saboteur para PS3 es una técnica experimental, y puedes hacerte una idea de que el estilo visual se adapta de forma excelente a ella. En la versión para Xbox 360 la cantidad de jaggies no es un problema grave; el juego no tiene demasiado alto contraste entre bordes, y es bastante suave en general. En este tipo de entorno, la técnica MLAA usada por Pandemic funciona de forma excelente, y en la mayoría de los casos hay que fijarse mucho para encontrar artefactos en la imagen. Pero están ahí, y eso lleva a preguntarse cómo funcionaría esta técnica en juegos con un contraste más alto, tipo Battlefield: Bad Company 2, Halo 3 o Uncharted 2, en los que seguramente hubiese tenido problemas.

Pero lo que tenemos aquí es algo nuevo y realmente emocionante desde un punto de vista técnico. Asistimos a cómo la PS3 ataca al problema con un método que ni siquiera las GPUs de gama más alta están usando. No puedes evitar preguntarte si el MLAA, en combinación con MSAA y un filtro para eliminar los artefactos, podría ser integrado en el hardware de la próxima generación de consolas.

También será interesante ver si el MLAA vuelve a aparecer en otro juego PS3 multiplataforma antes de eso, porque parece extremadamente bueno en acción. Al final todo se limitará a lo costosa que sea a nivel computacional la técnica, y si se puede refinar más. Ahí es donde ya no sabemos más. Si algún ex-trabajador de Pandemic quiere arrojar algo de luz al respecto, ya sabe dónde encontrarnos...

15 comentarios

Call of Duty Wii: ¿Guerra no tan moderna?

November 11th, 2009

Bien, Call of Duty: Modern Warfare Reflex para Wii. La mera idea de portar uno de los shooters más avanzados de las consolas HD a la plataforma de Nintendo suena cuanto menos atrevida, pero en Activision (junto al estudio de desarrollo Treyarch) se han atrevido a hacerlo y el resultado es una agradable sorpresa. Los usuarios de Wii se encontrarán con una versión sorprendentemente fiel del original, incluyendo modos online y nuevos controles gracias al Wiimote que no habíamos experimentado hasta ahora.

Portar Modern Warfare a Wii no es una idea tan descabellada como puedas pensar inicialmente, por diferentes razones. La primera es que el núcleo del motor de Modern Warfare todavía tiene gran cantidad de código de la tecnología de Quake, herencia directa de las primeras entregas de la saga Call of Duty. La construcción de los niveles de Modern Warfare tiene pocos elementos que cualquier shooter de la anterior generación no pueda igualar, y esto se manifiesta con la calidad de la conversión del juego a Wii.

A nivel de contenido más o menos todo se mantiene. Compáralo con las nuevas fases de Modern Warfare 2, con streaming y decompresión de datos al vuelo desde el disco - proporcionando una escala nueva vista en la franquicia, algo casi imposible de replicar en Wii sin un buen trabajo de re-ingeniería.

En algunos círculos de desarrolladores existe la creencia de que portar un juego de Xbox 360 a Wii es realmente mucho más fácil que desarrollarlo para PS3 (cambia PS3 por 360 si quieres, la idea es la misma). Esencialmente, en un mercado que exige la paridad entre los juegos para consolas HD, el esfuerzo necesario para conseguirlo es exhaustivo teniendo en cuenta lo diferente que son ambas arquitecturas. Al portar un juego a Wii, los desarrolladores no tienen tanta presión - hay carta blanca para reducir o eliminar lo que deseen, mientras el resultado final tenga buena aspecto y se pueda jugar.

Eso es exactamente lo que Treyarch ha hecho con Modern Warfare. El detalle de las texturas y los niveles de geometría se han reducido de forma drástica, los efectos de iluminación y sombras se han limitado , el frame-rate se ha reducido de 60FPS a unos más llevaderos 30FPS (e incluso así tiene ciertos problemas para mantenerlo en algunos tiroteos). El modelo de iluminación se ha ajustado hasta el punto en que la sección con gafas de visión nocturna de la misión The Bog es superflua - pese a que el juego te anime a activar las gafas, todo es tan brillante que en realidad no las necesitas.

Gráficamente Reflex es funcional, con el aspecto con el que imaginarías una versión para PS2 realizada por un desarrollador razonablemente competente, pero dejemos las cosas claras: no se ve como, por ejemplo, el Black de PS2. Pese a todo, echa un vistazo a la comparativa con la versión de PS3 y verás que pese a todos los sacrificios realizados, hace un buen trabajo para mantener el look y la ambientación del juego original.

Reflex opta por una estrategia jugable muy diferente a la de sus hermanos en HD. Infinity Ward se enorgullece del control con latencia ultra baja y opta por una tasa de 60FPS para conseguirlo. Con la reducción a 30FPS, esta respuesta queda comprometida, pero la versión para Wii es muy diferente al control creado por Infinity Ward.

Al cambiar el pad por el Wiimote (sin soporte para Motion Plus), la falta de 60FPS no afecta demasiado, teniendo en cuenta la latencia adicional al cambiar el controlador estándar por el uso del mando de Wii. Mover tu brazo provoca mucho más lag que usar dedos y pulgares en un pad tradicional - aunque apuntar con el Wiimote debería ser más instintivo, y deberías poder disparar a los enemigos más rápido.

El movimiento y apuntado en Wii funciona de forma similar a The Conduit, y hay momentos en los que Reflex realmente parece genial. Correr a través del campo de batalla, disparando desde la cintura, es algo que funciona perfectamente porque puedes disparar a donde quieras, sin que ello afecte la dirección en la que corres - algo que no se puede hacer tan fácilmente en PS3 o 360. De forma similar, el proceso de usar la mirilla, la mira telescópica del rifle o tirar una granada cambia por completo. Si el objetivo en estos modos es aumentar la precisión y el control, sin duda esto se consigue gracias al uso del puntero por infrarrojos del Wiimote.

De todas formas, la extraña configuración de los botones en el mando hace que las cosas sean difíciles para otra cosa que no sea correr y disparar a la vez, y es aquí donde el esquema de control muestra sus carencias. Tirar granadas y bengalas con el botón + y - obliga a reposicionar los dedos de forma patosa en el Wiimote - echar el brazo hacia atrás para lanzar una granada es particularmente molesto. Colocar el cuchillo en la dirección hacia abajo del d-pad también elimina la noción de tener un acceso instantáneo para eliminar enemigos cercanos, dado el tiempo que se necesita para mover el dedo a esa posición. Pero lo más importante, todavía existe la sensación de que simular el movimiento de la cabeza apuntando a los extremos izquierdo y derecho de la pantalla no es algo natural.

Pese a todo, cuando funciona realmente vale la pena, y hace que te preguntes que tipo de implementación veremos con el mando con sensor de movimiento de Sony. Si el sistema de head-tracking con la PlayStation Eye (algo que veremos en GT5) funciona bien con muy poca latencia, podría solventar el tema de la visión. Eso, combinado con la precisión extra del controlador de Sony, podría marcar la diferencia. ¿Una versión parcheada con sensor de movimiento de Modern Warfare para PS3? Eso es algo que, desde luego, nos encantaría ver.

2 comentarios

God of War III: Análisis de rendimiento de la demo

November 4th, 2009

Con un peso de unos 2.6GB, la demo del E3 de God of War III es una de las demostraciones más apetitosas que hemos tenido últimamente. La larga descarga realmente vale la pena, juzgando por la cantidad y profundidad del contenido que ofrece. Hay tanto, de hecho, que hemos tenido que repartir nuestro análisis en vídeo en dos partes, con tan solo unas pequeñas ediciones.

La primera parte cubre lo que se mostró durante la conferencia de prensa de Sony en el E3, mientras que la segunda muestra lo que viene después - y es justo cuando se vuelve más más interesante, mostrando su mejor cara a nivel tecnológico. Si ya has visto muchas veces los vídeos del E3, entonces quizás sea mejor que saltes directamente al segundo vídeo.

Así que empecemos con la primera parte. Lo que comentamos en nuestro análisis de la demo del E3 sigue teniendo validez hoy, aunque es importante aclarar lo limpio que es God of War III, algo que no es tan evidente al ver vídeos colgados en internet con diferentes grados de compresión.

El trabajo realizado con las texturas es extraordinario, los efectos especiales se usan de forma sutil y reservada y la iluminación es ejemplar. El juego parece usar un anti-aliasing 2x multisampling, pero tal y como ocurría con Killzone 2, la paleta de color utilizada ayuda a maquillar el efecto de suavizado de bordes.

Es durante la segunda parte cuando el variado rango de efectos creado por el estudio de Santa Monica se hace evidente. La iluminación por píxel, en combinación con las texturas de alta calidad, produce unos efectos espectaculares (por ejemplo en el mármol). El efecto de profundidad de campo funciona y tiene un aspecto soberbio, y el filtrado de texturas también es de excelente calidad. Los únicos puntos negativos son algunos bordes con pocos polígonos y los buffers alpha reducidos, aunque el impacto global en la calidad de imagen no supone ningún tipo de problema.

¿Y qué pasa con el frame-rate? Sí, es código del E3. Sí, seguramente ocurra que la versión final mejore lo que vemos en esta demo. Pero la verdad es que el rendimiento es intrigante. God of War III tiene v-sync (así que no hay tearing), y basándonos en nuestra partida tenemos una media de 36.81FPS, un mínimo de 24FPS y un máximo de 56FPS.

La media del frame-rate normalmente no suele ser demasiado útil, pero aquí es una buena indicación del rendimiento global a lo largo de la demo, lo cual es curioso. Bloquear el juego a 30FPS hubiese producido un apartado visual más consistente, así como unos controles más fiables y predecibles, y un mejor judder en pantalla en movimientos panorámicos de cámara.

Pero en general, y pese a pequeños detalles, esta demo es algo francamente bueno, y que se publique pocas semanas antes que la demo incluida en God of War Collection es curioso. ¿Será la misma demo del E3 incluida en el paquete en forma de código descargable? ¿Ha tenido esta vez Europa la "exclusiva"?

8 comentarios

GTAIV: 15 días en Liberty City

November 4th, 2009

Teníamos en mente publicar este artículo desde hace meses, pero el reciente lanzamiento de Grand Theft Auto IV: Episodes from Liberty City hace que hoy sea el día perfecto para hacerlo - no sólo porque el nuevo contenido es genial, sino por homenajear de cierta forma al que sigue siendo el mejor mundo abierto jamás creado para consolas.

Sentarte en el sofá y ver como el mundo de GTAIV avanza es una experiencia en si misma, y el rango de comportamientos que muestran los habitantes del mundo es absolutamente fenomenal. Beben café al ir a trabajar, se sientan y leen el periódico en bancos, calientan al salir a correr, abren el paraguas o corren a resguardarse cuando llueve y se muestran claramente molestos cuando un coche está a punto de atropellarlos.

Algunos de ellos fuman, otros no... incluso se pelean entre ellos en ciertas ocasiones. Combínalo con el movimiento realista de todos y cada uno de los vehículos, con el genial sistema de iluminación y con la soberbia ejecución de los diferentes tipos de condiciones meteorológicas y al final no puedes sino quitarte el sombrero ante semejante logro tecnológico.

La atención del jugador se centra en la propia acción del juego, y la ciudad que ha creado Rockstar North pasa a ser un trasfondo secundario, algo que maquilla lo lejos que está la tecnología de GTAIV de la del resto de juegos. Crear y programar algo como Liberty City tiene que ser una tarea titánica, pero junto a la jugabilidad pasa a ser un segundo plano de la historia de Niko - o la de Johnny Klebitz o Luis López.

Han habido muchas quejas de que el juego tiene un control con cierto retraso, o que el frame rate es variable y a menudo decepcionante. La verdad es que discutir eso es difícil, especialmente cuando otros juegos basados en mundos abiertos mantienen su frame rate sin problemas. De todas formas, es importante recordar que aparte de todo lo que hemos descrito, Liberty City es una creación como ninguna otra.

Juegos como Prototype o Crackdown pueden hacer streaming y descomprimir datos fácilmente en comparación, gracias a la gran repetición de elementos gráficos, texturas compartidas y geometría más simple. No solo eso, sino que los desarrolladores pueden crear el escenario como quieran para igualar los límites de su tecnología. GTAIV, en cambio, intenta recrear la ciudad de Nueva York, con todos los retos que eso representa.

Hablando de retos, crear este vídeo no ha sido un camino de rosas. Para empezar necesitamos una técnica para mantener la vista en primera persona sin que el juego saltase al modo espectador. Lo solucionamos gracias al teléfono con cámara que consigues una vez avanzado en la historia. Después, la captura. El ciclo de día y noche de GTAIV dura unos 50 minutos en tiempo real, y capturamos cerca de 45 vídeos a un frame por segundo durante el transcurso de diez días, de los cuales no todos pasaron el corte.

Aunque en nuestros anteriores vídeos de time-lapse simplemente hicimos un fading entre los ciclos de día y noche, con este fuimos un poco más lejos. Gracias al reloj del teléfono móvil de Niko, pudimos editar conjuntamente 15 días de tiempo de juego - por completo - cubriendo 35 lugares diferentes de Liberty City.

Este es nuestro homenaje a un excelente logro técnico que hasta ahora ningún otro juego basado en un mundo abierto ha podido igualar, y que provoca una gran curiosidad por ver qué será lo que ofrecerá Rockstar en el próximo e inevitable GTA. Con la tecnología ya creada (y, esencialmente, sin ningún rival a la altura), ¿los desarrolladores se centrarán en la creación de contenido? ¿o quizás crearán una versión todavía más avanzada de este increíble motor?

6 comentarios

Left 4 Dead 2: Análisis de rendimiento de la demo

November 2nd, 2009

Junto con las secuelas de Assassin's Creed y Modern Warfare, el Left 4 Dead 2 de Valve es seguramente uno de los juegos más esperados del año para los usuarios de Xbox 360. Pese a que de momento sólo está disponible para los americanos que realizaron la reserva del juego, hemos conseguido hacernos con ella para someterla a nuestra habitual batería de pruebas. Esta es la primera vez que hemos podido probar el juego en Digital Foundry, y las impresiones generales son realmente buenas.

La demo contiene una buena muestra de lo que podremos jugar en la versión completa. Con un peso de 1.6GB, la descarga ofrece dos niveles de The Parish, en modo individual y multijugador online. De forma similar a la primera parte, la CPU toma el control de tus tres compañeros cuando no hay otros jugadores humanos para controlarlos. Puedes probar una buen variedad de armas de fuego, cócteles Molotov y granadas, y las tan comentadas armas tipo melee. En total hay entre 20 y 30 minutos de juego, aunque para el análisis de frame rate que publicamos a continuación lo hemos editado a seis minutos.

Desde una perspectiva técnica, el frame rate es bastante sólido (30FPS con alguna que otra caída), y, al igual que en otros juegos basados en el motor Source, el apartado gráfico corre a 720p, con v-sync y sin anti-aliasing. Para suavizar un poco los bordes se ha añadido un sutil efecto de blur. Este tipo de efectos de post-proceso no suelen funcionar demasiado bien, pero en este caso al estar complementado por el blur de movimiento de la cámara el efecto no distrae tanto. Como aspecto positivo, comentar que el filtrado de texturas consiste en una buena combinación entre filtrado trilinear y anisotrópico.

Cuando el rendimiento se resiente, sin duda lo hace por culpa del fill-rate. Las mayores caídas de frame rate se observan cuando hay muchos efectos de transparencia en juego. Aunque el motor Source parece haberse diseñado para sacar el máximo fill-rate posible, el uso de humo y niebla necesita usarse con cuidado - la geometría que se superponga a la transparencia puede arruinar el efecto, así que el motor debe estar continuamente comprobando que eso no ocurra.

También da la sensación de que algunos efectos alpha se generan a una resolución mucho menor para luego ser reescalados, algo que se nota sobretodo en los efectos de las llamas en la demo (algo que se observa en la captura del vídeo anterior). Es una técnica muy común que sobretodo se usa en los juegos de PS3, en los que el ancho de banda de la GPU es un bien muy preciado, pero es tan buena que puede usarse en otras plataformas sin que el usuario llegue a percatarse de ello.

En general, hay muy pocas sorpresas: el motor Source en 360 parece seguir estando a la altura con esta secuela. Si quieres saber un poco más sobre el proceso de Valve para adaptar la tecnología de PC a multiplataforma, esta presentación para la GDC 2008 es fascinante, no sólo por la información que incluye sino por el uso estratégico de las fotografías.

8 comentarios

Publicidad