Myst Online: URU Live Forums :: View topic - 30 Frames Per Second Cap...

Tesseract

Joined: 21 Mar 2007

Posts: 790

Location: Oz

Anyhow, it's all speculation until we get the code. So let's wait and see. Smile

dandin1

Joined: 05 Jan 2009

Posts: 2

The reason for capping at 30fps is that it's better to have a constant fps than a variable one. During periods that require a lot of processing power, an uncapped (or higher fps) game's framerate might drop to 30fps, and the player will immediately notice it. However, if you just keep it constant at 30fps, your eyes wouldn't notice a difference when replaying the event. For example, Halo PC has a 30fps cap:

Quote:

We actually had long discussions about this and many of us felt that consistent framerates were a much more pleasant experience than variable framerates.

[/quote]

JWPlatt

Creative Kingdoms

Joined: 09 May 2006

Posts: 5760

Location: Everywhere, all at once

That might be a reason, but it's not "the reason" until Cyan tells why they implemented the cap.

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.

dandin1

Joined: 05 Jan 2009

Posts: 2

Yes, you are right, I should have said "The reason most PC games cap at ...".

SeanScot

Joined: 10 May 2006

Posts: 111

Location: Gainesville, FL, USA

I agree with lifting the cap. I always felt there was something different about the way UrUCC looked compared with Live, but I couldn't figure it out. After reading this thread, I'm sure this is it.

Tesseract

Joined: 21 Mar 2007

Posts: 790

Location: Oz

dandin1 wrote:

For example, Halo PC has a 30fps cap:

Quote:
We actually had long discussions about this and many of us felt that consistent framerates were a much more pleasant experience than variable framerates.

[/quote]

Halo's 30 fps cap is one of three options, the others being no cap and vsync.

Gondar

Joined: 12 Aug 2006

Posts: 1587

Location: Here, there, you know. Around.

Actually, a good example coming to mind is GTA: San Andreas. (I was playing through it just recently). They have the "frame limiter" option, which keeps the game at a steady 30FPS (excepting slowdowns on bad systems). Why is this important? Because 90% of the features of timing run on it. If you turn it off, the framerate jumps, and a lot of the timing stuff like game clock, mission timers, some animations, handling, AI behaviour, and so on.. as they put it the gameplay becomes "variable" which is apparently (in my experience) codeword for "screwed up at times". Could be though my computer can make the game crank out way way more frames than it'd expect..

But the point holds. We'll need to see the code to know how tied in any framerate caps are.. for all we know it could involve rewriting everything from network to physics to the core interface. Or it could just be a matter of changing animation timing and you're done.

_________________
You know, I wish we would learn Atrus loved the 1812 overture, and in turn we had a copy for our relto.
That's right, a canon canen cannon!

MOULa KI: #00027582
Welcome back all!

Rusty_Russell

Joined: 25 May 2006

Posts: 9836

Location: Luton, UK

I have to admit to being slightly amused at this discussion. When I was in Prologue on my Ge Force 4 Ti 4600 I had an fps of oh... about 7 Smile

.

Marten

Joined: 15 May 2006

Posts: 2169

Location: Washougal, WA

So... are we in agreement that we want to fix it? At least make it an option. Even if it remains the default option. Smile

_________________

MOULa 26838 | Prologue Video Project: On Hold pending Minkata support
Visit rel.to to explore Myst, Uru, and D'ni communities!

JWPlatt

Creative Kingdoms

Joined: 09 May 2006

Posts: 5760

Location: Everywhere, all at once

To heck with a checkbox option. Make it a slider! (1 to 255 fps, with graphical option for lock [closed padlock on slider] or best-effort [open padlock on slider]) Wink

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.

semplerfi

Joined: 09 May 2006

Posts: 1659

Location: 312 miles from Cyan ...

Rusty_Russell wrote:

When I was in Prologue on my Ge Force 4

Ge Force 2 Go 32mb Smile

_________________
semplers' shards

Chuckles58

Joined: 19 Jun 2006

Posts: 563

Location: DFW Texas

JWPlatt wrote:

To heck with a checkbox option. Make it a slider! (1 to 255 fps, with graphical option for lock [closed padlock on slider] or best-effort [open padlock on slider]) Wink

Atrus - "Move the slider a little to the left ... no, the other left, YOU FOOL!"

_________________
<--- Click
"Laugh it up, Chuckles" -- Space Ghost to Rand Miller; MOUL KI #38615, Mulligan KI #37069

Lontahv

Joined: 14 Apr 2007

Posts: 261

Actually, I don't see any way that the framerate cap could be tied to the network or animation-timing. Framerates vary on different machines and putting a cap on it doesn't mean you instantly get a constant framerate.

Timing anims based on framerate... heh... this is something programmers do in 1st grade. Razz

I'm actually thinking this cap has to do with PhysX. When you have a refresh/redraw loop it usually looks something like this (or at least it does when I write programs):

Code:




TimeSinceLastUpdate = 0


while (1) {


   CalculateAndStepThePhysics(TimeSinceLastUpdate) //when this is finished depends on what the physics is doing


   UpdateMatrices(TimeSinceLastUpdate) //steps matrix anims etc.


   RenderObjects()


   TimeSinceLastUpdate = GetCurrentTime() - TimeSinceLastUpdate


}

So, you pass the step size to the physics and anim-stepper.

Reading about implementing ODE (open dynamics engine) into programs the docs say having a constant step makes things more stable. Yeah... well... but it's not very nice physics coming to a stand-still when your framerate goes down and cones getting really hyper when you have a good framerate either. Razz

I'm thinking that PhysX update call has some sort of sleep function call in it to keep things more "stable".

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

MustardJeep

Joined: 10 May 2006

Posts: 2185

Location: Houston

I've never seen anyone time based on frame rate, but I have seen a lot of people time based off the CPU rather then the Clock.

Some old programs are rather uh "interesting" when translated up from 233 mega hertz to 2 gigahertz. Shocked

_________________
Waymet

ddfreyne

Joined: 04 Nov 2006

Posts: 447

Location: Plasma Miasma (still… and I'm feeling nauseous)

Quote:

Reading about implementing ODE (open dynamics engine) into programs the docs say having a constant step makes things more stable. Yeah... well... but it's not very nice physics coming to a stand-still when your framerate goes down and cones getting really hyper when you have a good framerate either.

Game speed and framerate should, IMO, always be decoupled. This allows the game speed to be increased/decreased without affecting the redraw speed (which isn't particularly useful for Uru, but for other game types it may be). The other way around is true too: high (or low) redraw speeds will have no effect on the game speed.

The game loop example you posted doesn't do this. It couples state updates with redrawing as tightly as possible: the frame rate is fixed and that the game speed is the same as the redraw speed. With such a game loop, naïvely getting rid of the 30 frames-per-second cap would mean that the game could suddenly run twice as fast, or even shift between half as fast and twice as fast or so (I am already getting motion sick :P).

Topic

You can…