hail-to-the-ryzen wrote:By logging the RDTSC instruction in dosbox-x (cputype=pentium), verified that the RDTSC instruction is continuously called by UT99 (3dfx mode). However, where cputype is 486, then this instruction is not accessed. A simple text editor shows that timeGetTime() is included in UT99 binary, so a likely possibility is that there are two paths for setting the game speed. The first measures the passage of time by the RDTSC "clock" while the alternate path uses timeGetTime().
That makes sense, since RDTSC was only introduced with the Pentium.
The advantage of the latter method is that it is not dependent on RDTSC and a constant rate of cpu cycles. Reported causes of a non-constant rate are power saving features that regulate cpu speed and the use of multiple cores in a modern CPU. A possible disadvantage is a perceived loss of in-game performance.
hail-to-the-ryzen wrote:In testing, the cpuspeed parameter was not used at the commandline to run UT99. However, this was tested on a modern CPU in 3dfx mode. Reducing the cpuspeed, such as cpuspeed=1000 on a 2000 Mhz cpu, resulted in a very fast game speed. In this case, the parameter value overrides the value calculated by UT99 and sets a slower cpu cycle rate than the real cpu cycle rate (1/2 in this example). Since the RDTSC instruction reports the real cycle rate, in-game runs at 2x the intended "game clock".
There was a time when RDTSC reported the actual cycles that a CPU executed. In the Pentium-days, there was no power saving yet, so the clock speed was fixed.
When power saving was first introduced, initially RDTSC still reported the actual cycles. Since that caused problems with unsuspecting software, which tried to use it as a clock signal (it's not, it was meant to be a debugging tool, to measure performance at the instruction level).
So eventually RDTSC was redesigned so that the speed was constant, regardless of the CPU clocking down or up (which means you lost the performance measuring capability).
UT99 is most probably in the 'unsuspecting software' category, which assumes RDTSC runs at a constant clock speed.
Technically it's not incorrect to have the RDTSC not matching the actual clock speed.
However, when you're emulating a Pentium, it is.
I'm not sure what you mean exactly though... UT99 probably measures the actual frequency of RDTSC once at startup. So if the game speeds up or slows down when you change the emulator's clock speed while the game is already running, that is expected behaviour. If the game is the wrong speed when you select a different clock speed before starting the game, but then don't change it, that may be a bug in the emulator (or a bug in the detection routine of UT99, which was likely only tested on real Pentium systems in a given clock speed range).
If you are talking about changing the clockspeed of the host machine, affecting the emulator's speed (assuming the host machine is still running fast enough to handle the emulation of the target machine), then that too would be a bug in the emulator.
Someone before said they had the same problem, and weren't able to properly resolve the issue, and it wasn't easy to. Is it supposed to build correctly?