Why Old Games Run Too Fast: Fixing Speed Issues on Modern PCs

Why Old Games Run Too Fast on New Hardware

Have you ever attempted to play a classic computer game on a contemporary system and been surprised by its accelerated speed? This phenomenon is a common experience for those revisiting older titles.

We recently demonstrated methods for executing legacy software on current computers. This discussion serves as a complementary exploration, focusing on the reasons why certain older programs, particularly games, often exhibit incorrect behavior when run on modern hardware.

The Source of the Issue: Timing and Processing Speed

The core problem lies in the significant difference in processing speeds between older and newer computers. Older games were frequently programmed to rely on precise timing loops.

These loops would instruct the computer to perform a certain number of operations per second. On older, slower hardware, this timing worked perfectly.

However, modern processors are vastly faster. Consequently, these timing loops execute much more quickly, causing the game to run at an unintended, often excessively rapid, pace.

How Games Managed Timing in the Past

Early game developers didn't have access to the sophisticated timing mechanisms available today. They often relied on simple techniques to synchronize game logic with the refresh rate of the monitor.

For example, a game might have a loop that waited for a specific amount of time to pass before updating the game state. This wait time was calibrated for the slower processors of the era.

On a faster processor, this wait time is effectively ignored, leading to the game running at full speed without any limitations.

SuperUser and Community-Driven Q&A

Today’s question originated from SuperUser, a valuable resource within the Stack Exchange network.

Stack Exchange is a collection of question-and-answer websites built and maintained by a community of users. It provides a platform for seeking and sharing knowledge on a wide range of topics.

The SuperUser community is particularly adept at addressing technical challenges related to computing and software.

Understanding Accelerated Gameplay in Older Games

A SuperUser user, TreyK, recently inquired about a peculiar phenomenon: why older computer games exhibit drastically increased speeds when run on contemporary hardware.

TreyK described experiencing this firsthand, noting that games from the early 1990s ran at an unexpectedly rapid pace on a modern computer.

The Problem Explained

Instead of a smooth 60 frames per second, the gameplay became excessively accelerated, with characters moving at unrealistic speeds.

This resulted in a situation where even a simple action, like pressing an arrow key, caused the character's sprite to traverse the screen almost instantaneously.

The progression of time within the game was also significantly distorted, necessitating the use of CPU throttling software to restore a playable experience.

The Root Cause: CPU Cycle Dependence

The core issue stems from how many older games were designed to function based on the number of CPU cycles available.

Rather than relying on precise timing mechanisms, these games often directly correlated game speed with the processor's clock speed.

This approach was common during a period when CPU speeds were relatively consistent and predictable.

Why Older Games Relied on CPU Cycles

Developers of the time assumed a certain CPU clock speed, and their games were programmed accordingly.

Consequently, when these games are executed on a significantly faster processor, the increased cycle rate translates directly into accelerated gameplay.

The games essentially "think" time is passing much more quickly than intended.

How Modern Games Avoid This Issue

Contemporary game development employs different techniques to ensure consistent performance across a wide range of hardware configurations.

Modern games typically utilize timing mechanisms that are independent of the CPU frequency.

These mechanisms often involve querying the system for the current time and calculating game logic based on elapsed time rather than CPU cycles.

Key Differences in Game Design

Here's a breakdown of the contrasting approaches:

• Older Games: Directly tied game speed to CPU clock speed.
• Newer Games: Utilize time-based calculations independent of CPU frequency.

This shift in design philosophy prevents modern games from experiencing the same acceleration issues when run on faster hardware.

Timing is managed through system calls, providing a consistent experience regardless of the underlying processor speed.

In Conclusion

The phenomenon of accelerated gameplay in older games is a direct consequence of their reliance on CPU cycles for timing.

Modern games, however, have adopted more sophisticated timing mechanisms that ensure consistent performance across diverse hardware platforms.

Understanding Timing in Classic Games

A SuperUser contributor, JourneymanGeek, offers insight into how timing mechanisms functioned in older computer games.

It's likely that developers predicated their game logic on a fixed system clock speed, integrating internal timers accordingly. Many of these titles were designed for DOS environments and operated in real mode, granting them direct access to hardware.

They commonly assumed a processor speed of 4.77 MHz for PCs, and the equivalent standard for systems like the Amiga. This assumption allowed for optimizations, such as minimizing code size by omitting internal timing loops.

Early games also maximized processor utilization, a practical approach given the limitations of slower, often passively cooled processors. Adjusting processor speed was initially achieved through a “Turbo button,” which actually slowed the system down.

Contemporary applications run in protected mode, with the operating system managing resources. Modern OSes generally prevent DOS applications (running within NTVDM on 32-bit systems) from monopolizing the processor. Essentially, both operating systems and application programming interfaces have evolved.

This explanation draws heavily from a comprehensive guide on Oldskool PC, which provides a more detailed exploration of the underlying reasons. It’s a valuable resource for deeper understanding.

Tools like CPUkiller attempt to simulate slowdowns by consuming excessive resources, but this is inefficient. Utilizing DOSBox to control the clock speed experienced by the application is a more effective solution.

For those interested in the technical details of how early game code was structured – and why it often struggles on modern hardware without emulation – another SuperUser answer provides an extensive analysis of the processes involved.

Do you have additional perspectives on this topic? Share your thoughts in the comments section. Further insights from other knowledgeable Stack Exchange users can be found in the complete discussion thread.