Google explicará la semana que viene cómo actualizar el mando de Google Stadia para que se pueda utilizar con dispositivos móviles y ordenadores a través de Bluetooth y así evitar que quede inservible cuando el servicio de juego en la nube baje la persiana el próximo miércoles 18 de enero, según ha anunciado la compañía a través de un breve comunicado en Twitter. Además, ha publicado un nuevo juego que se puede probar gratis hasta la clausura de la plataforma.
Comentarios
Siendo Google sospecho que empezaron diseñando el mando para que fuera bluetooth y luego por cuestiones de latencia o similar acabaron ellos haciendo un protocolo incompatible con bluetooth pero manteniendo el hardware ya existente con la misma frecuencia y marco regulatorio.
Aunque Google puede ser malvada sospecho que en este caso no fue por maldad sino por requisitos del proyecto, que dado lo ambicioso que era había que rascar por todos lados.
#1 Habría que comparar con productos similares... ¿necesita la plataforma de nvidia mandos "especiales"? ¿xbox cloud o como se llame? ¿no tenía o tuvo sony algún servicio similar? ¿cómo va cada alternativa comparada con el producto de google? ¿en serio la latencia de un mando es el cuello de botella, siendo el mayor problema de toda la vida la latencia, constancia y velocidad de la red?
#5 ¿en serio la latencia de un mando es el cuello de botella?
Las latencias se suman. Si la latencia es el cuello de botella hay que abordarla por todos los frentes, lo que quites de un sitio no se sumará al resto.
#6 No señor, las latencias no se suman.
Si el mando tiene una latencia de 2ms y la red fluctúa entre 3 y 5 ms, puede que se pierda por el camino una o dos actualizaciones del mando, pero por efecto de la red, no del mando. Lo pongo más gráficamente: las rayas horizontales es el tiempo que tarda en actualizarse la información de la red en el primer caso y del mando en el segundo caso. Teniendo en cuenta que los datos que realmente computan son los que atraviesan la red...
_________________|
--|--|--|--|--|--|--|--|
El mando tarda lo mismo en mandar su información actualizada, pero puede que por lo que tarda la red en hacerlo, se pierda una o dos actualizaciones de la info del mando por el camino. ¿Es problema del mando que el juego no te responda cuando moviste el mando sino 2 ó 4ms más tarde?. Reduzcamos la latencia del mando:
_________________|
||-|-|-|-|-|-|-|-|-|Ahora la latencia del mando es 1ms, pero sigue respondiendo igual de mal; la latencia en las actualizaciones de la red hacen que se pierda más información de movimiento del mando, el juego te va a responder 3 ó 4ms más tarde igualmente...
Piensas que las latencias ocurren una detrás de otra, pero las latencias en muchos casos van en paralelo.
#7 No entiendo por qué hablas de pérdida de información cuando hablamos de latencia.
Si el usuario pulsa el botón y se tarda 2 ms a que bluetooth entregue ese dato al ordenador y luego éste tarda x ms a enviarlo a servidores y recibir respuesta tienes una latencia de x+2. Si reduces la latencia del mando a 1 ms hay una latencia de x+1.
#10 Por supuesto que hay pérdida de información, otra cosa es que esa pérdida sea relevante. Si hay un cambio de estado en el mando y su latencia es x segundos mayor que lo que tarda la consola en generar un frame, llega x segundos tarde al frame de imagen final. Hasta ahí de acuerdo ¿no?. Si la información tiene que ir a un elemento que está en la nube y volver, todo lo que hagas con el mando mientras, es información perdida, no se va a reflejar en ningún frame de video; mientras la latencia del mando sea menor que la de la red (mejor aún, la mitad que la red para ser más precisos), no se notará para nada en el resultado final porque tampoco iba a ser procesado ni ibas a ver ningún cambio en un frame de la pantalla. Igualmente, el cálculo de acciones y el frame de la pantalla pueden estar desacoplados y no afectar la latencia de entrada a los frames dibujados, pero incluso sin tener en cuenta el tiempo de renderizado, lo que tarda en ir y volver la información del mando por la red es muy muy probable que sea mucho mayor que la latencia del mando.
Supones que el ordenador está esperando todo el rato y hace las cosas secuencialmente y no es así. Puede estar enviando datos mientras procesa frames y recibiendo información de dispositivos de entrada mientras espera por la red. Una vez más, las cosas no son tan secuenciales, si un ordenador tuviera que esperar por una transferencia, estaría la mitad del tiempo bloqueado... ¿recuerdas cuando movías datos por usb y windows se quedaba "parado"? ¿a que ahora ya no lo hace?
#11 Que decidas ignorar lo que ocurra en el mando después de que hayas enviado una instrucción y hasta que tengas el frame consecuencia de esa instrucción no cambia que esa primera instrucción tiene que hacer todo el recorrido para que se produzca ese frame.
Y el tiempo que tarda el mando a darle al ordenador la información de la primera pulsación siempre se suma a la latencia total final. Siempre es latencia del mando en la primera pulsación+x
Si reduces la latencia de la primera pulsación a la mitad reduces a la mitad lo que le sumas a la x. Es siempre una ganancia neta.
#12 Pero a ver, el mando va a mandar información cada x tiempo, independientemente de qué esté haciendo el dispositivo al que esté conectado, y éste no va a esperar a que el mando le responda para enviar información por la red. Se envía la última actualización disponible del mando, haya ocurrido ya, hace 10ms o hace 150. Luego esa información va por la red y tarda X, en lo que va por la red, el mando puede haber actualizado 0, 1, 2 o mil veces, el dispositivo al que esté conectado puede haberla capturado 0, 1, 2 o mil veces. No se acumula el tiempo como tú dices. La ganancia neta que pueda haber es despreciable porque se diluye con el costo de la información viajando por la red. Son cosas que suceden en paralelo, no se suman absolutamente, si acaso pequeñas diferencias entre los tiempos de ambas cosas.
Una vez los datos llegan por la red, se procesarán y se incorporarán al frame que se esté construyendo o al siguiente, es posible que incluso se renderice más de un frame mientras (si el sistema es eficiente, lo que se manda de vuelta casi nunca es un frame completo, son las diferencias entre frames consecutivos). A menudo la latencia es mayor que la capacidad de generar frames, así que se juega con eso a la hora de qué datos visuales se envían por la red de vuelta.
Lo que se denomina latencia en cosas como stadia no es tanto lo que tarda en enviarse la información del mando sino en integrarla en los frames que genera de vuelta de forma que cuando te los devuelve no haya un desfase evidente (que lo hay). Viene a ser algo similar a cómo los videojuegos online masivos procesan la información de manera predictiva y así generan las posiciones y acciones de tantos jugadores simultáneos de manera coherente con tanta variación de latencias distintas.
En una consola u ordenador normal si influye más porque toda la latencia de la red desaparece, así que es más que probable que tarde menos en renderizar frames que lo que tarda el mando en enviar sus datos (60fps son algo más de 16ms, dudo que el blutooth tenga latencias tan bajas).
#13 Se envía la última actualización disponible del mando, haya ocurrido ya, hace 10ms o hace 150.
Si el protocolo bluetooth añade 2ms de latencia esa se suma en el sentido que quizá llegue en la actualización 321 en vez de en la actualización 320. Cualquier latencia que introduzca el protocolo inevitablemente se suma, quizá en algunos casos concretos pueda no importar que se sume pero en otros sí importará.
En una consola u ordenador normal si influye más porque
Nadie discute que influya más en unos casos u otros, lo que es falso es que haya casos en los que no tenga influencia la latencia entre que el usuario pulsa un botón, pasa por el protocolo bluetooth, y llega al equipo que luego hará con esa información lo que considere oportuno. Si ralentizas la comunicación entre mando y ordenador eso es latencia que se suma al conjunto, que luego en algunos casos sea irrelevante que se haya sumado porque igualmente iba en un grupo que se estaba esperando igualmente vale pero en otros casos sí influirá negativamente.
Y por lo tanto reducir la latencia cambiando el protocolo tiene todo el sentido del mundo cuando la latencia es tu problema principal.
#14 Si lo que digo es que si las actualizaciones suceden en paralelo a los envíos por la red, muy mala tendría que ser la latencia del blutooth para notarse. Pero lo que no suma es de manera lineal porque no son procesos que sucedan en serie, y desde luego, la principal componente en la latencia será el elemento que más tarda y no el que menos. Y desde luego, un elemento con latencia constante afectará menos que uno con latencia variable.
Volvamos al comienzo: lo que más influye en cómo se percibe de suave un servicio web siempre será la latencia de la red, el resto de latencias se mezclan y se pierden por enmedio (lo que tarda en enviar entradas desde un mando y en generar frames en el otro extremo, se lo pasa la información viajando por la red, no ralentizas prácticamente nada a lo que ya es lento). De nada te sirve tener un dispositivo de entrada de latencia 0 o un servidor que te genere 240fps si la información luego te tarda 100ms en ir y otros 100 en volver. Y una quinta parte de segundo ya es un retardo que se nota muchísimo. Y si varía y a veces llega antes y otras veces después, produciéndose tirones, más todavía. De lo que se trata es de homogeneizar la respuesta al cliente, de que le parezca que le responde a tiempo y vea un movimiento fluído y constante.
Y me parece perfecto que quieran optimizar todo lo posible y disminuír lo máximo posible la latencia en todos lados, pero al final el problema de stadia nunca fue la latencia del mando, sino de la red:
https://www.reddit.com/r/Stadia/comments/dgnhaj/how_negative_latency_might_actually_work/
"Essentially, the computer (in this case, Google's Stadia server) will calculate multiple extra frames during each frame and serve the latest frame to you. Upon receiving input, it will apply the input to the earliest available frame and calculate the next few frames as if that input is held (still all within 1 normal frame duration), serving the latest one to you as if you've held that input for that many frames already."
El problema de "añadir frames porque si" es que añades latencia. Se ve muy fluído, pero la respuesta a los mandos resulta torpona, lo que has movido no se refleja en lo que hay en pantalla. Pasa con el triple buffering, generas más frames, pero sólo uno refleja el último movimiento del usuario). Algo similar pasa cuando generas menos frames (como cuando usas bajas frecuentas de refresco y fuerzas el vsync), el movimiento del usuario ya no es el que el frame que se muestra en la pantalla está mostrando (y no porque el mando tenga lag, sino por los tiempos de renderizado ahora son mucho mayores que los tiempos de refresco del mando).
#1 el mando se conecta por wifi a los servidores. De esa forma la latencia de lo que ves y la latencia de lo que haces es mínima
Un poco exagerado el "salvará", el mando también se puede conectar por USB, no es que se quede como un pisapapeles si no hay soporte bluetooth.
#19 We will be offering refunds for all Stadia hardware purchases (Stadia Controller, Founder's Edition, Premiere Edition, and Play and Watch with Google TV packages) made through the Google Store and software transactions (games and add-on purchases) through the Stadia store. Stadia Pro subscriptions are not eligible for refund, however you will be able to continue playing your games in Pro without further charges until the final wind down date.
Hasta el 18 de enero pueden tardar, pero a todo el mundo que conozco ya le han devuelto todo. Si la semana que viene no has recibido ningún mail ni el reembolso, yo me pondría en contacto con ellos.
#20 Gracias!
#17 Había ciertas compras que no iban a devolver, comprueba que las que te falten no sean de ese subgrupo. A mi me han devuelto hasta el dinero del mando ya.
#18 "Había ciertas compras que no iban a devolver"
Donde puedo encontrar mas detalles sobre esto que afirmas?
Hablo de compras de jeugos
"Google ha devuelto a los usuarios de Stadia todo el dinero de las compras realizadas relacionadas con el servicio."
Esto es falso. Ha habido reembolsos parciales, pero no han devuelto todo, todavia.
Esperemos no tener que contactar con soporte
#2 ¿parciales? No sé si tiene que ver con impuestos o costes de reembolso
#2 a mi me han devuelto todo.
#2 A mi también me han devuelto todo, de que hablas?
#16 De 5 compras, solo me han devuelto 2.
De eso hablo