Archived from groups: comp.sys.ibm.pc.games.action (
More info?)
"Magnulus" <magnulus@bellsouth.net> wrote in message
news:Ko3Fe.29116$TU.24429@bignews1.bellsouth.net...
> I know the concept sounds ridiculous... at first. But I think the idea
> has alot of merit. Yet few PC games use frame rate limiters.
Few PC games (that were written in the modern era) _need_ frame rate
limiters.
Assuming you have a modern (3 ghz or so) CPU, get a copy of GTA2 and disable
the framerate limit. Witness the results, and you might understand why ports
_resort_ to the use of framerate limiters.
> The whole idea of frame rate limiting is that it's not the upper maximum
> framerate that matters, but having a consistant framerate overall, since
> changes in framerate can be even more annoying than low framerate.
Ok, so say I am playing some 3d game. An uncapped framerate is 120 fps most
of the time. But then there's an area where the framerate drops to 10.
You're saying that if I capped the framerate, this would make things more
consistent. So now, I am playing at 30 fps (which has the same feel as 120
fps), and then I get to that nasty zone. The framerate drops to 10 again. In
other words, regardless of whether the cap is on or off, the game feels the
exact same way -- smooth in the good zones, 10 fps in the bad zones. It's
not like the GPU can "save up" on fps and then apply them to low-fps zones.
Calculations are done in real-time, yes? So a complex zone is going to be
slow (inconsistent) regardless of whether there is a cap.
> Look at
> movies or TV video- it only runs 24-30 frames per second. Many games on
> consoles have frame rate limiting, and some of the PC ports and a few
native
> PC games do as well.
>
There is a reason why ports tend to have limiters, and native PC games tend
not to. Also, you might want to look into "tickrate" to further understand
this issue. Most "framerate" limiters are, in fact, tickrate limiters. It is
necessary to limit tickrates because of the varying degree of CPU power in
PCs. You want a game to run in real-time, not processing time. It so happens
that with the right combination of computational complexity and
computational power, real-time = processing time. But this is a rare case in
PCs. In consoles, it's actually quite normal, since the hardware is known,
the developer can simply adjust complexity to match it. But when it comes
time to port the game, you are taking 700 mhz worth of software and putting
it on 3ghz worth of hardware. Without a limiter, the tickrate is going to
fly.