Buenos días compañeros de PS4foros.
Habida cuenta que me dedico al diseño e implementación de aplicaciones informáticas (aunque en un ámbito absolutamente opuesto al de los videojuegos), y que en el pasado he hecho mis (muy humildes) pinitos también en dispositivos móviles (apenas algunas aplicaciones y un par de prácticas en forma de juegos), voy a compartir con vosotros un par de conceptos interesantes en cuanto a la forma en que se gestionan los recursos de un juego desde el punto de vista de la máquina y el programador. Estoy seguro de que os interesará para comprender un poco de qué van esos tinglados de los frames por segundo, CPU, GPU y bloqueo del framerate, que tanto se mencionan últimamente cuando se habla de los “downgrades gráficos” de tal o cual juego debido a que una determinada consola no posee la suficiente potencia.
Comencemos pues.
Para poner gráficos en pantalla se utiliza tanto CPU (Unidad Central de Proceso) como GPU (Unidad de Proceso Gráfico), aunque lógicamente la mayor parte de la carga procesal la sufre la GPU que hace el trabajo duro (renderizar los gráficos poligonales con todos los efectos especiales que hoy en día se aplican en los juegos).
Aunque la CPU puede ser utilizada para parte de los cálculos gráficos (los menos), por plasmar el caso ideal (con el que todo se entenderá mejor) pongamos que es la GPU la que se encarga del 100% del proceso gráfico, siendo la CPU la que se encarga de realizar el resto de procesos del juego: cálculo de posiciones de los objetos (ojo, no cálculos poligonales que los hace la GPU, sólo coordenadas), cálculo de variables como la energía que nos restan los impactos enemigos, los puntos que vamos acumulando, el prestigio ganado en base a nuestros hackeos… (maldito “Watch Dogs”, sal de mi cabeza
).Que un juego corra a 60 fps en lugar de a 30 conlleva que hay que poner el doble de frames en pantalla por cada segundo que transcurre; esto acarrea lógicamente que la suavidad del movimiento es mayor (sobre la capacidad del ojo humano para percibir esta mejora corren ríos de tinta). Supongo que sabéis que un “frame” es una imagen estática, un fotograma.
Pero poner el doble de frames en pantalla por cada segundo transcurrido no es gratis. Tanto CPU como GPU deben aumentar significativamente su carga de trabajo.
Algunos cálculos de la CPU (como todo lo relativo a las posiciones de personajes, enemigos, proyectiles, etc) son necesarios para dibujar cada frame, es decir deben funcionar de manera casi solidaria con los realizados por la GPU; pero otros muchos procesos de la CPU son de datos que no influyen en lo que se va a ver en pantalla.
Por lo tanto es la GPU la que más se acerca a duplicar su trabajo cada vez que se duplican los FPS, ya que para mostrar cada frame, que en un juego poligonal suele ser totalmente distinto al anterior, debe renderizar la imagen (plasmar en un dibujo/fotograma de 2 dimensiones lo que poligonalmente tiene calculado en memoria) con texturas, efectos y demás.
El procedimiento, simplificado tanto para que lo entendáis como debido a mi propia limitación de conocimientos al respecto, es el siguiente:
- La GPU realiza todos los procesos gráficos necesarios para el siguiente frame a plasmar en pantalla (aplicar texturas a la imagen poligonal, aplicar iluminación, efectos etc). Esto le lleva un tiempo determinado (llamémosle tiempo-T). A mayor tiempo-T, menor nº de frames se plasmarán en pantalla por cada segundo; es aquí donde más hay que optimizar el juego, donde la capacidad de la propia CPU y del motor gráfico es primordial.
- CPU calcula la nueva posición (coordenadas) de los objetos de pantalla (imaginad un simulador de conducción o un "GTA V" con muchos personajes en pantalla), teniendo en cuenta la velocidad que llevaban (cada objeto de pantalla tendrá sus propias variables de velocidad, trayectoria, etc) y el tiempo-T que ha tardado la GPU en realizar los cálculos gráficos. A mayor tiempo-T de la GPU, mayor desplazamiento de los objetos habrá (como casi todos sabréis, Espacio = Velocidad * Tiempo).
De esta forma cuando el frame se plasma en pantalla la posición de los objetos siempre es la correcta en relación a su velocidad y al resto de objetos del juego. Pero dependiendo de la carga de trabajo que se exija a la GPU lo que si variará será la suavidad de la traslación de todos los objetos, puesto que cuanto más tarde la GPU en realizar sus cálculos, menos frames se dibujarán en pantalla por cada segundo (Frames Per Second = FPS).
Es aquí donde tenéis la respuesta a porqué los programadores reducen carga gráfica (resolución de texturas y polígonos, nº de polígonos que representan cada objeto, efectos aplicados, etc) para ganar fluidez (FPS).
Para que quede claro lo resumo: cuanto menos se exige a la GPU más rápido hace su trabajo y más rápido puede la CPU trasladar el resultado a pantalla.
Y ahora os hablo de esa solución, amada y odiada a partes iguales, que es el conocido “bloqueo del framerate”. ¿Qué quieren decir con aquello de “Hemos decidido bloquear el framerate de
Puesto que no todos los escenarios y situaciones de un juego son iguales, en un momento dado puede haber en pantalla 20 coches y un suntuoso decorado, y en otro momento sólo 5 coches y un escenario desértico. En el primer caso la GPU deberá hacer mucho más trabajo a la hora de calcular los gráficos de cada frame que en el segundo caso. Por lo tanto si no realizamos el “bloqueo de frames” (explico más adelante) en la situación de mayor carga gráfica se mostrarán menos frames por cada segundo, por la lógica explicada en los párrafos anteriores. Y en la situación de menor carga gráfica (con sólo 5 coches en pantalla) la GPU irá sobrada, con lo cual devolverá el control a la CPU muchísimo más rápido, poniéndose en pantalla muchos más frames por cada segundo.
Esto es lo que ocurriría en un juego en el que no se bloquea el framerate; la fluidez no es constante en prácticamente ningún momento. Aunque creo que esto no suele ser el caso común, y que normalmente se bloquea el framerate por arriba (en los juegos que NO exigen un gran rendimiento del hardware) o por abajo (en los que SÍ exigen un gran rendimiento del hardware). Luego pongo un par de ejemplos con vídeos de Youtube.
Si la oscilación de FPS es entre cifras difícilmente perceptibles para el ojo humano, no es demasiado apreciable: por ejemplo un juego que no exige el máximo de PS4, como "Tomb Raider: definitive edition", tiene bloqueo de framerate "por arriba", es decir nunca se permite que pase de 60 FPS, y en las secuencias de mayor carga gráfica la tasa cae a unos 40 frames por segundo. Pongo un vídeo de ejemplo (además, comparativo
):Pero en la decisión de bloquear o no el framerate, y si hacerlo por arriba o por abajo, creo que también influye el tipo de movimiento del juego. “Tomb Raider: definitive edition” no es acción lineal, por lo que supongo que los desarrolladores de PS4 no creyeron necesario bloquear el framerate a 30 FPS constantes, si no que prefirieron mostrar en pantalla casi toda la artillería posible en todo momento, buscar la máxima fluidez aunque haya oscilaciones de FPS en las secuencias con mayor exigencia.
Con los movimientos de cámara etc las oscilaciones son apenas perceptibles.
Pero en un juego de acción lineal (imaginaos un scroll lateral) es más fácil percibir las oscilaciones en el framerate. Supongo que eso es lo que pensaron los desarrolladores de “Need for Speed: Rivals” al decidir el bloqueo a 30 FPS de la versión PS4:
En este caso es bastante evidente que se trata de un "bloqueo por abajo", es decir que en muchos momentos PS4 podría sostener una tasa de frames más elevada y por lo tanto dar mayor sensación de fluidez... pero a costa de hacer perceptibles al jugador las oscilaciones en los momentos de mayor saturación. Y en un juego de velocidad esas oscilaciones hacen perder la mayor parte de las sensaciones.
¿En qué consiste bloquear la tasa de frames? Muy fácil, en obligar a que tiempo-T (la variable antes comentada) sea siempre mayor al valor deseado. Dicho de otra manera, sea cual sea el tiempo que tarde la GPU en realizar sus cálculos, la CPU realizará posteriormente los suyos, pero no se mostrará el frame calculado entre ambas en pantalla hasta que haya transcurrido un mínimo de tiempo. Se pierde tiempo “a posta”, por explicarlo llanamente.
Esto llevado a cifras: para mostrar 30 frames por cada segundo hay que mostrar 1 frame cada 1/30 segundos, es decir 1 frame cada 0,03 segundos aproximadamente. Sin embargo para mostrar 60 frames por cada segundo hay que mostrar 1 frame cada 1/60 segundos, es decir 1 frame cada 0,017 segundos aprox. (la mitad de tiempo, obviamente).
Sea cual sea el tiempo que tarde la GPU en devolver el control (0,028 segundos, 0,019 segundos, 0,004 segundos…) posteriormente la CPU realizará su parte del trabajo, luego “dormirá” el proceso (perderá tiempo a posta) hasta que hayan pasado 0,03 segundos, calculará por último cuales deben ser las posiciones de los objetos transcurrido ese tiempo, y finalmente moverá el frame a pantalla.
De esta forma se mostrarán en todo momento 30 frames/segundo, aunque potencialmente la máquina (CPU+GPU) podría mostrar más en los momentos de menor carga gráfica, pero a costa de perder esa buscada estabilidad.
Espero que este ladrillo divulgativo os haya servido para mirar con otros ojos a los desarrolladores de videojuegos. Esta lógica explicada aquí es apenas un átomo de la punta del iceberg que es la programación de uno de esos monstruos digitales que disfrutamos en la actualidad. Si pudierais ver la parte del código fuente de un videojuego poligonal relativa a los cálculos físicos de lo que ocurre en pantalla, veríais innumerables fórmulas y cálculos que seguramente muchos profesores Universitarios de Física tardarían muuuuuuuucho tiempo en descifrar.
Así es que espero que a partir de ahora encontréis sentido a los eternos créditos mostrados al final de los videojuegos, y a las dificultades que algunos proyectos han encontrado para que todo el conjunto física-gráficos-código de red funcione como debe (¿alguien dijo “Battlef…”
?).Saludos.
