Hilo de Noticias y Rumores de Multiplataforma

LordVulkan escribió:Lo mejor es el fan escocido acusando al responsable técnico de Nanite de FUD contra PlayStation y pidiendo a Tim Sweeney que controle a sus empleados, metiendo en la mención a todo el alto cargo de Sony que ha pillao.

Twitter debería cerrar

Lo de SSD es el típico anzuelo que lanzan en campaña de lanzamiento para distinguirlo de la competencia, al final de la generación ya nadie se acuerda de el.

Es una mas de las tantas historias de vende-humos del mundo de los videojuegos y en esta E3 tendremos mas.
Estoy esperando con ansias ver esos juegos que el gameplay se mueve con una cinemática y cuando sale el juego a los 3 o 4 años solo se parecen en el titulo, aunque siendo justos se han vuelto muchos mas prudentes en este aspecto, sobre todo Sony que tuvo años exagerados.

El que se crea que todo lo que ofrece UE5 va a ser solo para ps5 está de deltas hasta arriba, UE5 es un motor multiplatafomas con lo que tiene que funcionar en todos los sistemas, que vaya mejor en uno u otro sistema es normal, pero el que se piense que solo es posible en ps5 que se tome una tila

Mira que se hace sangre cuando fue solo un usuario que ha dicho varias cosas que no estaban muy acertadas.

Lo mismo que pasó con Xbox en el pasado con la potencia oculta y el poder de la nube.

pabloc escribió:Mira que se hace sangre cuando fue solo un usuario que ha dicho varias cosas que no estaban muy acertadas.

Lo mismo que pasó con Xbox en el pasado con la potencia oculta y el poder de la nube.

El problema de los falsos profetas es que suelen tener una legión de seguidores que siguen a pies juntillas lo que dicen.

Se debe luchar contra la desinformación lo mejor posible. Y con vídeos como el que se ha puesto es como se hace.

Gracias a los profetas de xbox aprendí un montón de cosas en su momento, incluido el no creerte medias verdades juntadas de forma interesada para contar una nueva película.

No hay que dar eco a cierta gente, son tóxicos

LordVulkan escribió:Lo mejor es el fan escocido acusando al responsable técnico de Nanite de FUD contra PlayStation y pidiendo a Tim Sweeney que controle a sus empleados, metiendo en la mención a todo el alto cargo de Sony que ha pillao.

Joder, pero esta gente vive de Epic y Playstation, le dan de comer?

El mundo y la mente del fanboy es algo digno de estudio porque perder los papeles y hacer el ridículo de semejante manera por cualquier cosa es lamentable del todo...

@exar También te digo que es twitter, allí el 99% de las publicaciones son para tirar mierda

Ah sisi, está claro que el mundo sería un mundo mejor si no existiera Twitter.

Y ojo, que la mente del fanboy en este caso es de los videojuegos, pero me da igual esto que el deporte, la política o el fanboy de la Coca-Cola o la Pepsi.

NocheToledana escribió:La famosa demo de Unreal Engine 5 funcionando perfectamente en un PC.

No puede ser el otro día leí al injeniero estrella del foro diciendo q la demo de la presentación de epic de este mes tuvieron q relajarla respecto lo q enseñaron en ps5 porque sin el IO mágico no se podía mover.

¿Créeis que se trata de TLOU Factions o de otro Multijugador?

https://www.pushsquare.com/news/2021/06 ... er_project

Yo me lo creeré cuando lo vea plasmado en los videojuegos; como en este último Ratchet... el cuál hace un muy buen uso de lo que se le pediría a un SSD (aprovechar su velocidad para integrarlo al gameplay, pero está claro que no todos los desarrollos pedirán eso; en un 'PES' solo cargaría rápido y ya xD)

mocolostrocolos escribió:¿Créeis que se trata de TLOU Factions o de otro Multijugador?

https://www.pushsquare.com/news/2021/06 ... er_project

Espero que sí. El multijugador de TLoU me pareció el mejor de esa generación junto con CoD 4: Modern Warfare. Vaya viciadas macabras le eché.

He visto esta imagen:



Y WTF creo que no he oído hablar absolutamente nada de ese Predator. Así de bueno habrá salido

Rokzo escribió:He visto esta imagen:



Y WTF creo que no he oído hablar absolutamente nada de ese Predator. Así de bueno habrá salido

Ahí mismo puedes ver las notas de OC y MC para hacerte una idea del zurullito que es xD

Rokzo escribió:He visto esta imagen:



Y WTF creo que no he oído hablar absolutamente nada de ese Predator. Así de bueno habrá salido

Creo que era uno de estos shooter multi asimétrico. De 4/5 humanos luchando contra un predator. Pero ya desde los primeros vídeos se veía que iba a ser un mojón

Rokzo escribió:He visto esta imagen:



Y WTF creo que no he oído hablar absolutamente nada de ese Predator. Así de bueno habrá salido

Mira si es importante el juego que fue el primer PlayStation Studios que salió día uno en PC, en abril 2020 y a nadie le importó.

Esa imagen deja una cosa clarisima, que Sony deberia de dejar de producir juegos multijugador, porque vaya tela xD

A mi me parece tremendo la compresión en los juegos de Ps5, no sé si es el algoritmo los dev kits o que, pero los juegos ocupan bastante menos que en series x.

manmartin escribió:A mi me parece tremendo la compresión en los juegos de Ps5, no sé si es el algoritmo los dev kits o que, pero los juegos ocupan bastante menos que en series x.

Eso sí que es cosa de la arquitectura de datos de la consola.

ryo hazuki escribió:Esa imagen deja una cosa clarisima, que Sony deberia de dejar de producir juegos multijugador, porque vaya tela xD

Acabo de leer ahora mismo que naughty dog busca personal para hacer su primer juego multijugador jajaja

A mi me parece que es algo que falta en playy, al igual que en xbox le falta más single player. Un término medio estaria bien jajaja

El problema de predator es que lo tendrían que haber sacado como F2P he ir desbloqueando personajes y demás, pero prefirieron sacarlo a 40€ si mal no recuerdo, aún así no es de playstation studios

davidDVD escribió:Yo me lo creeré cuando lo vea plasmado en los videojuegos; como en este último Ratchet... el cuál hace un muy buen uso de lo que se le pediría a un SSD (aprovechar su velocidad para integrarlo al gameplay, pero está claro que no todos los desarrollos pedirán eso; en un 'PES' solo cargaría rápido y ya xD)

Desde el desconocimiento y sin ganas de flammear, cuando salió el Spiderman MM, la gente se hacía pajas con la transición de una fase a mundo abierto (recuerdo un gif que salía por una ventana de una iglesia o algo así), que eso era el magicSSD y no se qué, que menuda velocidad de carga para volver al mundo abierto...

Luego en PS4 resultaba que era idéntico (salvando distancias de dibujado, resolución etc etc), pero es que en ps4 el kraken y no se que ostias, vamos excusas varias pero víctimas del hype que no se bajaban de la burra...

A mí el que cambies de mapa rápido-instantáneo no dice nada de la velocidad del SSD (entiéndeme que sea la polla que lo es pero no deja de ser un ssd), más si cuando aparece la ventana esa dimensional ya se ha cargado en la RAM el mapa al que vas a saltar...

Resumiendo que lo que te quería preguntar, ¿os referís a la velocidad del SSD, sólo por ese cambio de mapas?

Plage escribió:El problema de predator es que lo tendrían que haber sacado como F2P he ir desbloqueando personajes y demás, pero prefirieron sacarlo a 40€ si mal no recuerdo, aún así no es de playstation studios

Si lo es, es el mismo caso de Destruction all stars, juego de producción propia y desarrollado por un estudio third party (y ambos con destinos similares xD)

Me parece curioso que Sony nos muestre el Horizon semanas antes del E3 (por eso de no estar en el E3) y luego una entrevista cutre al Hermen dando noticias... En vez de hacer un State of Play como toca.

No se para cuando lo cuadrarán ahora. Agosto?
Pero desde el "gordo" de la presentacion de PS5, ya ha llovido y necesitarian presentar un poco la hoja de ruta que tienen para 2022 tambien. (y algo de hype a largo plazo)

mocolostrocolos escribió:Debe ser un PC con SSD mágico.

Pues no, parece que la demo podría correr sobre un HDD de acuerdo con Branchild:

https://www.resetera.com/threads/epic-g ... t-66829594

[The goal (dream) with Nanite was to remove the notion of technical budgets and constraints for 3D Artists so that they can just focus the art itself, regardless of quality

The virtualization of geometry is a lot harder to implement in practice than the virtualization of textures due to factors like rendering cost

GPU driven pipeline for Nanite, which allows optimizations like reduced draw call requirements per scene
Draw calls are per material, not per object. All opaque geometry can now be rendered with just a single draw call

In this demo, pixel sized triangles used software rasterizer, as it's up to 3x faster than hardware rasterizer. Big triangles use hw rasterizer (rasterizer chosen on per cluster basis)

Average frame for demo was ~1400p upscaled to 4k via temporal upsampling

Nearly zero CPU time and very little CPU cost. Most of the work handled by the GPU

Proprietary compression tech to keep file sizes in check (the immense amount of geometry would take up too much space otherwise)

All Nanite data on disk (compressed) was 6.14 GB in total

Texture data far larger than geometry data

16k x 16k virtualized shadow maps work in a similar way to Nanite by only rendering shadow detail that's perceptible (shadow pixels)

The scenes shown are demonstrated using a free roam camera to show that scripting is not necessary and that there isn't any masked loading

Entire level was loaded into memory (mainly for the purposes of showing that the infamous crack was not used to hide streaming)

Self-shadowing makes it easier to see the increased fidelity of actual geometry compared to normal maps

Demo shown is not using world partitioning (the tech hadn't fully developed by the time the demo was made)

The closer the camera is to a given mesh, the more faithful the geometry will be relative to the source model (the delta in fidelity is practically imperceptible without visualization data)

128 triangles per cluster. Cluster sizes on screen are roughly the same, regardless of viewing distance, which allows the triangles to have similarly stable counts on screen

On average, there weren't much more than 20M tris rendered on screen, even with billions of triangles from source geometry. The tri count will scale with resolution

Nanite supports hard surface model meshes as well, not just organic assets from megascans/photogrammetry

The ring on the portal at the end of the demo is not actually a unique mesh, but made from instanced geometry like the statues shown earlier in the demo

mocolostrocolos escribió:

mocolostrocolos escribió:Debe ser un PC con SSD mágico.

Pues no, parece que la demo podría correr sobre un HDD de acuerdo con Branchild:

https://www.resetera.com/threads/epic-g ... t-66829594

[The goal (dream) with Nanite was to remove the notion of technical budgets and constraints for 3D Artists so that they can just focus the art itself, regardless of quality

The virtualization of geometry is a lot harder to implement in practice than the virtualization of textures due to factors like rendering cost

GPU driven pipeline for Nanite, which allows optimizations like reduced draw call requirements per scene
Draw calls are per material, not per object. All opaque geometry can now be rendered with just a single draw call

In this demo, pixel sized triangles used software rasterizer, as it's up to 3x faster than hardware rasterizer. Big triangles use hw rasterizer (rasterizer chosen on per cluster basis)

Average frame for demo was ~1400p upscaled to 4k via temporal upsampling

Nearly zero CPU time and very little CPU cost. Most of the work handled by the GPU

Proprietary compression tech to keep file sizes in check (the immense amount of geometry would take up too much space otherwise)

All Nanite data on disk (compressed) was 6.14 GB in total

Texture data far larger than geometry data

16k x 16k virtualized shadow maps work in a similar way to Nanite by only rendering shadow detail that's perceptible (shadow pixels)

The scenes shown are demonstrated using a free roam camera to show that scripting is not necessary and that there isn't any masked loading

Entire level was loaded into memory (mainly for the purposes of showing that the infamous crack was not used to hide streaming)

Self-shadowing makes it easier to see the increased fidelity of actual geometry compared to normal maps

Demo shown is not using world partitioning (the tech hadn't fully developed by the time the demo was made)

The closer the camera is to a given mesh, the more faithful the geometry will be relative to the source model (the delta in fidelity is practically imperceptible without visualization data)

128 triangles per cluster. Cluster sizes on screen are roughly the same, regardless of viewing distance, which allows the triangles to have similarly stable counts on screen

On average, there weren't much more than 20M tris rendered on screen, even with billions of triangles from source geometry. The tri count will scale with resolution

Nanite supports hard surface model meshes as well, not just organic assets from megascans/photogrammetry

The ring on the portal at the end of the demo is not actually a unique mesh, but made from instanced geometry like the statues shown earlier in the demo

No se donde lees que no, en el propio post que enlazas dice que sí.

Eso está diciendo precisamente mocos.

LordVulkan escribió:

mocolostrocolos escribió:

mocolostrocolos escribió:Debe ser un PC con SSD mágico.

Pues no, parece que la demo podría correr sobre un HDD de acuerdo con Branchild:

https://www.resetera.com/threads/epic-g ... t-66829594

[The goal (dream) with Nanite was to remove the notion of technical budgets and constraints for 3D Artists so that they can just focus the art itself, regardless of quality

The virtualization of geometry is a lot harder to implement in practice than the virtualization of textures due to factors like rendering cost

GPU driven pipeline for Nanite, which allows optimizations like reduced draw call requirements per scene
Draw calls are per material, not per object. All opaque geometry can now be rendered with just a single draw call

In this demo, pixel sized triangles used software rasterizer, as it's up to 3x faster than hardware rasterizer. Big triangles use hw rasterizer (rasterizer chosen on per cluster basis)

Average frame for demo was ~1400p upscaled to 4k via temporal upsampling

Nearly zero CPU time and very little CPU cost. Most of the work handled by the GPU

Proprietary compression tech to keep file sizes in check (the immense amount of geometry would take up too much space otherwise)

All Nanite data on disk (compressed) was 6.14 GB in total

Texture data far larger than geometry data

16k x 16k virtualized shadow maps work in a similar way to Nanite by only rendering shadow detail that's perceptible (shadow pixels)

The scenes shown are demonstrated using a free roam camera to show that scripting is not necessary and that there isn't any masked loading

Entire level was loaded into memory (mainly for the purposes of showing that the infamous crack was not used to hide streaming)

Self-shadowing makes it easier to see the increased fidelity of actual geometry compared to normal maps

Demo shown is not using world partitioning (the tech hadn't fully developed by the time the demo was made)

The closer the camera is to a given mesh, the more faithful the geometry will be relative to the source model (the delta in fidelity is practically imperceptible without visualization data)

128 triangles per cluster. Cluster sizes on screen are roughly the same, regardless of viewing distance, which allows the triangles to have similarly stable counts on screen

On average, there weren't much more than 20M tris rendered on screen, even with billions of triangles from source geometry. The tri count will scale with resolution

Nanite supports hard surface model meshes as well, not just organic assets from megascans/photogrammetry

The ring on the portal at the end of the demo is not actually a unique mesh, but made from instanced geometry like the statues shown earlier in the demo

No se donde lees que no, en el propio post que enlazas dice que sí.

Vuelve a leer lo que he escrito.

Perdón, me ha fallado la comprensión lectora.

bigfoot_ escribió:1. Desde el desconocimiento y sin ganas de flammear, cuando salió el Spiderman MM, la gente se hacía pajas con la transición de una fase a mundo abierto (recuerdo un gif que salía por una ventana de una iglesia o algo así), que eso era el magicSSD y no se qué, que menuda velocidad de carga para volver al mundo abierto...

1Luego en PS4 resultaba que era idéntico (salvando distancias de dibujado, resolución etc etc), pero es que en ps4 el kraken y no se que ostias, vamos excusas varias pero víctimas del hype que no se bajaban de la burra...

2. A mí el que cambies de mapa rápido-instantáneo no dice nada de la velocidad del SSD (entiéndeme que sea la polla que lo es pero no deja de ser un ssd), más si cuando aparece la ventana esa dimensional ya se ha cargado en la RAM el mapa al que vas a saltar...

3. Resumiendo que lo que te quería preguntar, ¿os referís a la velocidad del SSD, sólo por ese cambio de mapas?

1. Pero ese es un cross-gen, ahí no hace falta "alinear" los componentes para que no haya esperas, la base es una PS4 con HDD... cualquier placa base actual podría (ya que es simplemente acceder/cargar rápido, quitas la transición)

2. Lo del Ratchet yo lo veo más complicadete, no por nada, más bien porque están sacando cosas (para PC) del mismo estilo de lo que presentó Cerny para PS5 en su día (acceso directo sin pasar por CPU o tal), de momento yo no sé si sirve lo actual (tal y cómo está planteado); más que nada porque no hay otro juego que haga lo mismo (creo); de momento no actualizo el PC por si acaso

3. Es lo que Nvidia (RTX IO) o Cerny presentó (lecturas directas sin intervención de CPU, y demás cosas técnicas xD)

@davidDVD yo creo que lo de la CPU no va así exactamente, creo que la cosa va más porque la GPU pueda coger lo que necesita sin que la CPU lo procese y lo mandé a la ram, no que la CPU no intervenga.

El handicap que tienen las consolas, por las cuales el uso del SSD es un paso importante, es la falta de memoria RAM.

En un PC esos problemas son menores, porque tenemos 2 pool de memoria, uno con la memoria del sistema, que hoy ya se está yendo hacia los 32 GB (y 64 GB en los entusiastas), y otro pool de memoria para la GPU, que está por los 8-16 GB, según el modelo de tarjeta. Al tener 2 pool de memoria, puedes ir metiendo a la más lenta (pero que es mucho más rápida que un SSD) a la RAM del sistema, para luego subirlo a la memoria de la GPU, el uso de un SSD o HDD es "desestimable" si podemos cargar en la RAM del sistema lo necesario una vez está ya corriendo el juego.

Así, es posible utilizar casi toda la memoria de la GPU, pudiendo liberar memoria de la GPU y cargarla del sistema cuando sea necesario, sin que repercuta en el rendimiento y, así, pudiendo tener una cantidad de assets, texturas y calidad de éstas muy alta.

Pero en consolas tenemos un problema, las de pasada generación tenían 8 GB (disponibles mucho menos), mientras que las de actual generación hemos pasado a los 16GB (algo menos disponible), tanto para CPU como para GPU, ahí ya tenemos una carencia de RAM importante. Eso obligaba que, por un lado, el uso del HDD tuviera que hacerse una lectura secuencial completa en cada nivel (unos tiempos de carga muy altos) y que, si quisieras ir cargando al vuelo del HDD, tener que liberar bastante más espacio de la RAM, para lo que fuera por venir, obligando a una cantidad y calidad de assets más baja.

Ahora, con el uso del SSD (y otras tecnologías asociadas como la compresión, el I/O controller o el FastPath), se permite aumentar mucho más el uso de la memoria, ya que el acceso a los datos es mucho más rápido que con el HDD, podemos liberar y cargar RAM en streaming sin muchos problemas, además, con las tecnologías asociadas, se puede eliminar más morralla que tenías que cargar antes, que te ocupaba RAM, pero que no ibas a utilizar en ese momento.

No es que el SSD sea mágico, pero sí que permite, por un lado, ahorrar costes en cuanto a RAM de sistema o de GPU necesitas (ya no es necesario cantidades tan ingentes de RAM), por otro, crear un streaming de datos a la memoria de la GPU contínuo para ir cambiando assets o texturas de manera más dinámica y, así, aumentar la calidad visual (sobretodo en variedad), además de reducir el espacio requerido en el disco principal, pues no requiere de la redundancia obligada en los HDD, por culpa de la baja velocidad de lectura aleatoria.

En cuanto a la demo de Nanite, pues normal que funcione bien en un PC con HDD, con lo que ocupa (6-7GB comprimidos), incluso descomprimidos, puedes perfectamente subirlo a la RAM sin problemas de espacio para luego ir cargando en la memoria de la GPU.

Mulzani escribió:El handicap que tienen las consolas, por las cuales el uso del SSD es un paso importante, es la falta de memoria RAM.

En un PC esos problemas son menores, porque tenemos 2 pool de memoria, uno con la memoria del sistema, que hoy ya se está yendo hacia los 32 GB (y 64 GB en los entusiastas), y otro pool de memoria para la GPU, que está por los 8-16 GB, según el modelo de tarjeta. Al tener 2 pool de memoria, puedes ir metiendo a la más lenta (pero que es mucho más rápida que un SSD) a la RAM del sistema, para luego subirlo a la memoria de la GPU, el uso de un SSD o HDD es "desestimable" si podemos cargar en la RAM del sistema lo necesario una vez está ya corriendo el juego.

Así, es posible utilizar casi toda la memoria de la GPU, pudiendo liberar memoria de la GPU y cargarla del sistema cuando sea necesario, sin que repercuta en el rendimiento y, así, pudiendo tener una cantidad de assets, texturas y calidad de éstas muy alta.

Pero en consolas tenemos un problema, las de pasada generación tenían 8 GB (disponibles mucho menos), mientras que las de actual generación hemos pasado a los 16GB (algo menos disponible), tanto para CPU como para GPU, ahí ya tenemos una carencia de RAM importante. Eso obligaba que, por un lado, el uso del HDD tuviera que hacerse una lectura secuencial completa en cada nivel (unos tiempos de carga muy altos) y que, si quisieras ir cargando al vuelo del HDD, tener que liberar bastante más espacio de la RAM, para lo que fuera por venir, obligando a una cantidad y calidad de assets más baja.

Ahora, con el uso del SSD (y otras tecnologías asociadas como la compresión, el I/O controller o el FastPath), se permite aumentar mucho más el uso de la memoria, ya que el acceso a los datos es mucho más rápido que con el HDD, podemos liberar y cargar RAM en streaming sin muchos problemas, además, con las tecnologías asociadas, se puede eliminar más morralla que tenías que cargar antes, que te ocupaba RAM, pero que no ibas a utilizar en ese momento.

No es que el SSD sea mágico, pero sí que permite, por un lado, ahorrar costes en cuanto a RAM de sistema o de GPU necesitas (ya no es necesario cantidades tan ingentes de RAM), por otro, crear un streaming de datos a la memoria de la GPU contínuo para ir cambiando assets o texturas de manera más dinámica y, así, aumentar la calidad visual (sobretodo en variedad), además de reducir el espacio requerido en el disco principal, pues no requiere de la redundancia obligada en los HDD, por culpa de la baja velocidad de lectura aleatoria.

En cuanto a la demo de Nanite, pues normal que funcione bien en un PC con HDD, con lo que ocupa (6-7GB comprimidos), incluso descomprimidos, puedes perfectamente subirlo a la RAM sin problemas de espacio para luego ir cargando en la memoria de la GPU.

Un pequeño apunte.

El tener SSD no te permite cargar texturas (o lo que sea) de mas calidad que sin SSD.

La calidad vendra determinada por lo que te quepa en la RAM. Puesto que del SSD se pasa a la RAM, la RAM va a seguir siendo el factor limitante. Para poder aumentar la calidad de las texturas o tienes mas RAM, o sacrificas cantidad de texturas.

A menos que me haya perdido algo sobre las nuevas consolas, lo de poder aumentar calidad es un bulo. El SDD lo que permite mejorar es el tiempo de carga.

Supongo que quiere decir que al leer desde el disco duro y no desde la raam te permite liberar el espacio que ocupan las texturas y tener todas a 4k - 8k...lo de assetts.. No se a que se refiere

Por cierto, los pcs tienen ssd, xbox tiene ssd, la magia que tanta burla genera no viene por tener un ssd sino porque algunos se piensan que la velocidad del mismo es un factor MUY determinante, cuando no lo es.

Las tareas importantes y mas rapidas que necesitan la gpu y la cpu las ejecuta la ram que para eso se invento y es muy muy cara, y como es tan cara se invento algo más barato llamado hd, que ha evolucionado al ssd, pero no deja de ser un elemento lento

Yo no se que le ven al famoso lumen como la segunda venida de cristo si es un sistema de luz que es old gen al lado de cualquier cosa con raytracing. Lo que destaca es la textura y el modelado poligonal, pero a costa de un sistema de luz old gen.

Lo otro que veo atras es parte del pataleo porque mentiroso tim en parte mintió por la pasta que le puso sony (sumado a que los fans le reinterpretaron las declaraciones para que digan cosas que el no dijo) y les salio mal en todo sentido porque les duro muy poco cuando se vino el puf de epic china. Se tiraron el lance de hacer lo que siempre hizo kuta y kaz con las tech demos... pero cerny y tim no tienen "la magia" de kuta y kaz para tirar hype y que salga bien

Nuhar escribió:Supongo que quiere decir que al leer desde el disco duro y no desde la raam te permite liberar el espacio que ocupan las texturas y tener todas a 4k - 8k...lo de assetts.. No se a que se refiere

Yo muy al principio, cuando se empezó a especular sobre los SSD en las consolas y las nuevas arquitecturas, pensaba que los tiros podrian ir por ahi, por mostrar texturas directamente del SSD (que no se ni si seria posible dividir el framebuffer en dos localizaciones), pero si no me estoy equivocando, la cosa realmente no es asi.

Repito, si no me equivoco, o hay algo que no he entendido, o que no me he enterado (si no que me corrija alguien), la Gpu ve lo que hay en el SSD, de ahi lo pasa a la RAM y de ahi a la pantalla (simplificando un poco el proceso). Si esto es asi, no es posible tener mejor calidad de texturas (y diria que tampoco te aporta tener mas variedad de texturas que un HDD). La RAM va a seguir siendo el factor limitante en ese sentido, igual que antes. Si todo lo que se muestra en pantalla viene de la RAM, esta es la que te va a limitar en cuanto a cantidad/calidad de texturas.

¿que aporta el SSD? Antes, creo que era la Gpu la que pedia una textura a la Cpu, la Cpu la busca en el disco, la pasa a la Ram y una vez en la Ram ya la ve la Gpu para mostrarla en pantalla (algo asi). Con el SSD y todo el tema del IO, te evitas ese circuito, lo que permite ahorrar tiempo. Si a esto, le añades que de por si el SSD es mas rapido, se reducen drasticamente los tiempos... pero nada mas.

Zeta V escribió:

Nuhar escribió:Supongo que quiere decir que al leer desde el disco duro y no desde la raam te permite liberar el espacio que ocupan las texturas y tener todas a 4k - 8k...lo de assetts.. No se a que se refiere

Yo muy al principio, cuando se empezó a especular sobre los SSD en las consolas y las nuevas arquitecturas, pensaba que los tiros podrian ir por ahi, por mostrar texturas directamente del SSD (que no se ni si seria posible dividir el framebuffer en dos localizaciones), pero si no me estoy equivocando, la cosa realmente no es asi.

Repito, si no me equivoco, o hay algo que no he entendido, o que no me he enterado (si no que me corrija alguien), la Gpu ve lo que hay en el SSD, de ahi lo pasa a la RAM y de ahi a la pantalla (simplificando un poco el proceso). Si esto es asi, no es posible tener mejor calidad de texturas (y diria que tampoco te aporta tener mas variedad de texturas que un HDD). La RAM va a seguir siendo el factor limitante en ese sentido, igual que antes. Si todo lo que se muestra en pantalla viene de la RAM, esta es la que te va a limitar en cuanto a cantidad/calidad de texturas.

¿que aporta el SSD? Antes, creo que era la Gpu la que pedia una textura a la Cpu, la Cpu la busca en el disco, la pasa a la Ram y una vez en la Ram ya la ve la Gpu para mostrarla en pantalla (algo asi). Con el SSD y todo el tema del IO, te evitas ese circuito, lo que permite ahorrar tiempo. Si a esto, le añades que de por si el SSD es mas rapido, se reducen drasticamente los tiempos... pero nada mas.

El SSD según la primera demo de ue5 en ps5, permitía tener texturas a 8k si no me equivoco. Era posible porque el SSD está cargando en la ram sólo lo que estés viendo en pantalla, descartando lo que no ves.

Mj90 escribió:

Zeta V escribió:

Nuhar escribió:Supongo que quiere decir que al leer desde el disco duro y no desde la raam te permite liberar el espacio que ocupan las texturas y tener todas a 4k - 8k...lo de assetts.. No se a que se refiere

Yo muy al principio, cuando se empezó a especular sobre los SSD en las consolas y las nuevas arquitecturas, pensaba que los tiros podrian ir por ahi, por mostrar texturas directamente del SSD (que no se ni si seria posible dividir el framebuffer en dos localizaciones), pero si no me estoy equivocando, la cosa realmente no es asi.

Repito, si no me equivoco, o hay algo que no he entendido, o que no me he enterado (si no que me corrija alguien), la Gpu ve lo que hay en el SSD, de ahi lo pasa a la RAM y de ahi a la pantalla (simplificando un poco el proceso). Si esto es asi, no es posible tener mejor calidad de texturas (y diria que tampoco te aporta tener mas variedad de texturas que un HDD). La RAM va a seguir siendo el factor limitante en ese sentido, igual que antes. Si todo lo que se muestra en pantalla viene de la RAM, esta es la que te va a limitar en cuanto a cantidad/calidad de texturas.

¿que aporta el SSD? Antes, creo que era la Gpu la que pedia una textura a la Cpu, la Cpu la busca en el disco, la pasa a la Ram y una vez en la Ram ya la ve la Gpu para mostrarla en pantalla (algo asi). Con el SSD y todo el tema del IO, te evitas ese circuito, lo que permite ahorrar tiempo. Si a esto, le añades que de por si el SSD es mas rapido, se reducen drasticamente los tiempos... pero nada mas.

El SSD según la primera demo de ue5 en ps5, permitía tener texturas a 8k si no me equivoco. Era posible porque el SSD está cargando en la ram sólo lo que estés viendo en pantalla, descartando lo que no ves.

Para tener texturas 8k no hace falta tener SSD ni toda la arquitectura que se ha diseñado en Ps5. WiiU (ahi queda el hardware que montaba) ya usaba texturas 8k en algun juego.

La transferencia de datos en ancho de banda del SSD a la RAM es de 5.5 y de la RAM a la pantalla 448. Eso significa que si todo lo que esta en la Ram se esta viendo en pantalla, algo que no ves en pantalla y lo quieras mostrar, no da tiempo a pasarlo en el intervalo que se renderiza un frame.

Zeta V escribió:

Mj90 escribió:

Zeta V escribió:
Yo muy al principio, cuando se empezó a especular sobre los SSD en las consolas y las nuevas arquitecturas, pensaba que los tiros podrian ir por ahi, por mostrar texturas directamente del SSD (que no se ni si seria posible dividir el framebuffer en dos localizaciones), pero si no me estoy equivocando, la cosa realmente no es asi.

Repito, si no me equivoco, o hay algo que no he entendido, o que no me he enterado (si no que me corrija alguien), la Gpu ve lo que hay en el SSD, de ahi lo pasa a la RAM y de ahi a la pantalla (simplificando un poco el proceso). Si esto es asi, no es posible tener mejor calidad de texturas (y diria que tampoco te aporta tener mas variedad de texturas que un HDD). La RAM va a seguir siendo el factor limitante en ese sentido, igual que antes. Si todo lo que se muestra en pantalla viene de la RAM, esta es la que te va a limitar en cuanto a cantidad/calidad de texturas.

¿que aporta el SSD? Antes, creo que era la Gpu la que pedia una textura a la Cpu, la Cpu la busca en el disco, la pasa a la Ram y una vez en la Ram ya la ve la Gpu para mostrarla en pantalla (algo asi). Con el SSD y todo el tema del IO, te evitas ese circuito, lo que permite ahorrar tiempo. Si a esto, le añades que de por si el SSD es mas rapido, se reducen drasticamente los tiempos... pero nada mas.

El SSD según la primera demo de ue5 en ps5, permitía tener texturas a 8k si no me equivoco. Era posible porque el SSD está cargando en la ram sólo lo que estés viendo en pantalla, descartando lo que no ves.

Para tener texturas 8k no hace falta tener SSD ni toda la arquitectura que se ha diseñado en Ps5. WiiU (ahi queda el hardware que montaba) ya usaba texturas 8k en algun juego.

La transferencia de datos en ancho de banda del SSD a la RAM es de 5.5 y de la RAM a la pantalla 448. Eso significa que si todo lo que esta en la Ram se esta viendo en pantalla, algo que no ves en pantalla y lo quieras mostrar, no da tiempo a pasarlo en el intervalo que se renderiza un frame.

Texturas 8k en ese nuevo motor gráfico y simplemente cargándolo cuando es necesario pues es un avance creo yo.

Sobre lo que comentas al final, la demo de ue5 estaba funcionando así y Ratchet según comentan está funcionando así o de manera similar, descartando lo que no estás viendo en pantalla.

Mj90 escribió:

Zeta V escribió:

Mj90 escribió:
El SSD según la primera demo de ue5 en ps5, permitía tener texturas a 8k si no me equivoco. Era posible porque el SSD está cargando en la ram sólo lo que estés viendo en pantalla, descartando lo que no ves.

Para tener texturas 8k no hace falta tener SSD ni toda la arquitectura que se ha diseñado en Ps5. WiiU (ahi queda el hardware que montaba) ya usaba texturas 8k en algun juego.

La transferencia de datos en ancho de banda del SSD a la RAM es de 5.5 y de la RAM a la pantalla 448. Eso significa que si todo lo que esta en la Ram se esta viendo en pantalla, algo que no ves en pantalla y lo quieras mostrar, no da tiempo a pasarlo en el intervalo que se renderiza un frame.

Texturas 8k en ese nuevo motor gráfico y simplemente cargándolo cuando es necesario pues es un avance creo yo.

Sobre lo que comentas al final, la demo de ue5 estaba funcionando así y Ratchet según comentan está funcionando así o de manera similar, descartando lo que no estás viendo en pantalla.

No se que tiene que ver el tocino con la velocidad. UE5 es un motor nuevo y en la demo que mostraron usaron texturas a 8k ¿que quieres decir con eso? ¿cual es el avance en ello?

Yo no estoy hablando de lo que dice o deja de decir la gente en los foros, estoy hablando de los frios numeros oficiales y que con ellos en la mano, no es posible hacer eso que tu estas diciendo (salvo que haya algo que no nos hayan contado).

@Zeta V

A ver, es porque ya no es necesario precargar de antemano tantas texturas o elementos.

Antes, en una consola, si querías eliminar el tener que hacer una pantalla de carga, necesitas ir cargando los datos de antemano para poder quitar la pantalla de carga, eso implica tener residente en memoria muchos datos que no se usarán hasta pasado un tiempo, por lo que estás limitando la cantidad de memoria RAM disponible para la escena actual.

Con la carga mediante el SSD (y las tecnologías asociadas), puedes cargar los datos casi sobre la marcha, permitiendo poder usar más memoria RAM para la escena actual y menos para la que va a venir, porque podrás ir cargándola a posteriori.

De ahí que permitas meter, o más variedad de texturas, o con más calidad...

Para un mundo abierto, es una mejora importante en cuanto a meter más calidad, para un escenario cerrado, con cargas por nivel, la diferencia no es tan palpable, salvo en el tiempo de carga.

Eso sí, el limitante de la GPU va a seguir estando ahí, si tu GPU sólo permite disponer de una cantidad de elementos en escena, el uso del SSD no va a permitir aumentar dichos elementos.

Zeta V escribió:

Mj90 escribió:

Zeta V escribió:
Para tener texturas 8k no hace falta tener SSD ni toda la arquitectura que se ha diseñado en Ps5. WiiU (ahi queda el hardware que montaba) ya usaba texturas 8k en algun juego.

La transferencia de datos en ancho de banda del SSD a la RAM es de 5.5 y de la RAM a la pantalla 448. Eso significa que si todo lo que esta en la Ram se esta viendo en pantalla, algo que no ves en pantalla y lo quieras mostrar, no da tiempo a pasarlo en el intervalo que se renderiza un frame.

Texturas 8k en ese nuevo motor gráfico y simplemente cargándolo cuando es necesario pues es un avance creo yo.

Sobre lo que comentas al final, la demo de ue5 estaba funcionando así y Ratchet según comentan está funcionando así o de manera similar, descartando lo que no estás viendo en pantalla.

No se que tiene que ver el tocino con la velocidad. UE5 es un motor nuevo y en la demo que mostraron usaron texturas a 8k ¿que quieres decir con eso? ¿cual es el avance en ?

Yo no estoy hablando de lo que dice o deja de decir la gente en los foros, estoy hablando de los frios numeros oficiales y que con ellos en la mano, no es posible hacer eso que tu estas diciendo (salvo que haya algo que no nos hayan contado).

Que todo lo que tendría que mover ps5 en este caso sería imposible tenerlo todo en la memoria y menos justo a tiempo si no fuese por el SSD.


Sobre lo otro



Que sea posible o no según los números como estás diciendo ya ni idea.

Pues eso que dice el tweet es más o menos el sampler feedback de Microsoft, aunque un paso por detrás ya que es "olvidar lo que ya no se ve" a lo que DX12U añade "no cargar las texturas que también tienes delante y no se ven..."

Entiendo yo vamos...

https://www.xataka.com/videojuegos/nuev ... a-texturas

Lo importante de todo esto es que empiecen a usarse toooodos estos truquitos y me importa poco en si se "caen los huevos" yo quiero 4K@60 o 1440p@120fps... Ya no puedo con los 30.

davidDVD escribió:

bigfoot_ escribió:1. Desde el desconocimiento y sin ganas de flammear, cuando salió el Spiderman MM, la gente se hacía pajas con la transición de una fase a mundo abierto (recuerdo un gif que salía por una ventana de una iglesia o algo así), que eso era el magicSSD y no se qué, que menuda velocidad de carga para volver al mundo abierto...

1Luego en PS4 resultaba que era idéntico (salvando distancias de dibujado, resolución etc etc), pero es que en ps4 el kraken y no se que ostias, vamos excusas varias pero víctimas del hype que no se bajaban de la burra...

2. A mí el que cambies de mapa rápido-instantáneo no dice nada de la velocidad del SSD (entiéndeme que sea la polla que lo es pero no deja de ser un ssd), más si cuando aparece la ventana esa dimensional ya se ha cargado en la RAM el mapa al que vas a saltar...

3. Resumiendo que lo que te quería preguntar, ¿os referís a la velocidad del SSD, sólo por ese cambio de mapas?

1. Pero ese es un cross-gen, ahí no hace falta "alinear" los componentes para que no haya esperas, la base es una PS4 con HDD... cualquier placa base actual podría (ya que es simplemente acceder/cargar rápido, quitas la transición)

2. Lo del Ratchet yo lo veo más complicadete, no por nada, más bien porque están sacando cosas (para PC) del mismo estilo de lo que presentó Cerny para PS5 en su día (acceso directo sin pasar por CPU o tal), de momento yo no sé si sirve lo actual (tal y cómo está planteado); más que nada porque no hay otro juego que haga lo mismo (creo); de momento no actualizo el PC por si acaso

3. Es lo que Nvidia (RTX IO) o Cerny presentó (lecturas directas sin intervención de CPU, y demás cosas técnicas xD)

Gracias por responder sin fanatismos, hemos creado un debate muy chulo que no es común por aquí...

Al final como le digo al compi, se parece el sampler feedback sin ser lo mismo.

Buena tecnología en todo caso. Y es lo que hará mantenerse a ambas consolas luchando con PCS varios años.

Mulzani escribió:@Zeta V

A ver, es porque ya no es necesario precargar de antemano tantas texturas o elementos.

Antes, en una consola, si querías eliminar el tener que hacer una pantalla de carga, necesitas ir cargando los datos de antemano para poder quitar la pantalla de carga, eso implica tener residente en memoria muchos datos que no se usarán hasta pasado un tiempo, por lo que estás limitando la cantidad de memoria RAM disponible para la escena actual.

Con la carga mediante el SSD (y las tecnologías asociadas), puedes cargar los datos casi sobre la marcha, permitiendo poder usar más memoria RAM para la escena actual y menos para la que va a venir, porque podrás ir cargándola a posteriori.

De ahí que permitas meter, o más variedad de texturas, o con más calidad...

Para un mundo abierto, es una mejora importante en cuanto a meter más calidad, para un escenario cerrado, con cargas por nivel, la diferencia no es tan palpable, salvo en el tiempo de carga.

Eso sí, el limitante de la GPU va a seguir estando ahí, si tu GPU sólo permite disponer de una cantidad de elementos en escena, el uso del SSD no va a permitir aumentar dichos elementos.

Primero de todo agradezco que te hayas tomado tu tiempo en responder.

A ver si consigo explicar el quid de la cuestión, porque no estamos hablando exactamente de lo mismo.

La teoria que tu explicas, el razonamiento que hay detras, lo entiendo. Es lo que se ha comentado durante estos ultimos meses cantidad de veces en los foros. El problema viene cuando trato de coger ese planteamiento y trasladarlo a la realidad numérica de los hardware, porque no encaja (o no me encaja con los calculos que hago que igual estan mal).

Lo que muestras en pantalla viene de la RAM. No puedes usar toda la ram porque para ello la transferencia entre SSD y RAM tendria que ser inmediata y esta muy lejos de serlo. Asi que si o si, tienes que reservar una parte de la RAM a aquello que no se esta viendo (mientras se carga del SSD). Ya solo con este simple razonamiento se viene abajo ese mito de que en Ps5 se cargan las cosas al vuelo y el tiro de la camara y tal.

Pero voy mas alla. Tu lo que planteas es que debido a la mayor velocidad del SSD, el espacio reservado a lo que no se ve, disminuye. ¿cuanto disminuye? Si tenemos un juego a 30 fps (por tirar a la baja), tenemos que renderizar un frame en 1/30= 0.03 segundos. El ancho de banda del SDD de Ps5 son 5.5 G/s. Ahora aplico una regla de tres. Igual aqui estoy haciendo algo mal, igual no entiendo las medidas de hardware (si es asi que alguien me corrija). Si 0.03 es el tiempo maximo de espera para renderizar la escena, en ese tiempo tengo que pasar las texturas del SSD. 0.03*5.5= 0.165 Gb, osea 165 megas de texturas. ¿se calcularia asi? o lo estoy haciendo mal? Porque segun estos numeros la cantidad disponible para mejorar texturas es muy inferior a 165 megas, ya que en 0.03 segundos no solo tienes que pasarlos a la Ram, es que hay que renderizar la escena y pasarlo a pantalla. No se cuanto quedaría, pero ya 165 megas de 16 gigas de Ram es una cifra inapreciable, y estamos hablando de que en la practica es mucho menos cantidad de megas.

Battlefield 2042.



El trailer... del trailer.

Gameplay para el 13 de junio

Con la carga mediante el SSD (y las tecnologías asociadas), puedes cargar los datos casi sobre la marcha, permitiendo poder usar más memoria RAM para la escena actual y menos para la que va a venir, porque podrás ir cargándola a posteriori.

Que todo lo que tendría que mover ps5 en este caso sería imposible tenerlo todo en la memoria y menos justo a tiempo si no fuese por el SSD

.

Segun Carmack esto no es asi, un disco SATA podria hacer lo mismo si el I/O esta configurado de una manera especifica

John Carmack (Doom, Quake) contradice afirmaciones sobre PS5 de Tim Sweeney (Epic)

Fuente

Carmack explica que "en efecto, ser capaz de cargar datos desde el disco SSD con el mismo formato de la GPU es un gran avance" pero no todo es tan prometedor "el único "pero" que le pongo a Tim Sweeney es que pueden sortear los buffer de kernel en PC con IO sin buffer"

En este caso, un antiguo disco duro SATA SSD le permitía mayor velocidad de acceso a los datos que una configuración más nueva, y muestra las diferentes velocidades. Parece que la clave está en la IO sin buffer.

Pero bueno, esa fue parte de la mentira que Tim quiso colar de que solo con un disco NVME era posible eso (a lo que los fans llevaron a reiterpretar que "solo con el disco NVME de PS5 es posible eso") y luego vino carmack y la tiro abajo con una demostración. Y despues epic china la remato al final.

Por otro lado, supongamos a la vez que si poseemos una 3090 con 24 GB de ram... para que queremos un SSD super rapido para ir cargando directamente, si ya podemos cargar todo en 8K en la misma memoria de la grafica. Osea que eso del disco NVME es mas bien un parche o a la falta de memoria de la GPU o a la mala configuracion del I/O del disco

Y yo que pense que el nivel maximo de flipada eran las ultimas peliculas del Fast&Furious, lo del trailer del Battlefield CGI con el piloto saltando del avion con el bazooka en mano para derribar otro avion y volver al suyo ya alcanza niveles estratosfericos de ridiculo.............y gameplay en la conferencia de MS, pues vale, lo podian haber dicho antes y me hubiese ahorrado ver ésto que no aporta absolutamente nada.

Me ha parecido estar viendo Fast & Furious, en serio. Bueno, ahora el 13 toca gameplay, veremos qué tal? El 13 hay confe de EA o lo esperamos para la de Microsoft?

Veo que no soy el único que ha pensado en F&F

Lo de battlefield lamentable, retrasamos la presentación 1 hora para un trailer, ni han hablado del juego, ni han mostrado gameplay, ni nada, pues nada el 13 veremos gameplay en la de xbox y supongo que hablaran del juego en la de EA de dentro de 1 mes

triki1 escribió:Y yo que pense que el nivel maximo de flipada eran las ultimas peliculas del Fast&Furious, lo del trailer del Battlefield CGI con el piloto saltando del avion con el bazooka en mano para derribar otro avion y volver al suyo ya alcanza niveles estratosfericos de ridiculo.............y gameplay en la conferencia de MS, pues vale, lo podian haber dicho antes y me hubiese ahorrado ver ésto que no aporta absolutamente nada.

Básicamente están recreando escenas de otros battlefield

exar escribió:Me ha parecido estar viendo Fast & Furious, en serio. Bueno, ahora el 13 toca gameplay, veremos qué tal? El 13 hay confe de EA o lo esperamos para la de Microsoft?

Veo que no soy el único que ha pensado en F&F

En la de xbox la de EA si mal no recuerdo era en julio