¿Deberían los FPS exceder los tics / segundos?

Una vez me dijeron que nunca deberías volver a dibujar un cuadro si la lógica del juego no ha cambiado desde el último sorteo.

Suponiendo que la lógica del juego se actualiza una vez cada tic, y suponiendo que un juego se ejecuta a 40 FPS @ 20 tics / second, ¿eso significa que cada dos cuadros consecutivos será exactamente el mismo? Si es así, ¿hay alguna diferencia visual entre un juego que corre a 40 FPS @ 20 ticks / second versus un juego que corre a 20 FPS @ 20 ticks / second?

Tal vez no entiendo bien el juego, pero me parece que ticks / second es un factor limitante de FPS.

Tu motor y tu juego deben ser súper flexibles para permitir la posibilidad de dibujar dos veces sin cambio de estado.
Un bucle de juego habitual vincula muy estrechamente todas las actualizaciones de forma secuencial.
Un hilo, un bucle, un punto para enjuagar events, un punto para ejecutar actualizaciones de procesamiento (procesadores de entidad / componente o simplemente actualizaciones del administrador) y, finalmente, una llamada de renderizado que activa el renderizado completo de 1 fotogtwig del motor.

El procesamiento de todo el motor de 1 fotogtwig se puede realizar de dos modos, extrospectivo (intrusivo), accediendo (con visitantes) al estado de los objects drwable del juego y creando los estados de renderizado, pases y commands que lo acompañan.

O podría conservarse por completo, y los procesadores configuraron el estado del motor durante la actualización lógica, y contiene suficiente información per se para dibujar un cuadro aislado.

Este es un bucle de juego clásico. Utiliza una variable delta_time que se otorga a todos los administradores durante la actualización.

Si tiene un administrador físico, generalmente hay otro bucle dentro de la Actualización, que usará un dt fijo e iterará la cantidad de time necesaria para completar el time de retardo para alcanzar delta_time . Y almacene el rest para la actualización del siguiente cuadro, para ejecutarlo como parte del primer ciclo la próxima vez.

Ahora, es posible tener un bucle de juego más avanzado al separar los tratamientos de events, utilizando una queue de events de sistema específica de subprocesss, preparando un grupo de events con marcas de time y cuando el hilo principal está en la actualización de tratamiento de events, tira de esta queue.

Es casi imposible personalizar totalmente las actualizaciones de los gerentes y la representación de frameworks. Muchas actualizaciones de estado del motor no son atómicas. Incluso un motor completamente retenido tendrá limitaciones. DirectX11 presenta lists de commands aisladas (dispositivos diferidos, en su lenguaje), que pueden ayudar a diseñar dicho motor. Pero si tienes tales dudas básicas sobre tu propio bucle de renderizado, supongo que aún no las usas.

Como estás en Java y hablas de tics, imagino que debes haber conectado tu function de actualización a un timer periódico. Por supuesto, esto es inferior a un layout de bucle de juego, incluso desde el layout de bucle más básico descrito anteriormente. No es así como se diseñan los sistemas de time real, sino que se basa en un marco que depende de la tasa de ticks del kernel nativo del sistema operativo y la máquina virtual de java para transmitir los events de activación (y progtwigción) para iniciar la rutina de frameworks. Esto generará malas tasas de muestreo (aliasing) y aleatoriedad de varias fonts. Tendrás que sufrir times de inactividad potencialmente largos que no están controlados, en la list de espera de list de hilos o en los problemas de networkingondeo de marca del timer de kernel. Esto se alineará incorrectamente con su presentación de velocidad de fotogtwigs, y dará como resultado tartamudeos, y si la queue de events no se agota por completo en cada actualización, también tendrá retraso de input y, potencialmente, se acumulará con el time. Peor aún, dado que usted está basado en events, me temo que sus events se consumen por el tratamiento de events, por lo tanto, su time de procesamiento variará de acuerdo con la input y retrasará la renderización de sus cuadros. Potencialmente totalmente enmascarado. Esto es como un defecto de security, muchas inputs podrían desbordar el juego y hacer que no responda.

Los sistemas basados ​​en events no están hechos para aplicaciones en time real, están hechos para aplicaciones básicamente inactivas .

Ahora, volviendo a tu pregunta, no debería ser un problema fracasar a 40FPS cuando tu juego se actualice a 20. También ten cuidado, en un sistema basado en timer, 20 FPS = 50ms, es probable que networkingondee hasta 60ms (4 * 15 ; 15 = kernel típico), por lo tanto obtendrá 16FPS. Use algunos cronómetros precisos para mostrar el time de actualización de cuadros en la pantalla y otro para mostrar la velocidad de visualización. (utilice un contador alnetworkingedor de la llamada Present . O framebuffer Swap (término OpenGL), o simplemente instale Fraps).

Esto te dará algunas statistics.

Las personas que defienden que las altas tasas de visualización son malas, probablemente se refieren a la pérdida inútil de resources, lo que resulta en calentamiento de la máquina, o el marco inútil tarda en terminar, la GPU no está list para renderizar el siguiente cuadro cuando está listo, es decir , probablemente justo en el medio del networkingibujado inútil. Por eso, no networkingibujar = mejor capacidad de respuesta, dejando la GPU disponible de inmediato cuando esté listo el siguiente cuadro.

También desgarro, es un argumento que a menudo se escucha. La rasgadura es causada por los swappings (presentaciones) frecuencias que no son múltiplos de la frecuencia de la pantalla. el VSynch es la característica que ayuda a que, mediante el uso de soporte de hardware, el cable VGA / DVI / HDMI transporta una señal que dice "¡Me volqué!", las tarjetas gráficas lo reciben, lo señalan a la CPU con una interrupción (lo más probable ), y el controller lo recibe y lo comunica a los hilos de presentación actuales de OpenGL / DirectX. Esto da rienda suelta a una copy rápida de ida y vuelta, que se ejecuta en mucho less que el marco de time de 60 Hz, y luego, cuando la siguiente pantalla se voltea, se presenta una image completa, esto evita perfectamente el rasgado .

Lo mejor es respetar esta velocidad de presentación, es un tempo dado por el hardware, y todo el hilo del juego / motor se pone a dormir por la API gráfica dentro de la llamada Swap / Present , que permite descansar la CPU, permitiéndola para enfriar, y permite la synchronization perfecta del cuadro / juego si se utiliza un ciclo lineal como se mencionó anteriormente.

Siempre que su juego pueda actualizarse más rápido que 60Hz. De lo contrario, caerá de inmediato a 30 fps naturalmente, luego a 20, luego a 15, por mesetas. Esta es una respuesta natural.

Depende de tu layout

Si tiene interpolación / extrapolación en su capa de renderizado, cualquier fotogtwig adicional se agregará a la suavidad de la animation. Por ejemplo, los efectos de partículas no afectan a la lógica de los juegos y pueden usar velocidades de cuadros mucho más altas. Su GUI podría funcionar a mayor velocidad de fotogtwigs para responder a la interacción del jugador más rápido.

Si no hay ningún cambio entre fotogtwigs ( sin interpolación / extrapolación / GUI ), saltarse los fotogtwigs adicionales es beneficioso, ya que ese fotogtwig adicional puede superponerse con el siguiente fotogtwig de ticks, lo que lo retrasa.

Considera Minecraft como un ejemplo de cuándo esta es una buena idea. Minecraft funciona a una velocidad fija de 20 tics por segundo, pero puede ejecutarse a cientos de fotogtwigs por segundo si está permitido. Los fotogtwigs entre los tics no son idénticos, en realidad Minecraft interpola movimientos y animaciones para suavizarlos, por lo que con un framerate más alto verás un movimiento más suave. Esta es una buena manera de compensar los altos requisitos de resources del tic-tac con los bajos requisitos de resources del dibujo. También permite un movimiento muy suave cuando se mira alnetworkingedor: el movimiento de la camera no tiene que estar restringido por la frecuencia de tic.