Cada aplicación de Windows tiene en su centro un bucle que se ve algo como esto:
BOOL bRet;
while((bRet = GetMessage(&msg, NULL, 0, 0)) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Es el trabajo de la aplicación - no los system's operativos - para asegurarse de que los mensajes se envían. Como probablemente sepa, los primeros juegos de Windows usaban un método alternativo donde, en lugar de llamar a la función de bloqueo GetMessage, llamaban al PeekMessage, y luego llamaban al bucle de procesamiento principal del juego si no había ningún mensaje que manejar. Se utilizaron varias formas de retrasos para tratar de obtener una velocidad de fotogramas adecuada sin tomar 100% de CPU. Simplemente no había un temporizador lo suficientemente bueno para dar una velocidad de fotogramas suave.
Hoy en día, puede que no sea necesario escribir explícitamente un ciclo que llame al DoEvents. Es podría ser posible obtener una velocidad de fotogramas sin problemas mediante el uso de temporizadores de grupo de temporizador integrados (expuestos en .NET por System.Threading.Timer, y envuelto por System.Timers.Timer).
Como recuerdo, también hubo problemas para obtener eventos de mouse y teclado de manera oportuna. Utilizamos el acceso directo al teclado y al mouse en lugar de depender del bucle del mensaje, porque el bucle de mensajes a menudo era demasiado lento y algunas veces nos hacía perder información.
No he escrito juegos en varios años, y no sé cómo es .NET como plataforma de juegos. Es posible que la entrada siga siendo un problema, que la cola de mensajes simplemente no sea lo suficientemente rápida como para dar la respuesta rápida que los desarrolladores de juegos desean. Por lo tanto, omiten la cola de mensajes para tareas críticas.
Sí, te estás perdiendo la importante distinción de que un juego no es un servicio del sistema operativo. – Hejazzman