PDA

View Full Version : running to fast?



maurion
06-28-2007, 03:37 PM
I bought painkiller black edition the other day, but i had nothing else then problems with the game so far. First thing I noticed is that I was running really fast in the game, and my enemys also, like everyone had speedhack. I reinstalled the game, didnt had it this time, but when i got into the catacombs level, the game crashed. I restarted it, but everytime i loaded a game, it crashed (not when i started a new game). So I reinstalled again, and used all patches. again had the speed bug, reinstalled on another partition, patched till 1.61 and the game went smooth without bugs finally. Now im starting the game again, i got the speed bug again (it just disappeared when i loaded my last game, wich is in the opera level).

How the hell am i supposed to run this game without all the noobish errors and bugs?

I just ran a format before i installed, and my specs are more then enough (amd dual core, ati x1950xt, 1g ram).

blowfish
06-28-2007, 06:22 PM
You can try disabling a core if you are running dual core. But the problem is PK itself, and some uneducated decisions on how to time events.

Here's the background...

The speed up/slow down issue has been known about for a long long time, and is not limited to dual cores. In fact it is relatively easy on a low spec machine to create slowmotion by having lots of machine activity during PK startup. The reason for it is also present in numerous other timing processes.

Many other games make this mistake and it is often used for cheating. In PK, someone on a faster machine or dual core, is able to zoom around the map, even on MP servers. The same kind of effect was also used for cheats in CS 1.6, WoW, UT and so on.

We do have some work around tools, but this really needs to get fixed[1]. There are a whole host of other fixes for PK, but I can point you in the right direction for those later. On timing issues PK++ fixes a lot of the issues relating to the assumption there is a constant tickrate, no CPU excess load, etc. In general in SP, world speed is adjusted by WORLD.SetWorldSpeed when working correctly (for demo playback and mp testing, it would be nice if this was available in MP if you get chance to allow this).

--

The error occurs from SystemDriver::GetCPUInfo(), where SystemDriver::mSecondsPerCycle is determined from QueryPerformanceCounter() over 1/32th of a second. Subsequent to this, SystemDriver::mSecondsPerCycle is used by various timing/timer activities (mostly written in assembly) within SystemDriver.h.

However anyone familiar with using high precision timing should be aware of QueryPerformanceCounter's unreliability - something I expect you've seen before. QueryPerformanceCounter() and QueryPerformanceFrequency() *are* recommended by Microsoft rather than the 64-bit CPU time stamp counter (TSC)[2], but still relatively unsuitable for accurate time measurement on modern CPUs. Virtualdub.org provides a good overview of this issue [3].

At best QueryPerformanceCounter()/QueryPerformanceFrequency() should only be used with SetThreadAffinityMask, which can be used to specify one processor only [4]. Even then, it is still unreliable on many machines which frequently adjust the clock speed depending on the load; so-called frequency scaling.

Since PK only does this once, at startup, if it gets SystemDriver::mSecondsPerCycle when frequency scaling has occured, it will be wrong for the duration. It might be possible to adjust SystemDriver::mSecondsPerCycle on a regular basis, but not advised.

The most suitable method of overcoming this problem is to surround timer calls (GetTickCount) by timeBeginPeriod(1) / timeEndPeriod(1) and not use QueryPerformanceCounter/QueryPerformanceFrequency at all, and although this gives a resolution of 1ms*, it is *reliable*. Other much more stable games such as Quake 3 make use of this method [5].

Without setting this it could be up to ~20ms, but usually 10ms. After 20 years, 1ms is the most reliable accuracy we can get on PC's!

[1] http://www.reghardware.co.uk/2006/07/04/amd_dual-core_tweak_tool/
[2] http://msdn2.microsoft.com/en-us/library/ms644904.aspx
[3] http://www.virtualdub.org/blog/pivot/entry.php?id=106
[4] http://msdn2.microsoft.com/en-us/library/ms686247.aspx
[5] http://www.fileshack.com/file.x?fid=7547

I hope this is useful. It has been frustrating over the months (years now), amongst many other issues, not to be able to set this right myself. This is of course directed at DC, or anyone else able to compile PK.

Varus77
06-29-2007, 11:19 AM
It is and was this AMD CPU implementation bug, solved with her CPU patch:

http://dreamcatchergames.com/forums/showpost.php?p=212719&postcount=2

and/or:

http://dreamcatchergames.com/forums/showpost.php?p=188396&postcount=4