...someone promise me that they'll figure out why there's a 30 fps cap and make it stop if possible.

To be honest, the 30fps thing is essentially what... killed MystOnline for me. I just... couldn't figure out why it was needed and it just... made everything so... mind-numbing to look at.


~Joey Makeitstop!

_________________
"What you still don't understand you have failed to hear or don't need to know..."~Yeesha

Whilst I don't know about the Plasma 2.0 Engine yet (not having looked at the source code), I know that many systems and developers use 30 fps as a benchmark for 'fixed time step'. This means that if everything is running smoothly, you (the developer/software) know that you will get an update every 30th of a second. Microsoft's XNA used an 30 fps for its default fixed-step, for example.

Variable step (when the fps is flexible) requires calculating all movement/animation, physics, look-ahead, etc to be based of a variable number of milliseconds, increasing the potential calculation workload. I'm guessing that Plasma uses 30 fps as a target to make such calculations easy and provide ample time for network updates.

It would also provide it with a target to aim for, if it finds it needs to start frame-skipping to counteract graphics/network lag.

I intend to dedicate some time to working through the source code of client and server when it's made available. At that point, perhaps we can find a way to cleanly convert it to variable-step FPS.

I was under the impression that the 30-frames-per-second cap is there because much higher framerates have no big advantage. 30 may be a bit low, but having framerates higher than 60 seem like a serious waste of CPU/GPU cycles.

Quote:

Variable step (when the fps is flexible) requires calculating all movement/animation, physics, look-ahead, etc to be based of a variable number of milliseconds, increasing the potential calculation workload.

Not necessarily. A decent game loop can easily decouple game speed from drawing speed without increasing the calculation workload. The game state can easily be updated at 30 Hz while the screen is being drawn at a high framerate.

ddfreyne wrote:

Not necessarily. A decent game loop can easily decouple game speed from drawing speed without increasing the calculation workload. The game state can easily be updated at 30 Hz while the screen is being drawn at a high framerate.

Agreed. Just the way I've generally come across it in the past. The Update cycle in a variable-step system traditionally gets passed the millisecond time difference. It is then obviously down to it, and its associated threads, to decide what needs to be re-calculated etc before rendering. Apologies if I came across as suggesting that doing it ALL in that update step was the only way to go about this. Obviously the actual re-draw can be done on a separate time-cycle, as long as the two (update/draw) don't clash on their data accesses.

I'd definitely go for 60 Hz, since pretty much every monitor out there supports that as a minimum (maybe a few LCD monitors only do 59 Hz; you'd need to skip a frame but it could still be a superior experience, depending on the reasons why the 30 Hz cap was implemented); on the other hand I have a 62 Hz panel in a laptop that will handle 60 Hz just fine). Halving some internal rates (if that's all that's needed) and adding vsync will make most everybody with modern graphics cards more than happy.

I guess that people with wacky refresh rates could experience some effects of repeated frames, but it should be mostly unnoticable. If this was an action game, it'd be a problem, but I think that just going to 60 Hz will give people some extra room to get their twitch reflexes on and feel like the game is more responsive without causing too many timing bugs.

Of course, I'd rather that everybody had a smooth and uniform experience. I do think that current bandwidth, decent graphics hardware, and the fact that this isn't targeting consoles like XNA means that there's more of a reason to at least double that cap (if it's not impossible to remove it and let that be determined rationally by the system).

There is definitely an advantage to framerates higher than 30.

They don't cause my eyes to bleed.

_________________

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

I'd be happy if the cap was raised to 60 fps.

It is worth noting that as far back as PotS, Cyan used 30 fps as their method of calculating animation time based on number of frames.

And yet the game copes in those days when your framerate is bottoming out from the city?
(Well, for a given value of 'copes'.. it's crying over everything at that point, animations aren't alone)


I dunno, think that'd be fixable by a sliding multiplier. The only faults I'm seeing come up when your framerate suddenly jumps around while your avatars do too, so to speak.

Either that or recode it not to rely on a static framerate and let it spin away at what the computer can provide it with, like many modern games. Wasted gpu cycles? Sure, but if your game can take them they were sitting idle anyways, weren't they?

_________________
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!

Marten wrote:

There is definitely an advantage to framerates higher than 30.

They don't cause my eyes to bleed.

Has it actually? I can understand, but the effect is distinct from the old "CRT refresh rate" problem, even if you're still using a CRT. The faster the motion, the more pronounced I find the effects of low frame rate caps to be (nevermind pulldown in video transfers; that's a separate issue), and Uru isn't the fastest paced game out there.

I still feel that some animations in MOUL seemed "choppier" than in Complete Chronicles/Path of the Shell.

_________________

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

I agree. I noticed a difference in MOUL. I'd like to see this cap at least made a preference and not mandated.

_________________
-Whilyam

ddfreyne wrote:

I was under the impression that the 30-frames-per-second cap is there because much higher framerates have no big advantage. 30 may be a bit low, but having framerates higher than 60 seem like a serious waste of CPU/GPU cycles.

There are at least two things wrong with this:

1. It's my computer, not Cyan's. Let me make decisions about what I'd like to waste.

2. Uru: ABM, etc, as far as I know, ran open rate. So there's still a missing reason for a decision which was made for MOUL differently than for ABM.

Offline Uru looks much "real" and alive to me, like film. MOUL looks more flat, like video. I suspect it is because of the frame rate.

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

I don't really have any reason, but I don't like it when games limit their frame rate. I want to be able to update the graphics as fast as my monitor/video card will support. And higher frame rates do make motions look smoother, and that usually means it looks better.

_________________
Nothing to see here, move along.

ddfreyne wrote:

I was under the impression that the 30-frames-per-second cap is there because much higher framerates have no big advantage. 30 may be a bit low, but having framerates higher than 60 seem like a serious waste of CPU/GPU cycles.

One would think so, because 30 fps is quite good for television and movies, so one might conclude that the eye can't really distinguish more frames. But in reality it very much can, and the reason tv and movies still look good is because the frames have *motion blur*. But most game engines (including Plasma) don't attempt to create the equivalent, so all you get is disjointed frames without the visual clue of motion blur to help you interpolate frames. I'm not one to care much about things like Hi-def video and such, but here the extra frames really do make it much easier on the eyes.

I didn't personally notice Moul's animation choppiness, but I suppose it might be due to the quaternion compression (which wasn't used on Pots), which may behave erratically near some points. I haven't investigated this, though, so this could well be wrong.