Game running at hyperspeed, ideas?

[Ryzen]

Just to be clear you're using the official THF download link?
viewtopic.php?f=51&t=14169

The directx 9c version I'm using is "directx_Jun2010_redist" last date modified of 10/23/16 - I got it from the Microsoft website way back when.

Negative on the 7000 series [here] since I did the 5000 series. The upgrade to 7000 wasn't enough to justify the cost . =(

[Niixnec]

Found this over on EQemu - http://www.eqemulator.org/forums/showthread.php?t=41153&highlight=running+fast

Believe your cpu is running at 4500 - might at least be pointing in the right direction.

Niix

[banani]

I'm returning as well, with an AMD 7900 at 4500MHz and was seeing super speeds. I went into BIOS and dropped it to 4200MHz and seems to be working.

[Hektus]

I gave up trying to figure this out and then just yesterday decided to try again and immediately found the solution: set your bios clock rate to 4200 MHz. Why didn't I see this solution when I searched initially? /shrug If I had stuck around this thread a little longer I would have seen the answers from Niixnec and banani. Seems like there was a similar problem was AMD processors years ago and this new problem cropped up recently.

Anyways, I can finally play again, so that's cool.

[Ryzen]

Welcome back!

[Bootzey]

Welcome back!

[iowna001]

I thought I would post this?
In case others come here with the same issue.

This dll file is what fixed it all for me.
I found it on another EQ Emu site.

[Bootzey]

Thx for info, building new PC soon and i'm sure i'll run into this issue.

[moguay]

I performed a disassembly comparison test to more understand.

The posted version improves upon the first by using the full 64-bit timestamp counter for more accurate and robust timing measurements, especially over longer intervals. The use of shrd to shift the 64-bit difference and the adjusted right shift after multiplication suggest a refined approach to converting cycles to a time unit, making it a more precise implementation of the timing function.

Key Observations
Timestamp Precision:
The first version uses only the lower 32 bits of the timestamp counter, which limits its range and can lead to overflow in long intervals (approximately 4 billion cycles, or a few seconds on modern CPUs).

The second version uses the full 64-bit timestamp, providing a much larger range and greater accuracy, especially for longer measurements.

Timestamp Difference Calculation:
The first version computes a 32-bit difference, while the second version computes a 64-bit difference using subtraction with borrow (sbb), ensuring correctness even if the lower 32 bits wrap around.

Scaling Adjustments:
The second version shifts the 64-bit timestamp difference right by 2 bits (shrd eax, edx, 2) before multiplication, possibly to adjust the scale or account for a specific timing factor.

After multiplication with 10624DD3h (a constant often used to convert cycles to microseconds on certain CPUs), the first version shifts by 6 bits, while the second shifts by 4 bits, reflecting different scaling due to the initial 2-bit shift.

Initialization and Padding:
The first version explicitly zeros out memory locations before storing timestamps, which is unnecessary since they are overwritten.

The second version skips this step and adds nop instructions, likely for alignment or to match the instruction count of the first version.