The term 'frame limiting' would imply that there is enough processing time per frame for at least one pass of the physics, rendering and logic. Frame limiting is used to prevent the physics/render/logic updating too quickly on faster machines than the minimum requirements.
Let's assume we have our game loop frame time split as follows:
Logic: ~3 fps
Physics: ~7 fps
Rendering: ~50 fps
Total: ~60 fps (minimum design framerate)
Limiting the frame speed to 60 fps will work fine here on all machines except those which cannot reach the minimum design speed of 60 fps, then we get the poor frame rates.
The only time you will benefit from separate timing is if you have redundant processing time available during each frame update. If a machine has a refresh rate of 85Hz in the above situation, we will have 25 fps free per frame to update the rendering or process more logic. But not the physics, which -must- run at an identical frame rate on both the 85Hz machine and the 60Hz machine for the simulation to remain accurate and consistent on both machines.
If you need the physics to run faster or with increased accuracy, you will have to sacrifice render/logic frame time, like so...
Logic: ~3 fps
Physics: ~7 fps (two passes at 7 fps or one at 14 fps)
Physics: ~7 fps
Rendering: ~43 fps (minus 7 fps)
Total: ~60 fps (minimum design framerate)
You can't process the physics during any spare frame time available on faster machines, because it simply defies the minimum requirements of the design. It would mean the physics will never run at full speed on the 60Hz machines.
In a nutshell, the physics MUST run at a constant frame rate, regardless of render/logic timing and free processor time during a frame. But most importantly, the physics MUST be able to run at full speed (whatever it is) at the minimum design framerate.
Let's assume we have our game loop frame time split as follows:
Logic: ~3 fps
Physics: ~7 fps
Rendering: ~50 fps
Total: ~60 fps (minimum design framerate)
Limiting the frame speed to 60 fps will work fine here on all machines except those which cannot reach the minimum design speed of 60 fps, then we get the poor frame rates.
The only time you will benefit from separate timing is if you have redundant processing time available during each frame update. If a machine has a refresh rate of 85Hz in the above situation, we will have 25 fps free per frame to update the rendering or process more logic. But not the physics, which -must- run at an identical frame rate on both the 85Hz machine and the 60Hz machine for the simulation to remain accurate and consistent on both machines.
If you need the physics to run faster or with increased accuracy, you will have to sacrifice render/logic frame time, like so...
Logic: ~3 fps
Physics: ~7 fps (two passes at 7 fps or one at 14 fps)
Physics: ~7 fps
Rendering: ~43 fps (minus 7 fps)
Total: ~60 fps (minimum design framerate)
You can't process the physics during any spare frame time available on faster machines, because it simply defies the minimum requirements of the design. It would mean the physics will never run at full speed on the 60Hz machines.
In a nutshell, the physics MUST run at a constant frame rate, regardless of render/logic timing and free processor time during a frame. But most importantly, the physics MUST be able to run at full speed (whatever it is) at the minimum design framerate.