Why did they create PC games relying on a fixed CPU frequency instead of a clock function?

Question

I know there have been computer games which rely on a fixed CPU frequency. Instead of a clock function they rely on the fact that the CPU needs some time to execute the code.

But why did they do it? Aren't there drawbacks only?

For example if the game is made to run on a 300MHz CPU. If the CPU has 250MHz or 350MHz the game will run 17% slower or faster. Also background tasks running on the PC may be a problem (making the game run slower).

So why did anyone want to do this instead of using a clock function (which is much more accurate)? I'm sure there is an answer to my question.

Answer 1

Every game I've seen that assumed a fixed CPU frequency in some sense came from one of two eras:

First, games designed for the original IBM PC and its clones (what Turbo buttons were invented to preserve compatibility with) were designed in an era when CPU speed was effectively part of the platform's ABI. Like with prior platforms like the Commodore 64 and later consoles like the NES, SNES, Sega Genesis/Mega Drive, etc., the IBM PC was just assumed to be fixed-spec hardware.

Second, games like the original Unreal and Unreal Tournament (which will work on varying hardware but require you to lock your modern CPU to a fixed clock speed before launching them) were written in an era when x86 CPUs which could vary their clock speed dynamically during execution didn't exist, so measuring the CPU's speed at startup and assuming it would stay constant to avoid the overhead of making system calls to check a timer was perfectly reasonable to the point where not doing that would be just one of a wide swath of "Let's try to hedge against someone inventing a Star Trek tricorder or replicator in two years and using it to cheat" shots in the dark.

In both cases, the answer boils down to "Because that was a standard assumption at the time, based on experience with the platforms of the time, and which only seems flawed with the benefit of hindsight".

Answer 2

A typical clock function in the 1980s was not very high resolution. MS-DOS function 2CH apparently reported 100ths of a second, but was actually based on the 18.2 Hz timer interrupt, so it wasn't actually that high resolution. There was also overhead making a system call to find out the time, and every cycle counts at 4.77 Mhz.

Typical systems used interrupts instead. And those were typically:

• MS-DOS - 18.2 per second. See this post for some of the details and this one for some more.
• 60 (US) or 50 (Europe) per second. This was used in a lot of systems, including MP/M-86 (which I have first-hand knowledge and double-checked) and I believe plenty of other variants of the Digital Research operating systems, and other systems as well. This rate matches the local mains electricity AC frequency. Even though the computers all run on DC power, this was a very common timing to use.

It was only years later, as CPU speeds increased, that either higher frequency interrupts or a system call to read a higher-resolution time value became common.

Answer 3

The answers here are quite PC-centric, which is the wrong approach, as x86 PC were really late in the computer game industry. Before that, games were written and ported to specific machines. Machines that did not evolve in performance. A C64 or an Apple II ran at 1 MHz from the first to the last built. A Spectrum ran at 3.54 MHz. There was no point to synchronize to an external clock especially since most of the computers didn't even have a timer.

The code was guaranteed to run at a specific speed provided by the platform. The platform did not change. The same phenomenon existed with consoles, that had a fixed hardware during their lifetime, even if higher integration would change the hardware (PlayStation 2 exists in tens of different builds, but all have same performance).

Answer 4

But why did they do it? Aren't there drawbacks only?

They did it because the systems were slow and they needed all the speed they could get. They could get away with it because every compatible system ran at the same speed. When that was no longer so this technique was dropped.

The drawbacks became apparent when you had a system with variable speed. Also some games ran at different speeds depending on what was happening, which was often disconcerting and could make them harder to play.

Another problem that affected some systems was hardware malfunctions when a peripheral was accessed without necessary delays. This could cause eg. screen corruption, garbled sound, or copy protection failure.

Games that needed smooth animation were generally synced to the frame rate where possible. However doing this can cause a massive slowdown if the rendering takes too long and it skips a frame. Alternatively a game might take fewer frames to render on a fast machine. If the code just waits for the end of the current frame it will run faster than it should.

For some games it didn't matter though, eg. turn based simulations and board games. For example in Microsoft Solitaire the ending animation runs as fast as possible, but that doesn't affect game play.

Answer 5

I'm a bit too old to judge if even the first PC games should be considered retro or not, but...)

My guess would be that those who developed the first PC games, maybe had some background of older platforms and therefore (or otherwise) just wanted to take the most out of the HW, at the time when you could assume a certain CPU had a certain clock frequency

(An earlier reply was commenting about responses being PC-centric, but I guess that was what the originator of this chain wanted)

Answer 6

For example if the game is made to run on a 300MHz CPU. If the CPU has 250MHz or 350MHz the game will run 17% slower or faster. Also background tasks running on the PC may be a problem (making the game run slower).

On the other hand when they designed to run on a 4.77Mhz 8088, They wouldn't have that problem because that was the only kind of PC available at the time.

So why did anyone want to do this instead of using a clock function (which is much more accurate)?

I guess their crystal ball was broken.

I don't think anyone was expecting 40 years of backwards compatible hardware upgrades. Such a thing had never happened before.

Answer 7

One major consideration for game design is to make games deterministic so that one can rely on certain outcomes for certain input. Controlling a game by an external timer instead of synchronised to the game mechanics may result in "playthroughs" not working dependably.

Answer 8

Reason 1: It was the norm at the time

In the early to mid-80's it was the norm that a given platform, whether console or PC, that it was relatively static. The CPU was running the same speed on all devices and the video system and memory was often the same across machines of the same platform, barring some regional changes (eg. PAL vs NTSC).

For games, what would also usually occur, was that a game would often get completely ported to a new system or platform - sometimes resulting in a vastly different game between eg. a C64 and a NES.

While different platforms could have the same CPU (eg. a Z80), the underlying architecture of the rest of the system could also be vastly different, especially when looking at the video output system. In many cases, it resulted in simply being much easier to rewrite large parts of a game to adapt it to the new platform - while you were there, you adjusted the game loop timings accordingly.

Reason 2: Hardware

Most computers and consoles at the time did not contain other reliable timers than the CPU itself, meaning that, often, that the programmer simply did not have any other option.

At the same time, home computers and consoles were often rather simple, single-tasking setups, and resources were often very constrained.

It wasn't really until the PC platform started to include the 286 processor that a given hardware platform could include a multitude of different CPUs.

Yes, you could do rudimentary hardware detection to adjust the game speed and timings, but implementing such a system takes time and resources, and it wouldn't always be reliable. Often, the PC would have the (now classic) Turbo button as well.

The 286 did pose some additional problems as well (as well as the later x86s), as some instructions in the CPU itself were optimized, which could throw off the timing of game code all on its own. And old instruction that took 8 cycles of CPU time, would now take 2 or 4, for example.

Reason 3: Software

With the constrained hardware resources at the programmer's disposal, the most major problem was often not having enough resources to make use of high-level programming languages. At the same time, there was no room to run and make use of all the fancy APIs and libraries that games often make use of today. Programmers would have to interface and make use of all the hardware manually.

As a requirement, most games above a certain point (ie. all the fancy games with good graphics etc.) also need to focus on speed in order to handle all the things a game would need. Everything, such as the fancy graphics, sounds and input would all need to be handled in a timely fashion.

That all means that the programmer was often relegated to using pure Assembly or directly using machine code for their games. BASIC and other higher-level languages would all plain be too slow to produce satisfying results on these old platforms.

Reason 4: It was simply much easier Still today, when writing a game engine from scratch without fancy libraries and APIs, it's much easier to adapt directly to the hardware.

However, said libraries and APIs make it much easier to write games for a multitude of different hardware configurations. In a modern PC, you also have such things as a fairly exact RTC module that can help time operations down to fractions of a millisecond. Along with these features, the OS also holds your hand in different ways by taking care of hardware calls and handling concurrency/parallelization.

Summing it up:

All the modern, fancy stuff in the previous paragraph did not exist back then. Plain and simple. Combine that with the lack of variation on most platforms until around the mid-80's, you have the two answers to why many games were CPU-bound. It was often too difficult to implement hardware detection and code that could adapt to differing hardware. Concerning the platform landscape at the time, it was also often unnecessary to implement such a feature.

As for the PC market - even when the 286 was around, many developers would then simply program the game to fit the 286. Even then, the relatively minor differences in clock speed (most often between 10-16 MHz for most consumers) on the 286 would not pose significant differences in the speed of the game.

As a result, it wasn't really before the 386 era that time-bound game logic became best practice in the gaming industry. The clock and speed differences on the CPU (for the 386, between 12 and 40 MHz) now posed a larger issue for the speed of a CPU-bound game.