Hablemos del interior de Xbox One

marjalone escribió:entonces que le decimos a este tio , que es un vago ?

hilo_el-productor-de-sniper-elite-3-habla-sobre-los-desafios-de-trabajar-con-la-esram-de-xbox-one_1982300

Gamerlol escribió:

marjalone escribió:entonces que le decimos a este tio , que es un vago ?

hilo_el-productor-de-sniper-elite-3-habla-sobre-los-desafios-de-trabajar-con-la-esram-de-xbox-one_1982300

Han explicado por activa y por pasiva en este hilo en los últimos días cosas sobre la ESRAM, cuellos de botella, DX12 y DX11, etc.

El productor de Sniper Elite no sé si será un vago, pero no lo seas tu y haznos el favor de leerte las últimas 20 páginas como mucho.

A ver si esto sigue avanzando por gente como @darksch y vas a venir tu a convertir esto en el día de la marmota.

Zokormazo escribió:

papatuelo escribió:

Zokormazo escribió:Bienvenido?,si estaba posteando la mar de normal y han venido a acribillarle

Si realmente conoces a este señor, tienes muchisima cara para soltar eso...

No tengo ni idea de quien es, ni le he leido antes.

Pero hoy y aqui no ha dicho nada raro ni fuera de lugar. En cambio otros han venido a invitarle a abandonar el foro cual mafia que va pidiendo cuota.

darksch escribió:

"El hecho de que Xbox One tenga a menudo juegos de menor resolución se debe a que los desarrolladores para llegar a los 1080p tienen que hacer un poco más de código específico para la consola de Microsoft, y todo el mundo tiene prisa para lanzar el juego, así que no lo hacen". Menudo zasca a los astroturfers

Y tanto, con motores deferred de mierda.
Intentaré explicar el porqué y la ventaja de motores basados en tiles para la arquitectura de Xbox One. No basándome en documentos oficiales pero sí en cómo sabemos que funcionan las cosas.

Tenemos la eSRAM, cuya principales funciones son: tiled-framebuffer, cache-resources y computing. Por puntos:

- Tiled-framebuffer: cuando renderizar todo en un buffer completo de una sola vez está claro que no cabe en la eSRAM. El renderizado es algo muy costoso en cuanto a ancho de banda se refiere, múltiples pasadas, uso de varios buffers al mismo tiempo para llegar a un resultado, etc. Al final para generar una imagen resultado has tenido que usar muchísimo ancho de banda. Si el framebuffer no te cabe en eSRAM tienes que alojar parte en la DDR3, la cual no está pensada para eso si quieres alto rendimiento. SIN EMBARGO, usando un motor de renderizado tiled, tan sólo necesitamos ocupar en la eSRAM un pequeño espacio, del tamaño del tile x el nº de buffers usados x 2 (mínimo). Renderizamos TODO sobre la eSRAM, y al terminar, el RESULTADO que es sólo el color buffer lo transferimos a la DDR3 (incluso gratis y en paralelo usando un DMA), mientras vamos renderizando el siguiente tile, de ahí el 2 como mínimo, podrían ser 3 o más dependiendo del buffering que querramos reservar, por si renderizar el siguiente tile llevara menos que transferir el anterior a la DDR3, cosa rara pero bueno. Pues bien, el color buffer tenemos que ocupa, para un resultado de 1920x1080x32bpp tan sólo 8MB por frame. Esto son 480MB/s en un juego a 60 fps. ¡Oh, vaya, de repente el ancho de la DDR3 ya no es un problema de cara al framebuffer!.

- Cache-resources: usando tiled resources se necesita mucho menos espacio, y al mismo tiempo usando un motor tiled, resulta que para renderizar un tile de pantalla estamos usando los recursos tiled del tiled, no sé si me explico, sólo nos traemos una parte de los recursos (tiled) de un solo trozo de pantalla (tile). Eso deja el espacio necesario muy pequeño en la eSRAM. Bien, pues resulta que de la DDR3 sólo haremos la 1ª lectura, ya que al hacerlo ese recurso ya lo hemos cacheado en la eSRAM, y todos los sucesivos samples se harán sobre la eSRAM. Entonces para establecer el filtrado de texturas sólo estaremos limitados por la GPU y no por el ancho de banda. Nótese que en la plataforma supuestamente más potente esto no puede hacerse, y de hecho el filtrado dependerá también del uso que la CPU y otros componentes (sonido, etc.) hagan del bus y del ancho de la memoria principal, es decir, lo que le dejen. En XOne esto funciona como vemos de una forma autónoma y no dependerá del resto salvo por únicamente la 1ª lectura del recurso, luego ya se cachea. Por lo tanto en realidad es como si de la DDR3 se leyera para poner un filtrado POINT, porque sólo lees los datos una vez, a partir de ahí cada sample nuevo de cada filtrado superior se haría sobre la eSRAM. Resulta que si no usas ni tiled resources ni tiled rendering, esto no podrás hacerlo igual porque no te cabrá en la eSRAM los recursos y tendrás que acudir más a menudo a la DDR3 para hacer samples.

- Computing: se sabe que el mayor enemigo de la computación GPGPU es la latencia de la memoria. LA eSRAM por ser de tipo SRAM de eso anda más que bien. La computación requiere no muchos datos en cuanto a tamaño, por lo que el espacio que quede en eSRAM usando los 2 puntos anteriores + el uso de DMA para ir alimentando es más que suficiente para mantener a la GPU ocupada con su capacidad de computación.

Eso sí, de todo esto iros olvidando en motores anticuados que no hagan uso de ninguna técnica moderna. Lo que se suele hacer es meter en eSRAM el trozo que quepa, y el resto a la DDR3, y ea que tire eso como pueda. Mientras que usando tiles ahí está como ejemplo FH2, que cuando lo bajamos a 30 fps nos sobra tanto que podemos activar un 4xMSAA para no desperdiciarlo, vamos que van sobrados de GPU para dibujar. Curioso cuando en la supuestamente más potente, para activar el 4xMSAA a 30 fps han tenido que bajar la resolución a 1920x800.

Algunos pedían que la eSRAM hubiera sido de 64MB, eso es imposible es muy costosa y su función no es sustituir a la VRAM. Es como pedir que las CPU les metan 8MB de caché L1 en lugar de caché L2 que seguro así corre más. Nos ha jodido pero y lo caro que es, además la función de la caché no es sustituir a la RAM.

Se podría decir que la XOne se diseñó "parcialmente incompatible" con motores antiguos, de cara a optimizar el desarrollo de motores que usaran las técnicas nuevas ya presentadas en 2012.

Ferdopa escribió:Jur...

Bueno, pues como me gusta probar las cosas por mí mismo (siempre que se pueda) he hecho la prueba de Star Swarm.

Primero, los resultados de D3D (DX11) y luego los de Mantle. Pongo el porcentaje de diferencia a su lado.

== Results ==========================
Test Duration: 360 Seconds

Total Frames: 11087 20415 +84%

Average FPS: 30.79 56.71 +84%
Average Unit Count: 3983 4561 +14%
Maximum Unit Count: 5530 5969 +8%
Average Batches/MS: 532.65 899.84 +69%
Maximum Batches/MS: 970.08 3793.01 +290%
Average Batch Count: 18173 17429 -6%
Maximum Batch Count: 138026 101261 -27%


Si DX12 es superior a Mantle como afirma MS... no habrá excusa para los desarrolladores a la hora de aprovechar cualquier tipo de hardware.

Un saludo.

Zokormazo escribió:Ayer danix2 andsbs tmb de pruebas y se encontro resultados raros. Sus pruebas intentando emular el hard usado por anandtech daban resultados contradictorios xD

eloskuro escribió:

Zokormazo escribió:Ayer danix2 andsbs tmb de pruebas y se encontro resultados raros. Sus pruebas intentando emular el hard usado por anandtech daban resultados contradictorios xD

No tenia acceso a los mismos drivers beta de anandtech

darksch escribió:

"El hecho de que Xbox One tenga a menudo juegos de menor resolución se debe a que los desarrolladores para llegar a los 1080p tienen que hacer un poco más de código específico para la consola de Microsoft, y todo el mundo tiene prisa para lanzar el juego, así que no lo hacen". Menudo zasca a los astroturfers

Y tanto, con motores deferred de mierda.
Intentaré explicar el porqué y la ventaja de motores basados en tiles para la arquitectura de Xbox One. No basándome en documentos oficiales pero sí en cómo sabemos que funcionan las cosas.

Tenemos la eSRAM, cuya principales funciones son: tiled-framebuffer, cache-resources y computing. Por puntos:

- Tiled-framebuffer: cuando renderizar todo en un buffer completo de una sola vez está claro que no cabe en la eSRAM. El renderizado es algo muy costoso en cuanto a ancho de banda se refiere, múltiples pasadas, uso de varios buffers al mismo tiempo para llegar a un resultado, etc. Al final para generar una imagen resultado has tenido que usar muchísimo ancho de banda. Si el framebuffer no te cabe en eSRAM tienes que alojar parte en la DDR3, la cual no está pensada para eso si quieres alto rendimiento. SIN EMBARGO, usando un motor de renderizado tiled, tan sólo necesitamos ocupar en la eSRAM un pequeño espacio, del tamaño del tile x el nº de buffers usados x 2 (mínimo). Renderizamos TODO sobre la eSRAM, y al terminar, el RESULTADO que es sólo el color buffer lo transferimos a la DDR3 (incluso gratis y en paralelo usando un DMA), mientras vamos renderizando el siguiente tile, de ahí el 2 como mínimo, podrían ser 3 o más dependiendo del buffering que querramos reservar, por si renderizar el siguiente tile llevara menos que transferir el anterior a la DDR3, cosa rara pero bueno. Pues bien, el color buffer tenemos que ocupa, para un resultado de 1920x1080x32bpp tan sólo 8MB por frame. Esto son 480MB/s en un juego a 60 fps. ¡Oh, vaya, de repente el ancho de la DDR3 ya no es un problema de cara al framebuffer!.

- Cache-resources: usando tiled resources se necesita mucho menos espacio, y al mismo tiempo usando un motor tiled, resulta que para renderizar un tile de pantalla estamos usando los recursos tiled del tiled, no sé si me explico, sólo nos traemos una parte de los recursos (tiled) de un solo trozo de pantalla (tile). Eso deja el espacio necesario muy pequeño en la eSRAM. Bien, pues resulta que de la DDR3 sólo haremos la 1ª lectura, ya que al hacerlo ese recurso ya lo hemos cacheado en la eSRAM, y todos los sucesivos samples se harán sobre la eSRAM. Entonces para establecer el filtrado de texturas sólo estaremos limitados por la GPU y no por el ancho de banda. Nótese que en la plataforma supuestamente más potente esto no puede hacerse, y de hecho el filtrado dependerá también del uso que la CPU y otros componentes (sonido, etc.) hagan del bus y del ancho de la memoria principal, es decir, lo que le dejen. En XOne esto funciona como vemos de una forma autónoma y no dependerá del resto salvo por únicamente la 1ª lectura del recurso, luego ya se cachea. Por lo tanto en realidad es como si de la DDR3 se leyera para poner un filtrado POINT, porque sólo lees los datos una vez, a partir de ahí cada sample nuevo de cada filtrado superior se haría sobre la eSRAM. Resulta que si no usas ni tiled resources ni tiled rendering, esto no podrás hacerlo igual porque no te cabrá en la eSRAM los recursos y tendrás que acudir más a menudo a la DDR3 para hacer samples.

- Computing: se sabe que el mayor enemigo de la computación GPGPU es la latencia de la memoria. LA eSRAM por ser de tipo SRAM de eso anda más que bien. La computación requiere no muchos datos en cuanto a tamaño, por lo que el espacio que quede en eSRAM usando los 2 puntos anteriores + el uso de DMA para ir alimentando es más que suficiente para mantener a la GPU ocupada con su capacidad de computación.

Eso sí, de todo esto iros olvidando en motores anticuados que no hagan uso de ninguna técnica moderna. Lo que se suele hacer es meter en eSRAM el trozo que quepa, y el resto a la DDR3, y ea que tire eso como pueda. Mientras que usando tiles ahí está como ejemplo FH2, que cuando lo bajamos a 30 fps nos sobra tanto que podemos activar un 4xMSAA para no desperdiciarlo, vamos que van sobrados de GPU para dibujar. Curioso cuando en la supuestamente más potente, para activar el 4xMSAA a 30 fps han tenido que bajar la resolución a 1920x800.

Algunos pedían que la eSRAM hubiera sido de 64MB, eso es imposible es muy costosa y su función no es sustituir a la VRAM. Es como pedir que las CPU les metan 8MB de caché L1 en lugar de caché L2 que seguro así corre más. Nos ha jodido pero y lo caro que es, además la función de la caché no es sustituir a la RAM.

Se podría decir que la XOne se diseñó "parcialmente incompatible" con motores antiguos, de cara a optimizar el desarrollo de motores que usaran las técnicas nuevas ya presentadas en 2012.

darksch escribió:Y tanto, con motores deferred de mierda.
Intentaré explicar el porqué y la ventaja de motores basados en tiles para la arquitectura de Xbox One. No basándome en documentos oficiales pero sí en cómo sabemos que funcionan las cosas.

...

URTYK escribió:Creo que Brad lleva desde 2013 trabajando en un motor nuevo especifico para Directx12 verdad?

enaguas escribió:claro pero esa campaña de potencia vino acompañada de juegos multiplataforma que hacían creer que la otra consola era mucho más potente (cod ghost.etc..)....ya que xbox one salio en pañales...han sido esos juegos los que han abierto brecha y los que han marcado y siguen marcado la opinión de muchos... a parte que el marketing que funciono de verdad a sony fue la desastrosa campaña de presentación que hizo la propia microsoft.

darksch escribió:

"El hecho de que Xbox One tenga a menudo juegos de menor resolución se debe a que los desarrolladores para llegar a los 1080p tienen que hacer un poco más de código específico para la consola de Microsoft, y todo el mundo tiene prisa para lanzar el juego, así que no lo hacen". Menudo zasca a los astroturfers

Y tanto, con motores deferred de mierda.
Intentaré explicar el porqué y la ventaja de motores basados en tiles para la arquitectura de Xbox One. No basándome en documentos oficiales pero sí en cómo sabemos que funcionan las cosas.

Tenemos la eSRAM, cuya principales funciones son: tiled-framebuffer, cache-resources y computing. Por puntos:

- Tiled-framebuffer: cuando renderizar todo en un buffer completo de una sola vez está claro que no cabe en la eSRAM. El renderizado es algo muy costoso en cuanto a ancho de banda se refiere, múltiples pasadas, uso de varios buffers al mismo tiempo para llegar a un resultado, etc. Al final para generar una imagen resultado has tenido que usar muchísimo ancho de banda. Si el framebuffer no te cabe en eSRAM tienes que alojar parte en la DDR3, la cual no está pensada para eso si quieres alto rendimiento. SIN EMBARGO, usando un motor de renderizado tiled, tan sólo necesitamos ocupar en la eSRAM un pequeño espacio, del tamaño del tile x el nº de buffers usados x 2 (mínimo). Renderizamos TODO sobre la eSRAM, y al terminar, el RESULTADO que es sólo el color buffer lo transferimos a la DDR3 (incluso gratis y en paralelo usando un DMA), mientras vamos renderizando el siguiente tile, de ahí el 2 como mínimo, podrían ser 3 o más dependiendo del buffering que querramos reservar, por si renderizar el siguiente tile llevara menos que transferir el anterior a la DDR3, cosa rara pero bueno. Pues bien, el color buffer tenemos que ocupa, para un resultado de 1920x1080x32bpp tan sólo 8MB por frame. Esto son 480MB/s en un juego a 60 fps. ¡Oh, vaya, de repente el ancho de la DDR3 ya no es un problema de cara al framebuffer!.

- Cache-resources: usando tiled resources se necesita mucho menos espacio, y al mismo tiempo usando un motor tiled, resulta que para renderizar un tile de pantalla estamos usando los recursos tiled del tiled, no sé si me explico, sólo nos traemos una parte de los recursos (tiled) de un solo trozo de pantalla (tile). Eso deja el espacio necesario muy pequeño en la eSRAM. Bien, pues resulta que de la DDR3 sólo haremos la 1ª lectura, ya que al hacerlo ese recurso ya lo hemos cacheado en la eSRAM, y todos los sucesivos samples se harán sobre la eSRAM. Entonces para establecer el filtrado de texturas sólo estaremos limitados por la GPU y no por el ancho de banda. Nótese que en la plataforma supuestamente más potente esto no puede hacerse, y de hecho el filtrado dependerá también del uso que la CPU y otros componentes (sonido, etc.) hagan del bus y del ancho de la memoria principal, es decir, lo que le dejen. En XOne esto funciona como vemos de una forma autónoma y no dependerá del resto salvo por únicamente la 1ª lectura del recurso, luego ya se cachea. Por lo tanto en realidad es como si de la DDR3 se leyera para poner un filtrado POINT, porque sólo lees los datos una vez, a partir de ahí cada sample nuevo de cada filtrado superior se haría sobre la eSRAM. Resulta que si no usas ni tiled resources ni tiled rendering, esto no podrás hacerlo igual porque no te cabrá en la eSRAM los recursos y tendrás que acudir más a menudo a la DDR3 para hacer samples.

- Computing: se sabe que el mayor enemigo de la computación GPGPU es la latencia de la memoria. LA eSRAM por ser de tipo SRAM de eso anda más que bien. La computación requiere no muchos datos en cuanto a tamaño, por lo que el espacio que quede en eSRAM usando los 2 puntos anteriores + el uso de DMA para ir alimentando es más que suficiente para mantener a la GPU ocupada con su capacidad de computación.

Eso sí, de todo esto iros olvidando en motores anticuados que no hagan uso de ninguna técnica moderna. Lo que se suele hacer es meter en eSRAM el trozo que quepa, y el resto a la DDR3, y ea que tire eso como pueda. Mientras que usando tiles ahí está como ejemplo FH2, que cuando lo bajamos a 30 fps nos sobra tanto que podemos activar un 4xMSAA para no desperdiciarlo, vamos que van sobrados de GPU para dibujar. Curioso cuando en la supuestamente más potente, para activar el 4xMSAA a 30 fps han tenido que bajar la resolución a 1920x800.

Algunos pedían que la eSRAM hubiera sido de 64MB, eso es imposible es muy costosa y su función no es sustituir a la VRAM. Es como pedir que las CPU les metan 8MB de caché L1 en lugar de caché L2 que seguro así corre más. Nos ha jodido pero y lo caro que es, además la función de la caché no es sustituir a la RAM.

Se podría decir que la XOne se diseñó "parcialmente incompatible" con motores antiguos, de cara a optimizar el desarrollo de motores que usaran las técnicas nuevas ya presentadas en 2012.

Ferdopa escribió:Jur...

Bueno, pues como me gusta probar las cosas por mí mismo (siempre que se pueda) he hecho la prueba de Star Swarm.

Primero, los resultados de D3D (DX11) y luego los de Mantle. Pongo el porcentaje de diferencia a su lado.

== Results ==========================
Test Duration: 360 Seconds

Total Frames: 11087 20415 +84%

Average FPS: 30.79 56.71 +84%
Average Unit Count: 3983 4561 +14%
Maximum Unit Count: 5530 5969 +8%
Average Batches/MS: 532.65 899.84 +69%
Maximum Batches/MS: 970.08 3793.01 +290%
Average Batch Count: 18173 17429 -6%
Maximum Batch Count: 138026 101261 -27%


Si DX12 es superior a Mantle como afirma MS... no habrá excusa para los desarrolladores a la hora de aprovechar cualquier tipo de hardware.

Un saludo.

darksch escribió:@cercata es normal que les meta caña, es que mira http://www.slideshare.net/takahiroharada/forward-34779335 la fecha de la presentación, ¡2012!. Vaya tela que aún apenas se haya tocado cuando los propios de AMD ya recomendaban la actualización en 2012.

cercata escribió:Y el Forza Engine, pues muy innovador, pero sin efectos climaticos, ciclo dia noche, etc. Y si lo usasen para juegos que no fuesen de coches, pues puede que tuviese mas limitaciones ... es el futuro, pero aun algo verde.

darksch escribió:

cercata escribió:Y el Forza Engine, pues muy innovador, pero sin efectos climaticos, ciclo dia noche, etc. Y si lo usasen para juegos que no fuesen de coches, pues puede que tuviese mas limitaciones ... es el futuro, pero aun algo verde.

¿No has jugado al FH2?

Zokormazo escribió:El problema con el forward+ en 2012 mas que tecnologia inmadura era el lastre de la generacion ps360. Nada nuevo.

[erick] escribió:Buenos días a todos,

una pregunta, que os parecería cerrar este hilo e ir abriendo hilos sobre los temas de actualidad que vayan surgiendo referidos al hardware de One.

La idea es reducir el nivel de ruido que tenemos en el hilo, que los hilos sean más útiles y sobre todo mejorar vuestra experiencia de usuario, pero tampoco queremos tomar la decisión de forma unilateral y queremos saber vuestra opinión y entre todos tomar la decisión.

¿Qué opináis?

Nuhar escribió:A mi me ocurre igual que a muchos compañeros, no entro juego por juego porque me resulta un poco peñazo ir a un hilo, luego a otro, ....

En un hilo único se puede hablar de todo en general y cruzar comentarios de varios juegos a la vez.

Zokormazo escribió:Pero bueno, por probar que no quede.

Zokormazo escribió:

[erick] escribió:Buenos días a todos,

una pregunta, que os parecería cerrar este hilo e ir abriendo hilos sobre los temas de actualidad que vayan surgiendo referidos al hardware de One.

La idea es reducir el nivel de ruido que tenemos en el hilo, que los hilos sean más útiles y sobre todo mejorar vuestra experiencia de usuario, pero tampoco queremos tomar la decisión de forma unilateral y queremos saber vuestra opinión y entre todos tomar la decisión.

¿Qué opináis?

Si y no xD

Por un lado me parece perfecto reconducir la dinamica de este hilo de alguna manera y reducir el ruido.

Por otro, estamos en la misma situacion que en el hilo de juegos de multi, y yo estoy con @Nuhar en esto:

Nuhar escribió:A mi me ocurre igual que a muchos compañeros, no entro juego por juego porque me resulta un poco peñazo ir a un hilo, luego a otro, ....

En un hilo único se puede hablar de todo en general y cruzar comentarios de varios juegos a la vez.

Se puede dispersar el interes en el tema en varios hilos, terminando siendo un peñazo y al final perdiendo actividad e interes de seguimiento por parte de los participantes.

Y luego esta el hecho de que este hilo lo que hace bien es dejar medianamente limpio el resto del foro de one. Teniendo 10 especificos en vez de un hilo, quizas perderiamos esa utilidad que tiene este hilo, y los posts que no vayan exactamente en ningun de los hilos nuevos podrian terminar en el hilo general de xbox one, trasladando alli parte de la discusion.

Tengo mis dudas de que no se si es peor el remedio que la enfermedad xD

Pero bueno, por probar que no quede.

Gamerlol escribió:No participo en el hilo, pero como lector mi opinión es la siguiente:

En caso de diversificar los temas en distintos hilos, sólo se va a conseguir separar la información, y a buen seguro que en los distintos hilos se entremezclarán temas, y el "nivel de ruido" no va a descender en absoluto, para ejemplo el subforo multiplataforma, que ahora mismo los hilos de juegos multis son ya un despropósito.

Al final los hilos se van a abandonar porque la información recogida en ellos estará dispersa y nadie se enterará de lo que realmente importa, y la información importante acabará en el hilo general de One.

[erick] escribió:Buenos días a todos,

una pregunta, que os parecería cerrar este hilo e ir abriendo hilos sobre los temas de actualidad que vayan surgiendo referidos al hardware de One.

La idea es reducir el nivel de ruido que tenemos en el hilo, que los hilos sean más útiles y sobre todo mejorar vuestra experiencia de usuario, pero tampoco queremos tomar la decisión de forma unilateral y queremos saber vuestra opinión y entre todos tomar la decisión.

¿Qué opináis?

Zokormazo escribió:El problema con el forward+ en 2012 mas que tecnologia inmadura era el lastre de la generacion ps360. Nada nuevo.

Gamerlol escribió:No participo en el hilo, pero como lector mi opinión es la siguiente:

En caso de diversificar los temas en distintos hilos, sólo se va a conseguir separar la información, y a buen seguro que en los distintos hilos se entremezclarán temas, y el "nivel de ruido" no va a descender en absoluto, para ejemplo el subforo multiplataforma, que ahora mismo los hilos de juegos multis son ya un despropósito.

Al final los hilos se van a abandonar porque la información recogida en ellos estará dispersa y nadie se enterará de lo que realmente importa, y la información importante acabará en el hilo general de One.

[erick] escribió:...

Horizonte de sucesos escribió:

[erick] escribió:Buenos días a todos,

una pregunta, que os parecería cerrar este hilo e ir abriendo hilos sobre los temas de actualidad que vayan surgiendo referidos al hardware de One.

La idea es reducir el nivel de ruido que tenemos en el hilo, que los hilos sean más útiles y sobre todo mejorar vuestra experiencia de usuario, pero tampoco queremos tomar la decisión de forma unilateral y queremos saber vuestra opinión y entre todos tomar la decisión.

¿Qué opináis?

Tener 5 hilos hablando de lo mismo?
Entrar en el que hablabas y ver que lo han cerrado porque el tema estaba en otro hilo?
Ver tus mensajes movidos continuamente?
Ver offtopics y disputas en mil hilos?

No gracias.

Zokormazo escribió:El problema con el forward+ en 2012 mas que tecnologia inmadura era el lastre de la generacion ps360. Nada nuevo.

Eso es cierto, ningún dev estaba dispuesto a programar un juego usando dos engines diferentes, uno para consolas y otro para PC, ya que el F+ no es soportado por el arcaico hardware consolero.

Si eso hubiese sucedido estaríamos hablando de versiones de juegos en PC que dejarían a las consolas como juguetes rotos. La diferencia sería humillante, muchísimo más de lo que fue. Por contra ahora tendríamos unos multis mucho más avanzados y potentes que lo que nos estamos comiendo a estas alturas, y no habría ninguno por debajo de los 1080p en ninguna consola y con un AA de los buenos.

ONE, actualmente es la plataforma de juegos donde más se ha avanzado en ese aspecto dado a su necesidad. A ver si gracias a ella se tira del carro y vamos desechando la tecnología obsoleta y sustituyéndola por la moderna.