0040AB4B has some interesting clues as to how the variable is formed.
It's using timeGetTime to determine how many milliseconds it takes to perform a certain number of operations and how fast it can perform one operation and basing the time between frames on that.Actually, no. It makes FAR less sense than that. It contains beautiful snippets like this:
v3 = 1000;
v4 = 1;
if ( v4 >= 0 ) v3 = v3 / v4;
for ( i = timeGetTime(); i OR FFFFFFFFh <= 2 * v3; i = timeGetTime() ); //purposefully wait until timeGetTime's lower DWord value is less than 2000; BUT WHY?!
i = timeGetTime();
while ( i == timeGetTime() ); //This will have a small difference, but it never does anything with this delta
That's the most meaningless use of timeGetTime I can imagine. It doesn't do anything and it looks like it's literally designed to waste time. The next snippet at least makes some sense:
i = timeGetTime();
sub_40AA12(&v2);
while ( timeGetTime() - i <= v3 );
sub_40AA12(&v5)40AA12 gets the value from rdtsc (Read Time-Stamp Counter). Then it calls 40AA62 that then compares the two results and returns the delta. Essentially this is reporting the delta of rdtsc with a one second delay, but only sort of. From the documentation of rdtsc:
The RDTSC instruction is not a serializing instruction. Thus, it does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed.
That's a strange way of saying that what is returned may not be the exact value of the TSC (Time-Stamp Counter) by the time the instruction is completed.
In any case, this delta is what is the basis of the function DLPB mentioned at 4020C0. Because of the non-guaranteed read accuracy this won't directly represent a second and when this value is divided by whatever is passed to it.
1A78DC0 is the rdtsc delta divided by whatever passed value is.
1A78DC8 is 1000 divided by whatever passed value is.
The combination of these values and a few other sets a sleep function between frame draws (4020F0). That's where the inaccuracy lies. RDTSC and Sleep aren't serialized functions so their effects aren't exact. It probably works WAY differently on PSX because all the hardware is identical. Since there are hundreds (thousands maybe?) of PC processors you'd have to include a timing function to set the sleep function (which is the wrong way to do it).
Show Posts
Very nice. Why nothing after 1B? I remember jumps to code exist, This code doesn't do anything?