Ok, I might know what's going on. First of all, this is how the original frame limiting (mostly) works:
info about frame limiting. It's from old times, but should still be (mostly) valid.
Read it? Good. Now about the subtraction - look how (theoretically) a main loop could be constructed:
while (notEnd) {
doStuff1();
doStuff2 { // dynamic function, calling address changes depending on the module we're in
startTheRDTSCTimer(); A
doStuff2a(); // here the actual processing work
idleUntilRDTSCReachesTheDesiredValue(); B
doStuff2b(); // here some other work
}
doStuff3();
}
So, the game makes sure that the time between A and B is
at least the time it calculated the frame processing should take... Wait a minute! What about the time it takes to get from B to A again? That's assumed to be exactly 10000 RDTSC ticks (for field).
This could affect the FPS slightly (now I see what you mean). One could correct it (slightly ;p) by moving the B just before A, or actually modding the limiter to take into account
at least the last frame processing time (each additional frame will add precision, but with exponentially lowering results - something like 4-5 frames should be enough).
About the panning - make sure that the mod in flevel is done (you could enter some pretty low value and see if the speed increases) and check without FRAPS on vanilla FF7 (no opengl - close one eye if it hurts to see those graphics ;p).