Construyendo NX Portátil (I): Pantalla.

Esto es una continuación de la entrada anterior, por lo que voy a utilizar como referencia la patente de la entrada anterior. He decidido desglosarla porque tuve una petición de hacer una serie de como podría ser la NX portátil.

TweetNXHH

En fin, al grano, en una de las partes de la patente podemos leer:

Una sección de procesamiento (14a, 18a) para la ejecución de un proceso determinado, y una sección de ajusta (14a) para ajustar un tiempo en el cual la sección de procesamiento ejecute un proceso predeterminado basado en el valor del temporizador (124a) del modulo inalámbrico del aparato de juego.

La sección de procesamiento puede ejecutar un proceso de generar los datos de imagen y almacenar los datos de imagen en un búfer de pantalla.

En el Wii U Gamepad desde el momento en que lo que hace es recibir la señal y descodificarla todo su trabajo esta predeterminado, siendo la única parte no predeterminada el tiempo en que se genera la imagen que tendrá que ir sincronizado con el de la consola principal. En todo caso lo que llama la atención es el concepto que los dos dispositivos tipo Wii U Gamepad estén conectados y el hecho que diga que genera los datos de imagen ya que los datos de imagen son realizados cuando la consola hace el rendering de la escena.

La sección de procesamiento puede ejecutar un proceso de generar datos de imagen y almacenar los datos de imagen en al menos dos búfers de pantalla.

Lo cual significa viendo lo que hemos visto de patente hasta ahora que tenemos Consola A (Maestra) y Consola B (Cliente) y es A la que se encarga de crear los búfers de imagen tanto de A como B para almacenarlos en su memoria y lo más probable transmitir a B de forma inalámbrica. Tened en cuenta que el Wii U Gamepad estándar no renderiza el juego en ningún momento y mucho menos podemos comunicar dos Wii U Gamepad al mismo tiempo y aquí nos encontramos con la misma situación.

Continuemos pues:

La sección de procesamiento de juego 14a genera una imagen de juego reflejando el resultado del procesamiento de juego y escribe los datos de imagen en el búfer de imagen 26a. La imagen es actualizada en un ciclo de 16.7ms.

Llama la atención que la generación completa de la imagen sean unos 16.7ms, el motivo de ello es que lo que diferencia las consolas actuales de las antiguas es que en las actuales el tiempo de fotograma no es fijo sino que es variable.

Dado que ambos dispositivos utilizarían la misma resolución esto significa además que el tiempo de sincronización no tiene que ver con el tiempo en generar el fotograma completo sino con la sincronización vertical y estaríamos frente a un sistema que funcionaría como los de antaño (ver mi serie Gráficos en Consolas Antiguas) en los que la frecuencia es fija.Es decir, el búfer de imagen A y B es generado por el dispositivo A pero es enviado hacía la pantalla del dispositivo A y del dispositivo B linea por linea. El concepto detrás del formato H.264 es que cada paquete que se envia (un paquete es un bloque de nxn pixeles) es autocontenido. Es decir… ¿Verdad que en las consolas antiguas se enviaban los patrones/sprites en el búfer de linea para ser procesados y estos en realidad eran bloques de nxn? Pues aquí como podréis adivinar es el mismo proceso.

Los bloques en H.264 son de 16×16 pixeles por lo que la resolución horizontal como vertical tendrá que ser de un múltiple de 16, más adelante entraremos en eso. De momento quedaos con este dato ya que es importante.

Curiosamente todas las consolas portátiles de Nintendo funcionan con excepción de 3DS, por otro lado con Wii U Nintendo ya ha conseguido una sincronización completa a 16.7ms utilizando un solo Wii U Gamepad. Por lo que es posible que la resolución de pantalla total de la nueva portátil sea de 854×480 pixeles (unos 409.920 pixeles en total). Hay que tener en cuenta que la portátil actual de Nintendo que es 3DS tiene una resolución total de (400+400+320)x 240 pixeles (unos 268.800 pixeles) por lo que el sistema del que estamos hablando tendría una mayor densidad, eso si, completamente ridícula en comparación con los dispositivos de bolsillo de hoy en día.

En todo caso la resolución esta muy atada al timing y este con la capacidad de transferencia del estandar 802.11 utilizado para la transmisión. Wii U utiliza el 802.11n que tiene un nivel de transferencia de 600Mb/seg, en el caso del más nuevo AC la transferencia pasa a ser de 1200Mb/seg, es decir se duplica la información que se puede enviar y en el caso de que Nintendo utilizará el estandar 802.11ac para la transmisión de datos entonces si se utiliza una sola pantalla la resolución total pasaría a ser de 819.840 pixeles en total, aun poco en comparación con lo que hay en el mercado pero un salto sustancial desde los 268.800 pixeles en total que tiene la resolución de 3DS contando todas las pantallas que tiene.

Por otro lado.., ¿es posible que Nintendo llegue a utilizar el formato H.265/HEVC? Creo que no deberíamos descartarlo y tener en cuenta que:

Se reputa que HEVC tiene una relación de compresión de datos que duplica la de H.264/MPEG-4 AVC al mismo nivel de calidad de video.

Es decir, si Nintendo utiliza esta formato de video (cuyos bloques son también de 16×16 pixeles) en el caso que la conectividad sea 802.11n entonces las resoluciones serán las mismas que en 802.11ac y resolución de 819.840 pixeles. En el caso de la combinación HEVC+802.11ac la resolución debería poder duplicarse de nuevo a los 1.639.680.

Lo primero es saber que tenemos dos posibles factores forma

3DS-vs-Vita

Dado que lo más seguro es que la siguiente portátil sea compatible hacía atrás con 3DS esto significa que tendrá que guardar el mismo formato forma que 3DS, pero de decidido incluir también el formato PS Vita por si Nintendo descarta el formato 3DS y decide romper con la tradición.

En el formato de una sola pantalla la resolución la podemos saber por la siguiente formula:

16(n)*9(n)= Resolución total del sistema.

144(n^2)=Resolución total del sistema.

(n^2)=Resolución total del sistema/144

En cambio en el caso de un formato tipo 3DS la formula es.

[(5(m)*3(m))+(5(m)*3(m))+(4(m)*3(m))=Resolución total del sistema.

42(m^2)=Resolución total del sistema.

(m^2)=Resolución total del sistema/42.

Las proporciones son siempre las mismas y lo único que cambia es el valor de n y m que en cada resolución tanto en vertical como en horizontal es siempre el mismo, he puesto dos variables distintas porque el valor de n y m nunca es el mismo por la diferencia del formato de pantalla.

En 3DS el valor de m es 80, lo cual es un número múltiple de 16. Dado que el Streaming se hace en bloques de 16×16 pixeles entonces el resultado obtenido para m y n se ha de redondear a la baja hasta el valor más cercano multiple con 16.

¿que ocurre entonces si conservamos el formato de 3DS con las resoluciones de 409.920 pixeles y 819.840 pixeles respectivamente? En el primer caso m nos da unos 98.8, un número que precisamente no es múltiple de 16. Sí tiramos hacía abajo 96 es el número más cercano, si tiramos hacía arriba es 112, hay demasiada distancia de 98.8 a 112 Ppor lo que para hacerlo compatible con el streaming H.264 diremos que m es 96. Lo que nos da las siguientes resoluciones:

  • Pantalla 3D ojo izquierdo: 480*288 pixeles.
  • Pantalla 3D ojo derecho: 480*288 pixeles.
  • Pantalla inferior: 384*288 pixeles.

No es lo que digamos un aumento de resolución muy alto respecto a 3DS. Es más bien bajo, ahora veamos el segundo caso (802.11ac con H.264/802.11n con HEVC) que nos da un indice de 139.72 aproximadamente, de nuevo no tenemos un número múltiple de 16 siendo el más cercano tirando hacía abajo el 128 y tirando hacía arriba el 144. Dado que tiene que sobrar espacio para posibles eventualidades diremos que m=128 en este caso (si, se que soy bastante conservador en esto).

  • Pantalla 3D ojo izquierdo: 640*384 pixeles.
  • Pantalla 3D ojo derecho: 640*384 pixeles.
  • Pantalla inferior: 512*384 pixeles.

En el caso de utilizar el formato HEVC para la compresión y el 802.11ac para el envió. En formato 3DS la m seria de 197.58, la cifra  a la baja multiple de 16 más cercana es el 192, por lo que tomaremos como referencia m=192.

  • Pantalla 3D ojo izquierdo: 960*576 pixeles.
  • Pantalla 3D ojo derecho: 960*576 pixeles.
  • Pantalla inferior: 768*576 pixeles.

Lo cual supone un aumento de resolución enorme respecto a 3DS y coloca la calidad de imagen al nivel de Vita. Pero este sería el caso extremo y una posibilidad más.

El siguiente paso es la pantalla 16:9 con una resolución de 409.920, utilizando la resolución de 854×480 nos sale n=54 aproximadamente. Para seguir el mismo estándar que el resto diremos que n es múltiple de 16 y el más cercano es el 48. Teniendo en cuenta esto la resolución pasa a ser de 768×432 pixeles. En cuanto al mismo formato y el segundo caso (802.11ac con H.264/802.11n con HEVC) que permite la resolución de 819.840 pixeles calculando la n obtenemos 75.46 aproximadamente, de nuevo nos encontramos con un valor que no es múltiple de 16 por lo que en este caso tendremos que rebajar a n=64. Lo que nos da una resolución de 1024×576 pixeles.

En cuanto al uso del HEVC+H.265 en 16:9 y una sola pantalla nos encontramos que el valor de n pasa a ser de 106.708325198, una cifra a medio camino que nos obliga a bajar a la n=96, lo que da una resolución de 1536×864. Una resolución que esta por encima de la de Wii U cuyos juegos en su mayoría son de 1280×720 pixeles.

Por lo que existen múltiples posibilidades en cuanto a factor forma y resolución por el hecho de existir una serie de variables concretas que lo permiten. Ahora bien, como he dicho antes desconocemos por completo el formato forma de esta supuesta portátil por el momento por lo que tendremos que jugar con las diferentes resoluciones y los diferentes factores forma en las entrada siguientes.

El número de opciones posibles se reduce a la mitad si Nintendo escoge tanto el formato 3DS como el formato PS Vita para su siguiente consola. Como he dicho antes de momento voy a mantener los dos formatos forma en la especulación.

Anuncios