Si alguna vez ha intentado ejecutar un juego de computadora antiguo en un sistema moderno, probablemente se sorprendió de lo rápido que se ejecutó el juego. ¿Por qué los juegos antiguos se salen de control en el hardware moderno?
Hoy, le mostramos cómo ejecutar software antiguo en computadoras modernas; La sesión de preguntas y respuestas de hoy es un buen cumplido sobre por qué algunos software más antiguos (especialmente los juegos) nunca parecen funcionar correctamente cuando intentas ejecutarlos en hardware moderno.
SuperUser, una subdivisión de Stack Exchange, una agrupación comunitaria de sitios web de preguntas y respuestas, nos ofrece la sesión de preguntas y respuestas de hoy.
La cuestión
El lector de superusuario TreyK quiere saber por qué los viejos juegos de computadora se ejecutan increíblemente rápido en el nuevo hardware:
Tengo algunos programas antiguos que tomé de una computadora con Windows de principios de los 90 y traté de ejecutarlos en una computadora relativamente moderna. Curiosamente, corrieron increíblemente rápido, no, no a 60 fps, más rápido, oh, Dios mío, el personaje, caminando a la velocidad del sonido. Pulsaba una tecla de flecha y el sprite del personaje cruzaba la pantalla mucho más rápido de lo normal. La progresión a lo largo del tiempo en el juego iba mucho más rápido de lo que debería. Incluso hay programas diseñados para ralentiza tu CPU para que estos juegos sean realmente jugables.
Escuché que está relacionado con los juegos basados en ciclos de CPU, o algo así. Mis preguntas son:
- ¿Por qué los juegos más antiguos hacen esto y cómo les fue?
- ¿Cómo no funcionan y se ejecutan los juegos más nuevos independientemente de la frecuencia de la CPU?
Entonces, cual es la historia? ¿Por qué exactamente los sprites del juego antiguo se iluminan en la pantalla tan rápido que el juego se vuelve injugable?
La respuesta
El colaborador de superusuario JourneymanGeek lo desglosa:
Creo que asumieron que el reloj del sistema funcionaría a una frecuencia específica y vincularon sus temporizadores internos a esa frecuencia de reloj. La mayoría de estos juegos probablemente se ejecutaban en DOS y eran modo real (con acceso completo y directo al hardware) y suponga que está utilizando un sistema iirc de 4.77 MHz para PC y cualquier procesador estándar que este modelo funcione para otros sistemas como el Amiga.
También tomaron atajos inteligentes basados en estas suposiciones, incluido el ahorro de una pequeña cantidad de recursos al no escribir bucles de sincronización internos dentro del programa. También usaron tanta potencia de CPU como pudieron, lo cual era una buena idea en los días de chips lentos, a menudo enfriados pasivamente.
Inicialmente, una de las formas de sortear diferentes velocidades de procesador era la antigua. Botón turbo (que ralentizó su sistema). Las aplicaciones modernas están en modo protegido y el sistema operativo tiende a administrar recursos; no permitirían que una aplicación DOS (que de todos modos ejecuta NTVDM en un sistema de 32 bits) use la CPU completa en muchos casos. En resumen, los sistemas operativos se han vuelto más inteligentes, al igual que las API.
Fuertemente basado en esta guía en Oldskool PC donde la lógica y la memoria me fallaron, esta es una gran lectura, y probablemente profundice en el «por qué».
Cosas como CPUkiller utilizando tantos recursos como sea posible para «ralentizar» su sistema, lo cual es ineficiente. Es mejor que uses DOSBox para administrar la velocidad del reloj que ve su aplicación.
Si tiene curiosidad acerca de cómo se implementó el código real en los primeros juegos de computadora (y por qué escalan tan mal en los sistemas modernos sin estar en una caja de arena en algún tipo de programa de emulación), le sugerimos que también verifique esta larga pero interesante descomposición del proceso en otra respuesta de SuperUser.
¿Tiene algo que agregar a la explicación? Habla en los comentarios. ¿Quiere leer más respuestas de otros usuarios expertos en tecnología de Stack Exchange? Consulte el hilo de discusión completo aquí..