Clockgen and Direct3D game problems...

I hesitated posting this before, because the last 2 times, no one replied... (yet I KNOW people have had this problem, as others have posted similar things).

Anyway:

Problem:

When running clockgen on Windows XP, to overclock or underclock, some direct3D games get **SPED UP** or slowed down, by the same percentage of the clock change. (note: running clockgen, setting the new FSB, and *then* launching the game, not running cgen while the game is running).

Games that get sped up/slowed down: (Just a small sample)
*PLEASE NOTE: All are tested in single player mode, so Multiplayer "fixes" against system timer hacks (like the old sys timer multiplayer game speedup hack from years ago, though that one does not work on XP) don't apply.

Battlefield 1942
Unreal Tournament '99 (and all games using the UT engine; Rune, Wheel of Time, etc)
Mageslayer
RTHDRIBL demo

Games that are not affected:
All OpenGL games (Quake, Quake 2, Quake 3)
Unreal Tournament 2004
Aliens vs Predator (Dx6 game, but Mageslayer is ALSO a DX (3,5, 6 or 7) game
Aliens vs Predator 2

Again this is not a complete list; just the few I tested.

Now--the question is: *WHY*?

Why would clockgen cause some games to run faster or slower than they should, while others are fine?

Again, this is not because the system timer is sped up improperly--(that was my original guess before). If the system timer were being sped up, it would affect all single player games and OpenGL.

(there is an updated hack program that does allow you to change the timer on XP, but results aren't exactly 'great').

Anyway: Regarding clockgen:
Is it some part of directX does not like the clock rate change?
If so, why are some directX 8 games affected (BF1942), while other DX8 games are not affected (Unreal tournament 200x)?

*Please note* :
This bug does NOT happen on windows 98se, under the same tested games (but using SoftFSB instead, as it's a much older P3 motherboard).


(P4 3.4 EE, IC7 max3, X800XT-PE).

Yea, you can essentially make "speed hacks" doing this.

I stumbled upon this when I used AINOS, which is a dynamic overclocking utility included on most ASUS boards. It leaves the system at stock speeds, and then when the system goes under heavy load it OC's the system.

So I was using this once, and I opened up my favorite game America's Army (I would have been at stock speeds) and then once I had it running for a bit, it boosted my system about 800 MHz. My game ran noticeably faster, and I could like sprint by people even if they had a head start running.

As far as why this occurs, the game must obviously make a note of your CPU speed on startup, and it expects your machine to handle instructions at THAT speed, if your CPU speed changes mid game, the game is unaware of it, so it is still trying to do things at the slower clock speed even though your CPU is much faster now.

If you were into cheating and what not, you could make a pretty bad speed hack using this sort of technique. I'm a clean gamer though, so I wouldn't do this sort of thing --Lutzy

edit: America's Army uses the Unreal Engine for those who don't know.

edit2: Just re-read your post and saw you said you weren't changing the speed during game but beforehand. Hmmm... Maybe on boot DirectX makes note of your processor speed? I'm out on a limb here, but what else could it possibly be?

Lutzy said:

Yea, you can essentially make "speed hacks" doing this.

I stumbled upon this when I used AINOS, which is a dynamic overclocking utility included on most ASUS boards. It leaves the system at stock speeds, and then when the system goes under heavy load it OC's the system.

So I was using this once, and I opened up my favorite game America's Army (I would have been at stock speeds) and then once I had it running for a bit, it boosted my system about 800 MHz. My game ran noticeably faster, and I could like sprint by people even if they had a head start running.

As far as why this occurs, the game must obviously make a note of your CPU speed on startup, and it expects your machine to handle instructions at THAT speed, if your CPU speed changes mid game, the game is unaware of it, so it is still trying to do things at the slower clock speed even though your CPU is much faster now.

If you were into cheating and what not, you could make a pretty bad speed hack using this sort of technique. I'm a clean gamer though, so I wouldn't do this sort of thing --Lutzy

edit: America's Army uses the Unreal Engine for those who don't know.

edit2: Just re-read your post and saw you said you weren't changing the speed during game but beforehand. Hmmm... Maybe on boot DirectX makes note of your processor speed? I'm out on a limb here, but what else could it possibly be?

Click to expand...

DirectX can not be doing this. I have 9.0C on both computers.
Otherwise--I would have the exact same issue on windows 98se, on my BH6 1.1/P3 motherboard and CPU, as I do on XP and my P4.. And the same directX installation goes on 98, ME and XP.

Just tested Mageslayer on win98se.
I used the old speedhack program to speed up the system timer; sure enough, mageslayer sped up.

I then set it back to normal, and then I overclocked my CPU on the fly (with Mageslayer running), with Soft FSB--and---no effect--the game ran at the same speed (even though the CPU was running 100% faster).

Yet...in Windows XP....if I use clockgen to change the CPU speed (when the game is not even RUNNING YET), and then launch the game, the game speeds up?

BTW, again--why do some games speed up and others don't? Remember, the games that are not affected (UT2004, Aliens vs predator 1 and 2) are also directX....

what I need to know is if others can reproduce this problem. (if they can understand anything I've said

There's one more thing left to try here....

There's two basic ways for a game to do it's timing.

The first method is to use the timestamp counter (TSC), which is incremented by one for each processor cycle (though the most recent P4's do some non-standard stuff which can muck some things up in power-saving mode). The game, during intialisation, finds out the speed of the CPU, and calculates the change in game time by dividing the TSC change by the frequency.

The second method is to use the Windows "performance" counter. This is a high-resolution timer that can be using one of several timers in a modern computer.

Yes, there are several timers. At a minimum, a recent PC has the TSC, the realtime clock, "timer 2" (sometimes called the system timer), and the APIC timer. Most recent PCs also have an ACPI timer and a HPET timer as well.

The TSC is simply a counter that is incremented by 1 every clock cycle. The realtime clock is the thing that originally kept the CMOS date/time accurate, and ticks at a rate of once per second (obviously ). "Timer 2", which is also knowns as the programmable interrupt timer (PIT) originally was a "spare" timer that was used for various timing-related things in general code (such as floppy disk drive timeouts and the like). It has a variable interval, from about 55ms down to about 1us. There is a high cost (cycle-wise) for reading this timer, which limits it's accuracy.

The APIC timer is very similar to the TSC. It is incremented once per bus cycle (so 200MHz for a 800FSB P4, etc). The ACPI timer is a high-resolution system independent timer that's meant to be fixed frequency across all computers. Usually resides in the southbridge. Finally, the HPET is a hotted-up ACPI timer with better accuracy, more functionality, and generally better

From this big selection, Windows usually picks two. The choices for the first, the "performance" counter, are motherboard dependent, but it usually goes in the order HPET, ACPI, TSC, PIT. The second timer is always the PIT.

Now, getting back to the methods that a game can use. The first one requires that the CPU speed is constant over the duration of the game, and that the clock speed can be obtained sufficiently accurately to start with. The first is usually a given during gaming, which gobbles any spare CPU cycles and stops power-saving modes from kicking in. Obviously things go wrong if the CPU thermal-throttles, but I'm going to ignore that The second is a bit more complicated.

There's quite a few ways to find out the CPU frequency. The first is to ask Windows. During boot, Windows uses the PIT timer to calculate the CPU speed (counts cycles per timer tick, multiply by ~18 to get frequency). This is usually fairly accurate, though you will see drift of a few MHz if you keep on rebooting Windows. Of course, this number is completely wrong once you start using clockgen or similar. The second method is to calculate it yourself. There's several ways to do this as well You can count the number of CPU cycles for each performance counter cycle, then ask Windows for the frequency of the performance counter. This works well, but backfires when Windows is using the TSC for the performance counter (as Windows uses the value it calculated at boot for the frequency). The other way is to do what Windows does: when your game starts, count the number of cycles per RTC tick, and use that to calculate the frequency. Most CPUID programs use the former (the performance counter method) which fails on some boards when using PowerNow and the like.

The second method, using Windows to keep track of the time, involved only whichever timer is being used for the performance counter. So this method fails when Windows selects the TSC as the timer, as it always uses the boot-time CPU frequency.

Soo ... there's only one certain-to-work method: determine the CPU frequency yourself when the game starts up, and then use the TSC along with that for timing. Any other method is prone to failure when the clockspeed has changed from what it was at boot, especially if Windows is using the TSC for the performance counter.

What you are seeing in your games is a manifestation of this. Some games do it correctly and function as expected when the frequency changes. Others do not, and as a result malfunction. Different versions of Windows use different methods for selecting the performance counter (eg: Win9x never uses the HPEC or TSC timers), and different motherboards support different features. This is why some motherboard/OS combinations fail and others do not.