Hablemos del interior de Xbox One

(mensaje borrado)
No creo que sea plan de pedir respeto y educación a nadie cuando se entra al hilo poco menos que invitando a que se vayan del foro y monten un blog los que no quieran respuestas. Más aplicarse el cuento lo primero.
Yo no se que tipo de paja mental se hizo mas de uno con la nube antes de salir la consola...yo como cliente me siento completamente informado por parte de Microsoft de como va el tema...video de forza explicando el tema...video de titanfall explicando el tema y video de Albert penello hablando de la computación EN UN FUTURO...eso sí, lo que no he leído ni visto es que los juegos en un inicio iban hacer uso de la computación a nivel de física o iluminación...por mi parte ha cumplido y de sobra con lo que ha ido informando..y por lógica pienso que si siguen en la linea de cumplir lo que dicen...veremos Cloud Computing y mejores juegos.
No se porque os estáis liando tanto si ya se veía en la hoja de ruta de la Xbox One que Microsoft tenía pensada su implementación a partir del 2015, básicamente una vez estuviera disponible el DirectX 12 que será lo que permita usarla para procesos gráficos y los desarrolladores empiecen entonces a sacarle partido.

Si os fijáis para lo único que se ha usado la nube de momento si no me equivoco ha sido para apoyar cálculos que suelen ser de la CPU, como la IA de FM5 y Titanfall y algunas de las físicas de este último.
Es la segunda vez que pido que se eviten esos comentarios jocosos atacando a los usuarios, que no aportan absolutamente nada al debate y solo crean mal rollo.

Malo va a ser que tenga que volver a repetir lo mismo, porque el descanso no va a ser precisamente corto.
ahona escribió:Malo va a ser que tenga que volver a repetir lo mismo, porque el descanso no va a ser precisamente corto.


Frase de padre!!!! Jajajajaja. Niños, ya sabeis, hacer caso a papi :P

A ver, hay cosas que microsoft no ha implementado aun, nos estan diciendo que van a venir pero que necesitan tiempo, creo que hay otros que tambien dicen lo mismo y no pasa nada, con lo que tengamos algo de paciencia.

Por ahora ya he visto cosas funcionando en la nube y he visto videos que demuestran que habra mas mejoras, ahora quiero ver los juegos con ellas funcionando.
No creo q sea sospechoso de antixboxero xd, pero estoy totalmente de acuerdo con zokormazo. Siempre he creido en el tema de la nube, pero va siendo hora q lo empiecen a mostrar de manera practica. Los drivatares y autotitanes no son para nada revolucionarios, quiero mas, mucho mas. A ver si muestran algo en este e3.
Strife 117 escribió:No se porque os estáis liando tanto si ya se veía en la hoja de ruta de la Xbox One que Microsoft tenía pensada su implementación a partir del 2015, básicamente una vez estuviera disponible el DirectX 12 que será lo que permita usarla para procesos gráficos y los desarrolladores empiecen entonces a sacarle partido.

Si os fijáis para lo único que se ha usado la nube de momento si no me equivoco ha sido para apoyar cálculos que suelen ser de la CPU, como la IA de FM5 y Titanfall y algunas de las físicas de este último.


Es muy sencillo, no les interesa mirarla. No les interesa escucha ni leer nada sobre el tema, porque sino no podrían trollear y soltar todas las tonterías que quisieran. Cuando dices cosas como el forza o el titanfall sueltan "es que eso no es nada, es que eso lo hace cualquiera, es que yo espero más, es que..". El caso es decir alguna tontería.
Decir q espero mas de unos drivatares y autotitanes es una tonteria? Vaya tela...
Stylish escribió:Joder macho. ¿Qué más da procesar una suma que el cálculo de una iluminación? Cualitativamente es exactamente lo mismo.

Tu puedes mandar a procesar a la nube en tiempo real lo que te salga de la punta del capullo, lo que Microsoft ha vendido, y con razón, es que Azure es capaz de ejecutar código en la CPU y en la GPU porque su runtime y su tecnología de virtualización así se lo permite, y no hay más.

Una vez sabido esto, que no es la primera vez que lo digo, tu puedes pedirle a Azure que te monte un servidor de base de datos y una máquina virtual corriendo apache para servir una página web o le puedes pedir que pasándole una geometría y los puntos de luz calcule en tiempo real la iluminación. Es una diferencia cuantitativa, no cualitativa.



Sinceramente ante tus últimos comentarios solo puedo decirte que estás sumamente equivocado (ni sabes lo que es un motor gráfico ni por lo visto lo que es un paradigma en programación... que si eres informático tiene tela marinera esto ultimo...), ya que en base a un vídeo y unas declaraciones lo siento pero no se puede afirmar nada categóricamente, con razonamientos, en cambio, si. He aquí unos cuantos:



Pasemos a definir básicamente lo que pretende microsoft con su arquitectura de cloud compute-gaming, lo que microsoft está definiendo es un cambio de paradigma en toda regla en el entorno cliente servidor, que cambia la premisa bien conocida de tarea entregada, tarea ejecutada, resultado devuelto, por encapsular esto en un entorno de ejecución en tiempo real. Esto transforma completamente el comportamiento del servidor y del cliente, ya que no tiene NINGÚN sentido que se envíe una respuesta a una petición de cálculos cuando la necesidad de ese dato es temporalmente inexistente (la has dejado atrás en el tiempo), un cliente de renderizado no espera por nadie que no sea hardware local, si pretendes esperar por la nube para renderizar algo la llevas clara (las latencias pueden ser enormes), el cliente en el modelo cliente servidor SIEMPRE espera la recepción del resultado de forma indefinida (hasta que se rebasa el TTL esperado para no colgar procesos, por supuesto), en este caso el cliente no va a esperar a nadie, por lo que el servidor tiene que asegurar unos plazos de ejecución mínimos que serán exigidos por el cliente para no fallar en la entrega y por tanto estropear por ello el renderizado de la escena.

Ahora imaginemos un par de casos prácticos para ilustrar una serie de diferencias cruciales para entender la problemática que este tipo de renderizado supone:

Caso 1º:
Tenemos un juego con un motor gráfico estándar basado en un modelo de renderizado local normal, a excepción de un detalle, el motor renderiza un mundo abierto y realista con ciclos de noche ya, cada minuto el sistema cambia la posición del punto luminoso principal de la escena a partir del cual se calculan todas las matrices de transformación/rotación/escalado de cada objeto para aplicarlas después a los bitmaps que forman las texturas de terceros objetos creando así la sombra como una representación 2D del objeto (esto es posible dado que el punto de luz permanecerá fijo en el cielo durante 1 minuto). en este caso la latencia máxima de recepción de la información calculada (matriz de transformaciones apilada) de forma remota por el servidor será de 55 segundos, reservándose 5 segundos para hacer un calculo aproximado (usando un modelo de geometría simple) en local en caso de que fuera necesario.

Caso 2º(Empleemos el del vídeo que has enlazado en tu ultimo mensaje):
Tenemos un juego con un motor gráfico mas modificado, que ha implementado las físicas con un sistema de calculo remoto para las colisiones, transformaciones, escalados y rotaciones de todos los chunks que se crean al partir la geometría compleja que forma los edificios (esto es posible siempre y cuando se reciban los datos (matriz de transformaciones apilada) a tiempo para volver a renderizar cada chunk correspondiente en su situación correcta una vez aplicados los cálculos del servidor) esto posibilita realizar cálculos complejos sobre miles de objetos en mucho menos tiempo de lo que permite el cliente por si mismo, pero ha de hacerse en menos tiempo de lo que tarda en renderizarse un frame (entre 2 y 5ms) restando el framerate al que estás renderizando. en este caso tenemos 32FPS osea 31.25ms y 5ms dan 26,25 ms como máximo para tener el dato en memoria desde que se renderiza el frame anterior.

(tiempo de renderizado de un frame en cryengine (mismo motor que el Ryse), busca el tiempo completo "sum all passes")
Imagen


Como se puede comprobar perfectamente el primero de los 2 casos es idóneo para la implementación del sistema de renderizado no local, tienes una tasa de refresco muy lenta que te permite enviar una petición sin problemas y que sea contestada varias veces en caso de perdida de paquetes u otros problemas de la red. pero... que ganas realmente? te ahorras un calculo que se hace cada minuto? y eso tiene un gran impacto en el rendimiento del juego? ya te digo yo que no, ese calculo se puede partir en zonas y hacerlo en los tiempos que sobren entre frames sin problemas, por lo que mandar eso a la nube no va a mejorar prácticamente para nada el rendimiento del motor gráfico.

pero sin embargo, que sucede en el segundo ejemplo? pues sencillo, para que te hagas una idea leete este post y las respuestas al mismo: http://stackoverflow.com/questions/88093/how-many-game-updates-per-second el motor se actualiza de unas 20 veces por segundo a unas 100 según los requisitos del juego, si tienes que mandar una petición y esperar respuesta para unos cálculos que tienen que hacerse 20 veces por segundo vas a tener que usar una conexión a Internet con muy poca latencia, para que te hagas una idea:

Imagen

se emplea un tiempo precioso en establecer una conexión y en enviar y esperar la recepción de una respuesta, mas que el envío de los datos en si (que con nuestras redes actuales seria despreciable) tenemos que tener en cuenta las latencias que hay en la comunicación ya que no se donde esperas que estén los servidores de Azure en Europa pero te garantizo de antemano que en España no hay, los pings de gente que ha hecho comprobaciones en titanfall rondan los 100ms o mas (no es casualidad que los bots del titanfall sean tan mancos), y estando en países del norte de Europa, aquí en España bien podrían superar esa cifra, que sitúa el refresco de las físicas en menos de lo necesario para hacerlas realistas, mucho menos de hecho, pero hagamos el calculo:

Para refrescar en cada frame tenemos la necesidad de ser capaces de pedir un dato y recibir respuesta en menos tiempo del que tardará en ejecutarse la siguiente vez nuestro código de físicas, esto supone un intervalo de 50ms como máximo entre actualizaciones, de ahi la cifra irá a menos cuanto mejor sea el juego, sabiendo que un paquete tiene que ir de ida y vuelta para poder recibir una respuesta y siendo EXTREMADAMENTE generosos con el servicio de Azure y suponiendo un solo mensaje para realizar una petición y un solo mensaje de vuelta con el resultado tenemos que necesitamos el tiempo de ping (Round Trip Time) cumplido a rajatabla sin contar con la operación en remoto (que si la difieres es compleja, no algo trivial) por lo que puedes suponer que necesitas tener una red que funcione al menos a 40ms de latencia suponiendo 10ms de ejecución en remoto. Sabiendo el ping que hay con los servicios Azure pretendes decirme que actualmente se podría hacer algo serio con esta tecnología y ademas mantener todo el trafico de una partida multiplayer por ejemplo? déjame que te lo niegue categóricamente, de hecho si esto fuera posible haría mucho que se hubiera implementado(ya que hace tiempo que tenemos latencias así y la capacidad de computo en la nube), azure no tiene nada de especial en el plano gaming y como servidores no son mejores que otros muchos, sencillamente son mas sencillos de usar y con un precio competitivo para la calidad que ofrecen...

En definitiva, hasta que no mejoren sobre todo las redes yo dudo mucho que veamos cosas significativas realizadas con esto a menos que se precalculen con mucha antelación (segundos), pero eso seria equivalente a scriptar los efectos y que se ejecuten con unas físicas pre-calculadas, para que entonces necesitas la nube?

un saludo.
elalexel escribió:
Stylish escribió:Joder macho. ¿Qué más da procesar una suma que el cálculo de una iluminación? Cualitativamente es exactamente lo mismo.

Tu puedes mandar a procesar a la nube en tiempo real lo que te salga de la punta del capullo, lo que Microsoft ha vendido, y con razón, es que Azure es capaz de ejecutar código en la CPU y en la GPU porque su runtime y su tecnología de virtualización así se lo permite, y no hay más.

Una vez sabido esto, que no es la primera vez que lo digo, tu puedes pedirle a Azure que te monte un servidor de base de datos y una máquina virtual corriendo apache para servir una página web o le puedes pedir que pasándole una geometría y los puntos de luz calcule en tiempo real la iluminación. Es una diferencia cuantitativa, no cualitativa.



Sinceramente ante tus últimos comentarios solo puedo decirte que estás sumamente equivocado (ni sabes lo que es un motor gráfico ni por lo visto lo que es un paradigma en programación... que si eres informático tiene tela marinera esto ultimo...), ya que en base a un vídeo y unas declaraciones lo siento pero no se puede afirmar nada categóricamente, con razonamientos, en cambio, si. He aquí unos cuantos:



Pasemos a definir básicamente lo que pretende microsoft con su arquitectura de cloud compute-gaming, lo que microsoft está definiendo es un cambio de paradigma en toda regla en el entorno cliente servidor, que cambia la premisa bien conocida de tarea entregada, tarea ejecutada, resultado devuelto, por encapsular esto en un entorno de ejecución en tiempo real. Esto transforma completamente el comportamiento del servidor y del cliente, ya que no tiene NINGÚN sentido que se envíe una respuesta a una petición de cálculos cuando la necesidad de ese dato es temporalmente inexistente (la has dejado atrás en el tiempo), un cliente de renderizado no espera por nadie que no sea hardware local, si pretendes esperar por la nube para renderizar algo la llevas clara (las latencias pueden ser enormes), el cliente en el modelo cliente servidor SIEMPRE espera la recepción del resultado de forma indefinida (hasta que se rebasa el TTL esperado para no colgar procesos, por supuesto), en este caso el cliente no va a esperar a nadie, por lo que el servidor tiene que asegurar unos plazos de ejecución mínimos que serán exigidos por el cliente para no fallar en la entrega y por tanto estropear por ello el renderizado de la escena.

Ahora imaginemos un par de casos prácticos para ilustrar una serie de diferencias cruciales para entender la problemática que este tipo de renderizado supone:

Caso 1º:
Tenemos un juego con un motor gráfico estándar basado en un modelo de renderizado local normal, a excepción de un detalle, el motor renderiza un mundo abierto y realista con ciclos de noche ya, cada minuto el sistema cambia la posición del punto luminoso principal de la escena a partir del cual se calculan todas las matrices de transformación/rotación/escalado de cada objeto para aplicarlas después a los bitmaps que forman las texturas de terceros objetos creando así la sombra como una representación 2D del objeto (esto es posible dado que el punto de luz permanecerá fijo en el cielo durante 1 minuto). en este caso la latencia máxima de recepción de la información calculada (matriz de transformaciones apilada) de forma remota por el servidor será de 55 segundos, reservándose 5 segundos para hacer un calculo aproximado (usando un modelo de geometría simple) en local en caso de que fuera necesario.

Caso 2º(Empleemos el del vídeo que has enlazado en tu ultimo mensaje):
Tenemos un juego con un motor gráfico mas modificado, que ha implementado las físicas con un sistema de calculo remoto para las colisiones, transformaciones, escalados y rotaciones de todos los chunks que se crean al partir la geometría compleja que forma los edificios (esto es posible siempre y cuando se reciban los datos (matriz de transformaciones apilada) a tiempo para volver a renderizar cada chunk correspondiente en su situación correcta una vez aplicados los cálculos del servidor) esto posibilita realizar cálculos complejos sobre miles de objetos en mucho menos tiempo de lo que permite el cliente por si mismo, pero ha de hacerse en menos tiempo de lo que tarda en renderizarse un frame (entre 2 y 5ms) restando el framerate al que estás renderizando. en este caso tenemos 32FPS osea 31.25ms y 5ms dan 26,25 ms como máximo para tener el dato en memoria desde que se renderiza el frame anterior.

(tiempo de renderizado de un frame en cryengine (mismo motor que el Ryse), busca el tiempo completo "sum all passes")
Imagen


Como se puede comprobar perfectamente el primero de los 2 casos es idóneo para la implementación del sistema de renderizado no local, tienes una tasa de refresco muy lenta que te permite enviar una petición sin problemas y que sea contestada varias veces en caso de perdida de paquetes u otros problemas de la red. pero... que ganas realmente? te ahorras un calculo que se hace cada minuto? y eso tiene un gran impacto en el rendimiento del juego? ya te digo yo que no, ese calculo se puede partir en zonas y hacerlo en los tiempos que sobren entre frames sin problemas, por lo que mandar eso a la nube no va a mejorar prácticamente para nada el rendimiento del motor gráfico.

pero sin embargo, que sucede en el segundo ejemplo? pues sencillo, para que te hagas una idea leete este post y las respuestas al mismo: http://stackoverflow.com/questions/88093/how-many-game-updates-per-second el motor se actualiza de unas 20 veces por segundo a unas 100 según los requisitos del juego, si tienes que mandar una petición y esperar respuesta para unos cálculos que tienen que hacerse 20 veces por segundo vas a tener que usar una conexión a Internet con muy poca latencia, para que te hagas una idea:

Imagen

se emplea un tiempo precioso en establecer una conexión y en enviar y esperar la recepción de una respuesta, mas que el envío de los datos en si (que con nuestras redes actuales seria despreciable) tenemos que tener en cuenta las latencias que hay en la comunicación ya que no se donde esperas que estén los servidores de Azure en Europa pero te garantizo de antemano que en España no hay, los pings de gente que ha hecho comprobaciones en titanfall rondan los 100ms o mas (no es casualidad que los bots del titanfall sean tan mancos), y estando en países del norte de Europa, aquí en España bien podrían superar esa cifra, que sitúa el refresco de las físicas en menos de lo necesario para hacerlas realistas, mucho menos de hecho, pero hagamos el calculo:

Para refrescar en cada frame tenemos la necesidad de ser capaces de pedir un dato y recibir respuesta en menos tiempo del que tardará en ejecutarse la siguiente vez nuestro código de físicas, esto supone un intervalo de 50ms como máximo entre actualizaciones, de ahi la cifra irá a menos cuanto mejor sea el juego, sabiendo que un paquete tiene que ir de ida y vuelta para poder recibir una respuesta y siendo EXTREMADAMENTE generosos con el servicio de Azure y suponiendo un solo mensaje para realizar una petición y un solo mensaje de vuelta con el resultado tenemos que necesitamos el tiempo de ping (Round Trip Time) cumplido a rajatabla sin contar con la operación en remoto (que si la difieres es compleja, no algo trivial) por lo que puedes suponer que necesitas tener una red que funcione al menos a 40ms de latencia suponiendo 10ms de ejecución en remoto. Sabiendo el ping que hay con los servicios Azure pretendes decirme que actualmente se podría hacer algo serio con esta tecnología y ademas mantener todo el trafico de una partida multiplayer por ejemplo? déjame que te lo niegue categóricamente, de hecho si esto fuera posible haría mucho que se hubiera implementado(ya que hace tiempo que tenemos latencias así y la capacidad de computo en la nube), azure no tiene nada de especial en el plano gaming y como servidores no son mejores que otros muchos, sencillamente son mas sencillos de usar y con un precio competitivo para la calidad que ofrecen...

En definitiva, hasta que no mejoren sobre todo las redes yo dudo mucho que veamos cosas significativas realizadas con esto a menos que se precalculen con mucha antelación (segundos), pero eso seria equivalente a scriptar los efectos y que se ejecuten con unas físicas pre-calculadas, para que entonces necesitas la nube?

un saludo.


Me encantaría contestar a todas las gilipolleces que has escrito porque me parece interesante contestar, pero la falta de respeto absurda, gratuita y vacía que has hecho en tus primeras líneas hacen que te ignore completamente y reporte tu mensaje. Pensando además que eres un individuo que no merece ni siquiera mi atención.

Celebro que tengas tan claro como funciona la tecnología que ni has visto, ni has entendido ni has implementado. No tengo nada que aportarte y no lo haré.
elalexel
El primer parrafo descalificando a un usuario te ha sobrado. El resto esta bastante bien.
Stylish escribió:Me encantaría contestar a todas las gilipolleces que has escrito porque me parece interesante contestar, pero la falta de respeto absurda, gratuita y vacía que has hecho en tus primeras líneas hacen que te ignore completamente y reporte tu mensaje. Pensando además que eres un individuo que no merece ni siquiera mi atención.

Celebro que tengas tan claro como funciona la tecnología que ni has visto, ni has entendido ni has implementado. No tengo nada que aportarte y no lo haré.


si te parece una falta de respeto que te muestren tus carencias es que las tienes, de hecho todos las tenemos, ¿pero te has de ofender porque te digan que ignoras ciertas cosas? creo que todos podemos aprender leyendo y escuchando de los demás cuando nos dicen que nos estamos equivocando, y me encantaría que contestaras a las gilipolleces que según tu suelto, ya que no te he visto razonar ninguno de tus argumentos hasta ahora... este, como no, tampoco. :-|

un saludo
Creo que algunos os pasáis los avisos de Moderación por los forros, muy bien.

elalexel: Eso no son formas, NO.
elalexel escribió:
Stylish escribió:Me encantaría contestar a todas las gilipolleces que has escrito porque me parece interesante contestar, pero la falta de respeto absurda, gratuita y vacía que has hecho en tus primeras líneas hacen que te ignore completamente y reporte tu mensaje. Pensando además que eres un individuo que no merece ni siquiera mi atención.

Celebro que tengas tan claro como funciona la tecnología que ni has visto, ni has entendido ni has implementado. No tengo nada que aportarte y no lo haré.


si te parece una falta de respeto que te muestren tus carencias es que las tienes, de hecho todos las tenemos, ¿pero te has de ofender porque te digan que ignoras ciertas cosas? creo que todos podemos aprender leyendo y escuchando de los demás cuando nos dicen que nos estamos equivocando, y me encantaría que contestaras a las gilipolleces que según tu suelto, ya que no te he visto razonar ninguno de tus argumentos hasta ahora... este, como no, tampoco. :-|

un saludo


Simplemente te voy a poner una cita de un usuario de este foro, que imagino que habrás leído, y luego te diré que si para cada petición al servidor piensas que la única opción es abrir una conexión, negociar una llamada y recibir un dato, entenderás absolutamente imposible el juego online, ¿no? DIOS, ¡SI ES IMPOSIBLE RECIBIR DATOS DE UN SERVIDOR EN TIEMPO REAL!

Anda machote, baja los caballos y vete a faltar al respeto a quien yo te diga.

hay cosas que son mas sensibles a la latencia que otras, y por lo tanto son mas candidatas a poderse calcular en la nube que otras.

La generacion de los graficos 3D no se puede sacar a la nube, eso lo va a tener que seguir pintando la xbox, pero hay muchas cosas mas que necesita un juego:
- IA: 200ms e incluso 300ms es aceptable para una IA decente. es mas o menos el lag que tendria un humano jugando en multiplayer. La XboxONE enviaria el estado de juego a la nube, la nube calcularia las respuestas de los PNJ (Personajes no jugadores) y enviaria la respuesta a la consola. a efectos practicos, es como si estuvieses jugando online con bots calculados en la nube.
- fisicas: hasta 500ms pueden ser aceptables. cuando disparas un cohete sobre una pared, el como se rompe la pared y vuelan los cachitos independientemente, incluso chocando entre si y con el entorno, pueden ser calculados en la nube y enviados a la consola. para la consola no son mas que otros 'objetos estaticos a pintar' en pantalla, ya que no tiene que llevar la contabilidad de la velocidad ni el efecto de la gravedad sobre ellos.
- iluminacion indirecta: hay un video muy chulo de nVidia en el cual, una latencia de 50ms es inapreciable y una de 200ms es tolerable
- iluminacion directa: esto es mas delicado, y una latencia de 50ms empieza a ser molesta.
Nuevamente te doy la razón Stylish. No solo es del todo posible con las conexiones ya existentes sino que es más inminente de lo que se cree. No estamos hablando de 3-4 ni 5 años vista, sino de una franja mínima de 1 año y máxima de 2.

Se han hecho pruebas hasta con conexiones de 20mb, para ver el límite minimo tolerable para que el resultado fuese aceptable, y la computación se hacía sin ningún problema y se recibía en el dispositivo cliente en idénticas circunstancias. Por lo que dicen, incluso con una conexión de 10-15mb podría funcionar de una manera minimamente aceptable, y eso que se sigue avanzando, por lo que no descartaría que el requisito de conexión sea incluso menor más adelante. Aquí veo hablando muy a la ligera en el sentido similar al fenómeno que en Hobby Consola decía que se necesitan mas de 100mb y una latencis de 0ms, pero dejando disparates del estilo al margen, no se tienen en cuenta los tiled resources. Repito: tiled resources. Solo nos fijamos en que unas texturas aparentemente potentes deberían ocupar bastante y por tanto requerir de una línea rápida y una latencia bajisima para poder correrlos en nuestro dispositivo local de turno sin que se resienta. Pero lo que se obvia es que con los tiled resources es posible "comprimir" esas texturas y descomprimirlas en tiempo real de manera inapreciable, y que esas texturas de máxima calidad, gracias a su compresión, se pueden comunicar del servidor al cliente con una conexión decentita. Los tiled no se han inventado por amor al arte, sino que su vinculación a la computación en la nube está más que prevista desde un principio.
Forzimbras escribió:Nuevamente te doy la razón Stylish. No solo es del todo posible con las conexiones ya existentes sino que es más inminente de lo que se cree. No estamos hablando de 3-4 ni 5 años vista, sino de una franja mínima de 1 año y máxima de 2.

Se han hecho pruebas hasta con conexiones de 20mb, para ver el límite minimo tolerable para que el resultado fuese aceptable, y la computación se hacía sin ningún problema y se recibía en el dispositivo cliente en idénticas circunstancias. Por lo que dicen, incluso con una conexión de 10-15mb podría funcionar de una manera minimamente aceptable, y eso que se sigue avanzando, por lo que no descartaría que el requisito de conexión sea incluso menor más adelante. Aquí veo hablando muy a la ligera en el sentido similar al fenómeno que en Hobby Consola decía que se necesitan mas de 100mb y una latencis de 0ms, pero dejando disparates del estilo al margen, no se tienen en cuenta los tiled resources. Repito: tiled resources. Solo nos fijamos en que unas texturas aparentemente potentes deberían ocupar bastante y por tanto requerir de una línea rápida y una latencia bajisima para poder correrlos en nuestro dispositivo local de turno sin que se resienta. Pero lo que se obvia es que con los tiled resources es posible "comprimir" esas texturas y descomprimirlas en tiempo real de manera inapreciable, y que esas texturas de máxima calidad, gracias a su compresión, se pueden comunicar del servidor al cliente con una conexión decentita. Los tiled no se han inventado por amor al arte, sino que su vinculación a la computación en la nube está más que prevista desde un principio.


¿Cuando hablamos de esas tasas de transferencia hablamos de subida o de bajada? La cosa cambia considerablemente en relación a las ofertas de internet que tenemos en el país.
Bajada. La subida en la computación en Azure no es más que para dar la "orden" de computación. Donde se requiere la conexión es para descargar en tu dispositivo los datos ya computados remotamente, que es la fase trascendental.
Forzimbras escribió:Bajada. La subida en la computación en Azure no es más que para dar la "orden" de computación. Donde se requiere la conexión es para descargar en tu dispositivo los datos ya computados remotamente, que es la fase trascendental.


Apostillo que en los servidores de Azure pueden y están volcados los datos de cada mapeado del juego en cuestión. No tiene que pasárselos nadie, realmente de subida es muy poco requerimiento.

Luego lógicamente si es un juego que tiene millones de peticiones por hora, se empiezan a repetir y ya no tiene ni que calcularlas, se las cachea y las vuelca sin más. Si ya se que 2+2 son 4 porque ya he hecho el cálculo, para que voy a calcular otra vez? Respondo que son 4 y listo.
Stylish escribió:Simplemente te voy a poner una cita de un usuario de este foro, que imagino que habrás leído, y luego te diré que si para cada petición al servidor piensas que la única opción es abrir una conexión, negociar una llamada y recibir un dato, entenderás absolutamente imposible el juego online, ¿no? DIOS, ¡SI ES IMPOSIBLE RECIBIR DATOS DE UN SERVIDOR EN TIEMPO REAL!

Anda machote, baja los caballos y vete a faltar al respeto a quien yo te diga.


Crees que después de explicarte pormenorizadamente como funciona un ejemplo de render en remoto y de tener en cuenta en el análisis un socket abierto para comunicaciones de forma que ante una petición se conteste el resultado sin mas latencia que la generada por el mensaje y su respuesta en ambas direcciones no se perfectamente que se puede dejar una comunicación abierta y que no son necesarios mas que los mensajes de apertura de comunicación al inicio mientras no cierres el canal? me da que estás alterado y no te has tomado con calma la lectura, ya que expongo justamente este caso, si digo extremadamente generoso es porque obviamente esas conexiones hay que cerrarlas cada cierto tiempo por las características de un servicio como azure (y esto provocara que de vez en cuando lo que sea que estés calculando en remoto tendrá saltos en ciertos frames), si realmente han tocado los servidores entonces puede que esto no sea así pero si según tu no tienen nada de especial lo dudo encarecidamente.

Stylish escribió:
hay cosas que son mas sensibles a la latencia que otras, y por lo tanto son mas candidatas a poderse calcular en la nube que otras.

La generacion de los graficos 3D no se puede sacar a la nube, eso lo va a tener que seguir pintando la xbox, pero hay muchas cosas mas que necesita un juego:
- IA: 200ms e incluso 300ms es aceptable para una IA decente. es mas o menos el lag que tendria un humano jugando en multiplayer. La XboxONE enviaria el estado de juego a la nube, la nube calcularia las respuestas de los PNJ (Personajes no jugadores) y enviaria la respuesta a la consola. a efectos practicos, es como si estuvieses jugando online con bots calculados en la nube.


Siento decirte que esto no es cierto, en juegos como el counter los pro players tienen tiempos de reacción bastante mas bajos, en torno a los 150ms o menos (algunos bajan de los 100 pero hay MUY pocos), puedes comprobar tu propio tiempo de reacción con esta sencilla aplicación:

http://www.humanbenchmark.com/tests/reactiontime/

ten en cuenta que lo haces sin estar concentrado ni en el juego y que aun así el tiempo medio de respuesta de los usuarios es de 215ms, por lo que hay una buena parte de los usuarios por debajo de los 200ms que son la tasa que ponen como buena, siendo claramente inferiores a pro players y bastante mediocres, sobre todo si tendemos hacia los 300 que entonces son inútiles.

tambien puedes probar la aplicación enlazada en esta pagina http://www.tomshardware.co.uk/forum/236 ... speed-test
es bastante mas similar a un shooter y en las 2 pruebas que he hecho he bajado de 200ms.

Stylish escribió:
- fisicas: hasta 500ms pueden ser aceptables. cuando disparas un cohete sobre una pared, el como se rompe la pared y vuelan los cachitos independientemente, incluso chocando entre si y con el entorno, pueden ser calculados en la nube y enviados a la consola. para la consola no son mas que otros 'objetos estaticos a pintar' en pantalla, ya que no tiene que llevar la contabilidad de la velocidad ni el efecto de la gravedad sobre ellos.


esto es cierto siempre que esos objetos no interactuen con el resto del escenario, si hablamos del derrumbe de un edificio claro, pero para eso puedes escriptar la caída y punto, no necesitas renderizarla empezando por el punto justo en el que se ha roto en la partida, o sencillamente usar el típico truco de iniciar el derrumbe de forma local y cuando pasa a ocupar x porción del objeto iniciar el script, maneras hay muchas para convertir a ese uso de las físicas en algo bonito pero inútil. Sin embargo si esos objetos interactuan con el jugador es algo completamente distinto, ahí si que aportan valor pero tienen entonces que ser capaces de actualizar su posición y colisiones al mismo ritmo que el resto del juego, sino se ocasionarían problemas bastante graves de gameplay, la verdad.
Stylish escribió:
- iluminacion indirecta: hay un video muy chulo de nVidia en el cual, una latencia de 50ms es inapreciable y una de 200ms es tolerable
- iluminacion directa: esto es mas delicado, y una latencia de 50ms empieza a ser molesta.


la iluminación en tiempo real por las cifras que muestras y lo obvio del problema es bastante mas impracticable, todo depende de los "ticks" internos del juego (osea su tiempo interno) pero dudo que los juegos tiendan a eso, mas bien a lo contrario, a ejecutarse cada vez mas deprisa, ya que aplicaciones como la realidad virtual así lo exigen.


un saludo.
Pongo un post sobre esta tema de Flasbackman360

CLOUD COMPUTING: Vaya, al parecer funciona!

Ya desvelamos que la disposición del driver de la ethernet en XBox One extrañamente va regido a través del SoC de forma directa y no a través del procesador de apoyo de componentes como en PS4 y PC.
Imagen

Esto posibilita al "cerebro" de la máquina actuar con una ínfima latencia y anoche Microsoft explicó cómo con una demo técnica que muchos ya habréis visto.

Toda la geometría que entra en escena puede ser pre almacenada en la nube, "toda, es toda". Microsoft explica que cuando entras en el área del juego, solo tienen que hacer una copia del uso del ancho de banda local. la misma copia de cálculo podría ser utilizada para todos los jugadores en el caso de ser un juego cooperativo. La única cosa que se necesita enviar desde el "cliente" hacia la nube es la "posición inicial", la trayectoria y la aceleración de disparos se puede mandar con tan sólo 20bytes de información con una precisión perfecta para cada una de las balas. Para hacer un cálculo rápido, una ametralladora que dispare 10 balas por segundo necesitará que subamos con nuestra conexión 200bytes por segundo, más el ancho de banda de las cabeceras de IP inherentes para cada transferencia que son 20bytes para IPv4, 40bytes para IPv6. 240Bytes por segundo es el únido requisito neceseario para manejar y procesar el cálculo que requiere la destrucción a tiempo real de material. Eso es un ancho de banda de subida necesario insignificante, una conexión modem de 56k podría manejar eso.

https://www.youtube.com/watch?v=QxHdUDhOMyw

Los datos devueltos necesarios para el sistema local serán por norma general, mayores en volumen, pero está calculado de la misma manera. Además de la información de la bala que puede ser entendida como un vértice, es necesario enviar la geometría de la porción creada por la susodicha colisión y la rotación de la misma. Geometría del objeto, posicion inicial y aceleración centrípeta, son los únicos datos necesarios en el sistema local

Imagen

Podría apostar con una sencilla regla de 3 y como aproximación un máximo de 50bytes, por lo cual en el pico del vídeo se ve que había 36000 trozos, lo cual es una auténtica barbaridad y realmente no necesaria pero lo que sería compatible con una conexión de descarga de 25 megas, si todos estos datos se transmiten al mismo tiempo. Pero esto no es necesario porque, ya que los trozos no han sido generados simultáneamente, pueden ser branqueados 10 veces por segundo. Así que partiendo de la base que no hay más de 100 trozos generados por cada centésima de segundo al mismo tiempo, una conexión que pueda enviar 10.000bytes, topes de 100ms es todo lo que requieres. Una conexión de 1Mbps bastaría facilmente para ver en tu casa la demo técnica que MS nos enseñó.

He utilizado un tiempo de respuesta de 100milisegundos ya que es un lag positivo y viable para físicas. (Probablemente tenéis menos ping en Titanfall) ya que por muy lejos que vivas del DNS y/o enrutador local, azure hace el resto. Lo normal es tener un ping hacia AZURE de un máximo de 60ms.

Imagen





Una pregunta:

El tema de las sombras se puede calcular sin problemas en la nube no?

El sol se mueve muy despacio, así que las sombras se pueden calcular sin importar el ping que haya. Hasta con un ping de 1000ms funcionaría a la perfección. Tampoco creo que hubiera problemas con el movimiento de la vegetación para proyectar su sombra. Luego ya las sombras de focos, linternas y derivados dejárselo a la consola.

Podríamos hacer una lista de procesos que se pueden delegar a la nube sin ser nada problemáticos con las latencias. Como por ejemplo:

1- Sombras proyectadas por el sol.
2- IA
3- Físicas de la vegetación
4- Físicas de destrucción
5- Metereología
6- Iluminación indirecta
7-...
laleshe escribió:No creo q sea sospechoso de antixboxero xd, pero estoy totalmente de acuerdo con zokormazo. Siempre he creido en el tema de la nube, pero va siendo hora q lo empiecen a mostrar de manera practica. Los drivatares y autotitanes no son para nada revolucionarios, quiero mas, mucho mas. A ver si muestran algo en este e3.

Las cosas se empiezan por el suelo no por el tejado,creo que se entiende
Aquí hay un par de individuos que vienen de buenas a primeras a decir lo que dijo MS sin tener ni idea. Ni idea de cloud computing tampoco.

Ni me voy a molestar a contestar la cantidad de tonterías que han soltado.

Sólo os resumo: con cloud computing se puede hacer lo que te de la real gana, y todo lo que se ha hecho hasta ahora lo usa del modo que mejor se ha ajustado a sus necesidades.
Horizonte de sucesos escribió:Una pregunta:

El tema de las sombras se puede calcular sin problemas en la nube no?

El sol se mueve muy despacio, así que las sombras se pueden calcular sin importar el ping que haya. Hasta con un ping de 1000ms funcionaría a la perfección. Tampoco creo que hubiera problemas con el movimiento de la vegetación para proyectar su sombra. Luego ya las sombras de focos, linternas y derivados dejárselo a la consola.

Podríamos hacer una lista de procesos que se pueden delegar a la nube sin ser nada problemáticos con las latencias. Como por ejemplo:

1- Sombras proyectadas por el sol.
2- IA
3- Físicas de la vegetación
4- Físicas de destrucción
5- Metereología
6- Iluminación indirecta
7-...


Bueno, si la luz del sol impactando en tu personaje proyecta una sombra, esa sombra no puede tener un retraso en ser calculada de 1 segundo, porque en ese caso iria un segundo por detras de ti :D Al igual que la sombra de los personajes o elementos moviles del escenario.

En el tema de fisicas de destruccion, como alguien ha comentado hace poco, depende de si los elementos que son destruidos pueden interactuar con tu personaje u otros personajes. Si rompes algo que te puede caer encima, pero lleva un retraso de medio segundo o un segundo, pues puede haber problemas. Imagina que empujas una roca en el borde de un precipicio. Si las fisicas se calculan en un servidor, tu puedes empujarla, pero las fisicas no haran efecto en ella hasta que recibas los datos de "la nube". Y ahi, como han dicho, igual hasta 200ms no se nota mucho, pero yo creo que 500ms se debe notar bastante.

Un saludo!
Para que las simulaciones físicas sean viables en tiempo real sin tener lag apreciable, supongo que van a necesitar generar precacheados de simulaciones. Por ejemplo, supongamos que queremos mover las ramas de un árbol con el viento en Watch Dogs. Sería absurdo calcular una y otra vez la posición de las ramas y hojas en base a las fuerzas aplicadas, porque seguramente, de entre varias peticiones que se hayan hecho al servidor, exista una que tenga unos datos de entrada sino idénticos, muy parecidos a los nuestros. En ese caso, el server devuelve directamente el diccionario de transformaciones necesarias para cada parte animada, tirando de esa caché.

Eso por supuesto sería aplicable a todos aquellos elementos que a lo largo de todos los clientes, sean susceptibles de enviar los mismos datos y petición al servidor. Por ejemplo iluminación global de un mapa.

Eso significa que las peticiones tardarían mucho menos en resolverse, y serían menos sensibles al lag.

La historia aquí es que las latencias que tenemos ya de por si son altas (de media unos 40ms de ping), así que tan sólo en la petición y respuesta, sin contar con el tiempo de procesamiento de la petición y cálculos en el lado del servidor, tendríamos un retardo curioso...
argam escribió:
Horizonte de sucesos escribió:Una pregunta:

El tema de las sombras se puede calcular sin problemas en la nube no?

El sol se mueve muy despacio, así que las sombras se pueden calcular sin importar el ping que haya. Hasta con un ping de 1000ms funcionaría a la perfección. Tampoco creo que hubiera problemas con el movimiento de la vegetación para proyectar su sombra. Luego ya las sombras de focos, linternas y derivados dejárselo a la consola.

Podríamos hacer una lista de procesos que se pueden delegar a la nube sin ser nada problemáticos con las latencias. Como por ejemplo:

1- Sombras proyectadas por el sol.
2- IA
3- Físicas de la vegetación
4- Físicas de destrucción
5- Metereología
6- Iluminación indirecta
7-...


Bueno, si la luz del sol impactando en tu personaje proyecta una sombra, esa sombra no puede tener un retraso en ser calculada de 1 segundo, porque en ese caso iria un segundo por detras de ti :D Al igual que la sombra de los personajes o elementos moviles del escenario.

En el tema de fisicas de destruccion, como alguien ha comentado hace poco, depende de si los elementos que son destruidos pueden interactuar con tu personaje u otros personajes. Si rompes algo que te puede caer encima, pero lleva un retraso de medio segundo o un segundo, pues puede haber problemas. Imagina que empujas una roca en el borde de un precipicio. Si las fisicas se calculan en un servidor, tu puedes empujarla, pero las fisicas no haran efecto en ella hasta que recibas los datos de "la nube". Y ahi, como han dicho, igual hasta 200ms no se nota mucho, pero yo creo que 500ms se debe notar bastante.

Un saludo!


Las sombras que haya que calcularse de forma instantánea se dejan para la consola, pero todas las demás (que no son pocas) para la nube.

Las físicas justamente es una de las cosas qe mejor funcionan en la nube, y has de tener un lag muy muy alto para que no funcione bien.

Si viste la demo de Microsoft sobre las físicas en la nube, que está confirmado que no es una demo creada para tal efecto sino tecnología de un juego en desarrollo, habrás comprobado lo bien que funciona para físicas. Donde se calculaba hasta las físicas de los trozos que saltaban, su interacción entre ellos y con su entorno, hasta su propia rotación y velocidad.

En tu ejemplo, no hay diferencias en tema de lag entre lanzar una piedra a alguien o dispararle con un M16 en el COD de turno, ambos son dos proyectiles. Salvando las distancias de que la bala llega antes que la piedra.
jose juan escribió:
laleshe escribió:No creo q sea sospechoso de antixboxero xd, pero estoy totalmente de acuerdo con zokormazo. Siempre he creido en el tema de la nube, pero va siendo hora q lo empiecen a mostrar de manera practica. Los drivatares y autotitanes no son para nada revolucionarios, quiero mas, mucho mas. A ver si muestran algo en este e3.

Las cosas se empiezan por el suelo no por el tejado,creo que se entiende


Yo quiero saber cuándo se va a llegar al tejado, o al menos a la primera planta. Creo que también se entiende.
@Zokormazo creo que tienes una idea equivocada de nube. Una nube no es más que una infraestructura de servidores, no le busques más significados. Y su uso puede ser cualquiera. Así que los juegos online efectivamente usan nube, cuando usas Office online usas nube, etc.etc. Lo que "vende" M$ es que tiene una nube de gran capacidad que puede usarse para multitud de cosas, y la pone disponible para una plataforma de juegos como Xbox, cosa antes nunca hecha. Imagina tener esa capacidad del WoW, por la cual pagas una cuota de 14€/mes me parece, disponible en TODOS los juegos, tan solo se necesita la intención del desarrollador de usarla, y todo integrado en la pequeña cuota del Live Gold.
Ya hay juegos que lo usan, como Forza o Titanfall, de no usarse en las partidas multijugador de Titanfall por ejemplo aquellos que no fueran el "host de las IA" jugarían con desventaja porque recibirían los datos de IA con retardo respecto al propio host. Es decir tú puedes montar la partida en el servidor pero delegar el cálculo de IA a un host, que te retorne los datos, y enviárselos a los demás jugadores, quedando éstos en desventaja como digo.

Por otra parte insisto en que la nube se usará para procesamiento que beneficie a múltiples usuarios con un mismo cálculo, esto es datos de partidas multijugador. Pero no espero para nada por no ser realista (no factible) que se ponga a calcular sombras ni cosas de esas para cada jugador conectado al Live jugando.
Por lo tanto, las funciones principales en juegos de la nube serán:
- Almacenamiento: gran BD de aprendizaje, con lo que se crean los jugadores sombra, ej. Forza.
- IA: para partidas multijugador que todos reciban los datos al mismo tiempo, acelera el juego online.
- Entorno: lo que hacen los MMORPG, se calcula el entorno común para todos los jugadores.
- Contenidos en tiempo real: actualización de los contenidos leyéndose de la nube, ej. Sunset Overdrive.
darksch escribió:@Zokormazo creo que tienes una idea equivocada de nube. Una nube no es más que una infraestructura de servidores, no le busques más significados. Y su uso puede ser cualquiera. Así que los juegos online efectivamente usan nube, cuando usas Office online usas nube, etc.etc. Lo que "vende" M$ es que tiene una nube de gran capacidad que puede usarse para multitud de cosas, y la pone disponible para una plataforma de juegos como Xbox, cosa antes nunca hecha. Imagina tener esa capacidad del WoW, por la cual pagas una cuota de 14€/mes me parece, disponible en TODOS los juegos, tan solo se necesita la intención del desarrollador de usarla, y todo integrado en la pequeña cuota del Live Gold.
Ya hay juegos que lo usan, como Forza o Titanfall, de no usarse en las partidas multijugador de Titanfall por ejemplo aquellos que no fueran el "host de las IA" jugarían con desventaja porque recibirían los datos de IA con retardo respecto al propio host. Es decir tú puedes montar la partida en el servidor pero delegar el cálculo de IA a un host, que te retorne los datos, y enviárselos a los demás jugadores, quedando éstos en desventaja como digo.

Por otra parte insisto en que la nube se usará para procesamiento que beneficie a múltiples usuarios con un mismo cálculo, esto es datos de partidas multijugador. Pero no espero para nada por no ser realista (no factible) que se ponga a calcular sombras ni cosas de esas para cada jugador conectado al Live jugando.
Por lo tanto, las funciones principales en juegos de la nube serán:
- Almacenamiento: gran BD de aprendizaje, con lo que se crean los jugadores sombra, ej. Forza.
- IA: para partidas multijugador que todos reciban los datos al mismo tiempo, acelera el juego online.
- Entorno: lo que hacen los MMORPG, se calcula el entorno común para todos los jugadores.
- Contenidos en tiempo real: actualización de los contenidos leyéndose de la nube, ej. Sunset Overdrive.


Se perfectamente lo que son servidores, la nube etc.

Pero microsoft, ademas del uso de servidores dedicados, dejarselos a los thirds etc, anuncio otra feature mas. De hecho, la feature novedosa importante y la que tanta controversia e incredulidad a creado en parte de la comunidad. En esa feature nueva, a la que microsoft bautizo como el poder de la nube, el cloud computing para xbox, las consolas envian parte de sus computos propios de renderizado, fisicas, IAs client-side a azure y este le devolvia los calculos ya hechos.

Es esta feature la que supuestamente va a suponer un boost importante a la potencia de xbox one, y lo que no ha llegado aun.

El resto, si, muy bonito util y ya era hora de que llegara algo asi por parte de los first, porque era una verguenza que pagando una cuota para las funciones online no hubiera ni unos tristes servidores dedicados. Pero no es lo novedoso, no es ese "poder de la nube" del que hablaba microsoft, no es ninguna revolucion, ni supone un boost a la capacidad tecnica de calculo de la xbox one.
Tienes razon. Por eso estamos todos pendientes del E3
Zokormazo escribió:
darksch escribió:@Zokormazo creo que tienes una idea equivocada de nube. Una nube no es más que una infraestructura de servidores, no le busques más significados. Y su uso puede ser cualquiera. Así que los juegos online efectivamente usan nube, cuando usas Office online usas nube, etc.etc. Lo que "vende" M$ es que tiene una nube de gran capacidad que puede usarse para multitud de cosas, y la pone disponible para una plataforma de juegos como Xbox, cosa antes nunca hecha. Imagina tener esa capacidad del WoW, por la cual pagas una cuota de 14€/mes me parece, disponible en TODOS los juegos, tan solo se necesita la intención del desarrollador de usarla, y todo integrado en la pequeña cuota del Live Gold.
Ya hay juegos que lo usan, como Forza o Titanfall, de no usarse en las partidas multijugador de Titanfall por ejemplo aquellos que no fueran el "host de las IA" jugarían con desventaja porque recibirían los datos de IA con retardo respecto al propio host. Es decir tú puedes montar la partida en el servidor pero delegar el cálculo de IA a un host, que te retorne los datos, y enviárselos a los demás jugadores, quedando éstos en desventaja como digo.

Por otra parte insisto en que la nube se usará para procesamiento que beneficie a múltiples usuarios con un mismo cálculo, esto es datos de partidas multijugador. Pero no espero para nada por no ser realista (no factible) que se ponga a calcular sombras ni cosas de esas para cada jugador conectado al Live jugando.
Por lo tanto, las funciones principales en juegos de la nube serán:
- Almacenamiento: gran BD de aprendizaje, con lo que se crean los jugadores sombra, ej. Forza.
- IA: para partidas multijugador que todos reciban los datos al mismo tiempo, acelera el juego online.
- Entorno: lo que hacen los MMORPG, se calcula el entorno común para todos los jugadores.
- Contenidos en tiempo real: actualización de los contenidos leyéndose de la nube, ej. Sunset Overdrive.


Se perfectamente lo que son servidores, la nube etc.

Pero microsoft, ademas del uso de servidores dedicados, dejarselos a los thirds etc, anuncio otra feature mas. De hecho, la feature novedosa importante y la que tanta controversia e incredulidad a creado en parte de la comunidad. En esa feature nueva, a la que microsoft bautizo como el poder de la nube, el cloud computing para xbox, las consolas envian parte de sus computos propios de renderizado, fisicas, IAs client-side a azure y este le devolvia los calculos ya hechos.

Es esta feature la que supuestamente va a suponer un boost importante a la potencia de xbox one, y lo que no ha llegado aun.

El resto, si, muy bonito util y ya era hora de que llegara algo asi por parte de los first, porque era una verguenza que pagando una cuota para las funciones online no hubiera ni unos tristes servidores dedicados. Pero no es lo novedoso, no es ese "poder de la nube" del que hablaba microsoft, no es ninguna revolucion, ni supone un boost a la capacidad tecnica de calculo de la xbox one.



Microsoft nunca ha dicho q vaya a renderizar en la nube. Han hablado de físicas, IA y q estaban probando con raytracing. (Además d otras funciones menos mediaticas)
raytracing es parte del proceso de renderizado. Las fisicas son un preproceso para el renderizado, las IAs, pueden ser un proceso client-side aun sin ser del renderizado. Aunque no haya hablado directamente microsoft, sus partners han hablado de iluminacion, de sistemas de particulas etc en esa nube.

Asi que microsoft y sus partners si han hablado de procesar partes del renderizado no criticos en latencia y de otras computaciones clasicamente client-side en la nube.
Creo q estas confundiendo renderizado con computación, pero t entiendo lo q quieres decir. Solo queda esperar y ver si mienten o no.
Bah que va, eso de renderizar en la nube para mí que se le escapó a uno que estaba muy flipado y le echó algo raro al ColaCao. Creo que OFICIALMENTE (en mayúsculas) M$ no ha dicho abiertamente que se usaría para eso.

Aún así si acelera el juego sin necesidad de computar render, porque gran parte de la lentitud/tirones en juegos online es por los datos (IAs, personajes, etc.), y si eso lo computas en un servidor y no en un host, y ese servidor tiene una buena potencia, pues quieras o no el juego te irá más fluido sin necesidad de ultra-potenciar la consola. Vamos que es tangible sin necesidad de poner los equipos de la NASA al servicio de Xbox Live. Para esto se requiere escalabilidad (para asegurarse que un juego nunca se queda corto de servidores según van entrando jugadores) y conexión, y creo que Azure tiene ambas.
Y una plataforma, un codigo, y llevarlo a la pratica. Y esto ultimo no lo han hecho. De poco o nada nos sirven los 300k de servidores y toda la escalabilidad de azure si no llevan a la practica xD
Yo no tengo ni idea de todos esos tecnicismos, pero por lo que decis algunos, lo del siguiente video es imposible:

https://www.youtube.com/watch?v=QxHdUDhOMyw

Entonces me gustaría informarme sobre que esta sucediendo o que "trampas" estan haciendo.
Nuhar escribió:Yo no tengo ni idea de todos esos tecnicismos, pero por lo que decis algunos, lo del siguiente video es imposible:

https://www.youtube.com/watch?v=QxHdUDhOMyw

Entonces me gustaría informarme sobre que esta sucediendo o que "trampas" estan haciendo.


Yo al menos no digo que no sea posible.

Digo que esta por ver eso llevado a la practica, con casos practicos, con un millon de xbox one pidiendo solicitudes sin parar, con los servidores en quintalapoya de la frontera y funcionando sobre las chustalineas que tenemos.

Lo del laboratorio esta bien y es muy bonito, pero lo que hay que ver es que cojones de todo eso sera lo que llegue y como y en que condiciones al usuario final en forma de juegos.
La consola lleva 5 meses y ya queréis juegos adelantados a su época. Parece que nadie recuerda que un triple A puede tardar entre 2 y 5 años en salir y para que utilice todo lo que queremos debe hacerlo con las herramientas adecuadas. Lo he dicho en otro foro y lo vuelvo a repetir: todos queremos lo más mejor del mundo mundial, pero eso no ocurre en unos días.
Llevamos 5 meses en esta generación. Paciencia amijos, paciencia.
En cualquier caso, es más que dudoso que las third-parties hagan uso de ese "poder de la nube" del que habláis. Nos conformaremos con los exclusivos, que no es poco.
Pero todo a su tiempo, que en esta industria intervienen muchos actores y los plazos son muy largos, mucho más largos que en la producción de una película por ejemplo.
Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

El caso es que estais o estabais diciendo que hay cosas que son imposibles que darían lag y bla bla bla, y en ese video yo al menos no lo noto, y lo poco que se de animacion del poco tiempo que llevo estudiando 3D, yo diría que si que esta ayudando a calculo de físicas y a renderizar. Entonces, ¿estais equivocados (hablo en general) o en este video hay trampa?

Simplemente quiero saber como se explica lo del video.
Zokormazo escribió:Digo que esta por ver eso llevado a la practica, con casos practicos, con un millon de xbox one pidiendo solicitudes sin parar, con los servidores en quintalapoya de la frontera y funcionando sobre las chustalineas que tenemos.


De ahí sólo veo problemático lo de las chustalineas. Muchos no tendrán acceso al futuro modelo de cloud computing que Microsoft propone para la One. Muchos otros sí.
Lo de cientos de miles (millones venga, pero no suele ser el caso) de peticiones concurrentes no es problemático en un sistema distribuido, abierto, escalable, transparente y tolerantes a fallos (Azure + Orleans framework).
Y un servidor en Amsterdam está lejos sí, pero tampoco es terrible. Hay posibilidades, pero está claro que no es algo que vaya a suceder este año o el que viene.
En serio, pensar que Xbox One no va a utilizar el cloud computing para todo lo que pueda, incluído render en diferido de algunas cosas, es ridículo. Tienen una infraestructura completa muy potente para ello: Azure, tienen los mejores ingenieros de software y programadores en sus plantillas, Xbox One está diseñada para procesar de forma especialmente rápida los datos obtenidos por Ethernet (por eso va directo al SoC y no al northbridge)

En los 5 meses que llevamos hemos visto: offload de IA en la nube y servidores dedicados para multiplayers. Por otro lado nos han enseñado demos técnicas de iluminación y físicas en diferido.

No veo yo a nadie cuestionar el Playstation Now que sólo hace streamings de juegos como onLive, sin embargo a eso se le da credibilidad absoluta y nadie cuestiona que eso vaya a ser jugable a pesar del posible lag.

Creo que la comunidad tiende a poner en juicio todo lo que dice y hace Microsoft, cuando hasta ahora, cada cosa que ha hecho o planteado ha sido honesta (acertado y desacertado). Incluso para las decisiones malas han dado marcha atrás antes de implantarlas porque nos las han contado tal cual, sin trampa y sin ocultar nada (mal contado, mal expresado y mil cosas más)



Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

El caso es que estais o estabais diciendo que hay cosas que son imposibles que darían lag y bla bla bla, y en ese video yo al menos no lo noto, y lo poco que se de animacion del poco tiempo que llevo estudiando 3D, yo diría que si que esta ayudando a calculo de físicas y a renderizar. Entonces, ¿estais equivocados (hablo en general) o en este video hay trampa?

Simplemente quiero saber como se explica lo del video.


Yo espero una aplicación de cloud computing potente para Quantum Break. De hecho pienso que las escenas que nos han enseñado en la que estalla una bomba y saltan miles de cristales, o la escena de destrucción del puente, son in-game con offload de físicas en la nube (y de ahí la reciente demo que ha enseñado MS sobre físicas en la nube)
hsaoud escribió:En serio, pensar que Xbox One no va a utilizar el cloud computing para todo lo que pueda, incluído render en diferido de algunas cosas, es ridículo. Tienen una infraestructura completa muy potente para ello: Azure, tienen los mejores ingenieros de software y programadores en sus plantillas, Xbox One está diseñada para procesar de forma especialmente rápida los datos obtenidos por Ethernet (por eso va directo al SoC y no al northbridge)

En los 5 meses que llevamos hemos visto: offload de IA en la nube y servidores dedicados para multiplayers. Por otro lado nos han enseñado demos técnicas de iluminación y físicas en diferido.

No veo yo a nadie cuestionar el Playstation Now que sólo hace streamings de juegos como onLive, sin embargo a eso se le da credibilidad absoluta y nadie cuestiona que eso vaya a ser jugable a pesar del posible lag.

Creo que la comunidad tiende a poner en juicio todo lo que dice y hace Microsoft, cuando hasta ahora, cada cosa que ha hecho o planteado ha sido honesta (acertado y desacertado). Incluso para las decisiones malas han dado marcha atrás antes de implantarlas porque nos las han contado tal cual, sin trampa y sin ocultar nada (mal contado, mal expresado y mil cosas más)



Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

El caso es que estais o estabais diciendo que hay cosas que son imposibles que darían lag y bla bla bla, y en ese video yo al menos no lo noto, y lo poco que se de animacion del poco tiempo que llevo estudiando 3D, yo diría que si que esta ayudando a calculo de físicas y a renderizar. Entonces, ¿estais equivocados (hablo en general) o en este video hay trampa?

Simplemente quiero saber como se explica lo del video.


Yo espero una aplicación de cloud computing potente para Quantum Break. De hecho pienso que las escenas que nos han enseñado en la que estalla una bomba y saltan miles de cristales, o la escena de destrucción del puente, son in-game con offload de físicas en la nube (y de ahí la reciente demo que ha enseñado MS sobre físicas en la nube)


Al parecer es 100% con el motor del juego en un devkit. No dicen nada de ayudado por ningun medio. Ya sea cloud computing o majia :P
http://community.remedygames.com/showpost.php?p=162656&postcount=7

he E3 trailer is running on a devkit powered by our brand new game engine Northlight. You can even see a glimpse of the engine logo at the beginning of Sam's and Ozz's TwitchTV segment (starts at 31 min).

I'm not an expert, but I'd guess that a devkit more powerful than the actual console would be kinda silly.

http://www.twitch.tv/twitch/b/416120041
y no olvidemos que en dos años por la simple y llana evolución a nivel hardware la capacidad de cálculo de cualquier plataforma cloud (me da igual si hablamos de MS, Amazone, google, etc) se multiplicará por muchos enteros. (todavía recuerdo cuando el almacenamiento era algo caro... y en proyectos IT era un auténtico quebradero de cabeza... ahora me dicen "necesitaremos 1 TB de almacenamiento para entornos virtualizados" y tan tranquilo)

El talón de aquiles del cloud "lo que sea" (gaming, computing,...) es la conexión, no la capacidad de procesamiento. Desde ese pto de vista (procesamiento) dará igual si a nivel mundial hay 5 - 10 - 20 millones de jugadores haciendo peticiones. Habrá que buscar la mejor forma de solventar las problemáticas que se planteen, pero ese no va a ser EL PROBLEMA.

Veremos cosas calcualdas en lado servidor en función de la tolerancia a la latencia que admitan, y de las soluciones que se implementen, pero el volumen en sí de procesamiento remoto no será el limitante.

Por tanto, yo pienso que simplemente hay que dar tiempo a superar barreras...
Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

Es que es por ESO justamente por lo que digo que la computación individual no es factible. La relación consolas/servidores es tan apabullante que no es viable.

Yo sabiendo que lo que habrá es lo que se que habrá (redundante) está perfecto. Que son servidores dedicados en cada juego, las ventajas de servidores como en juegos por los que pagas para cada uno una cuota (MMORPG) disponible para cada juego con una única y pequeña cuota. A eso añade almacenamiento (que ya lo estamos usando), y me parece un servicio excelente.
Hay que tener claro que no todo el mundo va a tener acceso al cloud computing. Ese es el gran factor limitante. La cancelación del lanzamiento de Titanfall en Sudáfrica es un primer ejemplo de esto. No hay datacenters de Azure en África. Pueden implementarse otras soluciones, llegar a a acuerdos con los proveedores ISP locales para usar servidores desplegados por ellos e integrarlos en Xbox Live Compute. En Australia se ha hecho por ejemplo.
Y algunos hablais de azure como si microsoft fuera a dedicar todo azure a xbox one... JA!

Azure tiene infinidad de clientes, con infinidad de distintas computaciones. Clientes que pagan cientos y miles de $ al mes por ese servicio. Dudo mucho que microsoft los deje en un segundo plano por clientes que pagan siendo generosos 20$ al mes.

Habra una parte de la capacidad de computacion de azure dedicada a xbox one, pero ni jarto de vino sera todo Azure.

EDIT:

Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

El caso es que estais o estabais diciendo que hay cosas que son imposibles que darían lag y bla bla bla, y en ese video yo al menos no lo noto, y lo poco que se de animacion del poco tiempo que llevo estudiando 3D, yo diría que si que esta ayudando a calculo de físicas y a renderizar. Entonces, ¿estais equivocados (hablo en general) o en este video hay trampa?

Simplemente quiero saber como se explica lo del video.


Mas que trampa en ese video, ese video probablemente estara hecho con el cliente a una latencia minima hacia los servidores y con unos servidores con poca carga. Por eso decia que lo del laboratorio es muy bonito, pero que luego hay que verlo en la vida real.
darksch escribió:
Nuhar escribió:Pero vamos a ver, lo que llegue a cada consola dios dirá, eso dependerá de cuanto dinero se gaste microsoft en servidores y potencia de calculo, si ahora hay 5 millones de consolas y 300.000 servidores igual puede hacer maravillas, si hay 50 millones de consolas igual no mueve una mosca, pero no sabemos si también elevarían el número de servidores de acorde a los sistemas conectados.

Es que es por ESO justamente por lo que digo que la computación individual no es factible. La relación consolas/servidores es tan apabullante que no es viable.

Yo sabiendo que lo que habrá es lo que se que habrá (redundante) está perfecto. Que son servidores dedicados en cada juego, las ventajas de servidores como en juegos por los que pagas para cada uno una cuota (MMORPG) disponible para cada juego con una única y pequeña cuota. A eso añade almacenamiento (que ya lo estamos usando), y me parece un servicio excelente.


Lo que dices es ante todo lógico, pero Azure es un sistema escalable, habrá que esperar para apostar.

De todos modos, 300.000 servidores son muuuuuuuchos servidores y todas las consolas no estan conectadas a la vez. Aparte, como dices, si es un juego online o mundo abierto online, los mismos servidores están dando cobertura a muchas consolas a la vez por lo que la relación servidor/número de usuarios descendería.

No se, bastante tengo con descubrir el "timo del video" como para encima indagar sobre si la nube afectará individualmente o colectivamente jajaja.

Zokormazo escribió:Mas que trampa en ese video, ese video probablemente estara hecho con el cliente a una latencia minima hacia los servidores y con unos servidores con poca carga. Por eso decia que lo del laboratorio es muy bonito, pero que luego hay que verlo en la vida real.


Venga, le sumo los 100ms que tengo de ping (vodafone y sin fibra, casi nada) en el titanfall. Sigue sin haber lag. Asi que sigue siendo muy bonito y factible. Coincido en que quiero verlo en la "vida real" (juegos)
KinderRey escribió:Hay que tener claro que no todo el mundo va a tener acceso al cloud computing. Ese es el gran factor limitante. La cancelación del lanzamiento de Titanfall en Sudáfrica es un primer ejemplo de esto. No hay datacenters de Azure en África. Pueden implementarse otras soluciones, llegar a a acuerdos con los proveedores ISP locales para usar servidores desplegados por ellos e integrarlos en Xbox Live Compute. En Australia se ha hecho por ejemplo.


Esto me recuerda a la Dreamcast, con su tarjeta ethernet detrás para jugar online. El primer juego online en consola de la historia fue el Chu Chu Rocket de DC, y por aquél entonces mucha gente desconfiaba de la tecnología y su utilidad. Eso sí, yo me hinché a navegar por internet y a sacarle el partido que pude a esa tecnología. Mucha gente no podía usarlo porque no tenían internet pero al poco tiempo, Playstation 2 sacó un adaptador externo ethernet y empezó la fiesta, seguido de Xbox 1 con su Xbox Live, etc.

Esto es una evolución natural, que no todos podrán disfrutar, pero que dentro de 10 años se verá como lo más normal del mundo.

Edito: Recordar que en la época de la DC ya existía el juego online en PC, al igual que ahora existe el cloud computing en PC (para geoprocesos, por ejemplo). La clave, es que se ha dado el paso de llevarlo a las consolas, como SEGA hizo en su día con la DC.
17587 respuestas