Minkata Shard Update December 14th, 2015 (Build 82, updated to Build 88)

[Christian Walther]

The jerkiness is interesting. I thought the frame rate limit was addressed a while back, around the time of the PhysX changes, but maybe not.

You may be thinking of this discussion, which was about an improvement to “laggy” behavior in low-framerate situations, so the opposite of what is being discussed here.

[Mac_Fife]

Possibly. I do remember discussion about raising or removing the frame rate cap, but it's likely that was an entirely seperate discussion and I'm simply misremembering what followed.

[rarified]

My personal preference would be what was alluded to before -- a scheduler tied to the display frame refresh rate. I have not looked into the event handling needed for such a change though. _R

[Christian Walther]

That’s what the “Vertical Sync” checkbox in the graphics settings should do, if it’s implemented properly – no event handling required.

[Hoikas]

That’s what the “Vertical Sync” checkbox in the graphics settings should do, if it’s implemented properly – no event handling required.

Except the client limits it to 30fps while vertical sync limits you to the monitor's refresh rate (usually 60Hz), so you still observe the stuttering behavior. The Gehn client works great with the limiter totally removed (except it's reapplied during the loading process).

[Christian Walther]

Yes, I meant in absence of the 30 fps limit.

[Hoikas]

Ah, I understand now. VSync is handled by DirectX itself, so that should work properly.

[rarified]

So what happens in the client if the governor is "removed" and "Vertical Sync" is not checked? CPU saturation, and movement overrun/redo at each DirectX refresh?

_R

[Hoikas]

In windowed mode, removing VSync has no effect because DirectX can only update at the refresh rate there. In fullscreen, the main thread only is fairly busy so as long as the client hwnd is active. The draw call blocks in exclusive fullscreen if the client hwnd is inactive. There are several calls in the main thread to functions like sleep, getmessage, etc that keeps things responsive and from truly saturating the main thread.

Of course, in the H-uru codebase exclusive fullscreen is going the way of the dodo and will be replaced by a fake fullscreen mode that operates just like windowed mode... except fullscreen

[Treehugger]

Hmm, I'm not able to confirm either the Gahreesen animation jerkiness or the misbehaving camera in Kemo. Both seemed to be behaving quite normally, so I suspect it's a "local" issue. Perhaps if you re-check these on a later visit, maybe after re-starting the client, then we can look to see if it's something that is persistent.

the camera in Eder Kemo keeps sticking - you can click to first person to complete the age, so it's not a game-critical problem, but it's annoying when it swoops, gut-wrenchingly, when you're not expecting it. You end up staring at the wall beside the journey cloth that you have to walk up the sloping wall to get to (sorry, don't know how else to describe it.)

I visited Eder Kemo, specifically this Journey Cloth to test this out and couldn't recreate it. I had no issues with the camera there. The camera does move, but I think it's only the way it was intended.

Finally, I can check on both these issues using my Win 8.1 laptop. I can report that Gahreesen does not appear jerky, but the avvie for whom the Kemo camera misbehaves, who was created new for Build 82, still has that problem.

Thanks for bearing with me, folks!