After releasing a patch to limit the number of resolutions NFS: PU reports, I had to look a the problem of setting the wrong LOD (Level of Detail) for textures on fast PCs. It was empirically proven, that on CPUs running above 2 GHz all textures were set to the lowest detail what caused ugly graphics. On a x86 a program can use the Read Time-Stamp Counter (RDTSC) intruction to get the CPU clock rate. A quick search in OllyDbg has found 10 places w porsche.exe, where it is used. By setting brakepoints counting invocations on procedures executing RDTSC I’ve pinpointed the one run at the start of every race. The patch simply changes the return value of this procedure:
0055609D |. 75 08 JNZ SHORT Porsche_.005560A7 0055609F |. 8B4D F8 MOV ECX, [LOCAL.2] 005560A2 |. 894D FC MOV [LOCAL.1], ECX 005560A5 |. 8BC1 MOV EAX, ECX 005560A7 |> 8D0480 LEA EAX, DWORD PTR DS:[EAX+EAX*4] 005560AA |. 8BE5 MOV ESP, EBP 005560AC |. 5D POP EBP 005560AD \. C3 RETN
0055609D |. 75 06 JNZ SHORT Porsche.005560A5 0055609F |. 8B4D F8 MOV ECX, [LOCAL.2] 005560A2 |. 894D FC MOV [LOCAL.1], ECX 005560A5 |> B8 0000007F MOV EAX, 7F000000 005560AA |. 8BE5 MOV ESP, EBP 005560AC |. 5D POP EBP 005560AD \. C3 RETN
Since the value was returned in EAX, I’ve put there the constant 0x7F000000 which is basically means it always reports a CPU clocked at around 2 GHz. Additionally I had to modify the jump at @0055609D, because it pointed to an invalid location after the previous change. Several people have reported the patch works. Several people on the nfstuning.com forum tested it and confirmed it works.