Originally Posted by Robert602
I can't explain why you say it looks faster. Does anyone know of a demo or game with a frame count? That way we could leave it running for 10 minutes or so then do the FPS calculation using a wristwatch and good old pen n' paper. If needs be, I can throw together such a demo that uses different methods for calculating FPS.
It is weird, at 3.2 ghz, when I click and rotate the skull I can see the effect of a low framerate (21fps), I.e. it rotates and swivels jaggedy.
When I run at 2.4 ghz yes the skull auto rotates slower but at 45 fps, but when I click and manually drag/rotate it now I can obviously see it swivelling left right very rapidly (at 40fps). When I click and drag it doesn't swivel at the jaggedy 25 fps but at the smooth 45 fps.
Just download rthdribl and you'll see what i mean.
Your method of calculation would not work if it is a script that depends on the realtime clock, eg a racing game with a laptime counter that is synched to the real world. Or any scripted motion.
Again just imagine a 3d model that auto rotates, but that you can also manually rotate (ala 3Dmax0, or menu screen of f1 Challenge '99 -'02)).
Downclocking slows down the speed of auto rotation (it rotates it 10% more in slomotion) but increases the fps at which it does run from 25 to 40 fps.
But when you cancel auto rotation by clicking on the object and drag it around yourself, it gets dragged at 40 fps! (you can feel this)
This is what seems impossible, for logically as you begin dragging,.. the fps should fall. It doesn't.
So in practice the Mobility 9600/9700 is capable of moving around a DX9 rthdribl model dragged around the screen by you at 45 fps,
while in normal operating condition it does so at 25.
Somebody suggest any way to officially bechmark this and I will do it.
PCmark and Pi are no good, neither is 3dmark03 as 3dmark results stay the same (as per shapeshifters findings) and the cpu tests obviously score less.