Super slight micro stutter on a few tables

Where do you add this because I search my registry for this (MinPhysloopTime) and nothing came up

Found this

https://github.com/vpinball/vpinball/blob/master/txt/RegistryKeys.txt

You need to login in order to like this post: click here

When did this show up??  Like above people had said kind of Important should be standard no?

It’s great that works but man keeping up with cutting edge changes is hard

You need to login in order to like this post: click here

For all I can remember which is up to last week I did it already, will have to check and see.  Thanks for the tip though

You need to login in order to like this post: click here

So I have been going nuts recently on rascals tables I get this super micro stutter ONLY when the ball is launched at the top of the table. I noticed it with Raven, and when asked no one had a similar problem.

Today, I loaded up his ready aim fire table and again, a micro stutter. Irritated, i started moving pieces off one by one till I found what was causing it. I tracked it down to the primitive at the top of the launch. I believe it was primitive 1.

I was trying a bunch of different things but when I switched off the setting and I’m drawing a blank now (I know it says switchable in script) the stuttering goes completely away!

And from what I can tell it has no affect on the tables. Not sure if you are running into the same thing as me, but that was my fix. Now to try yours tomorrow!

You need to login in order to like this post: click here

randr wrote:

Anyways @thalamus suggested adding a registry key for “MinPhysloopTime” =Dword:00000019 and so far the trouble tables are perfectly smooth and dare i say never seemed to be better! anyone think this will be a problem for future? and if not WHY is this not common knowledge?

It’s not common knowledge because the feature is VERY experimental, in the truest sense of the word.   I’ve been running it on my cab for a very long time and have been happy with the result, though.

It is intended to reduce flipper latency when vsync is enabled.    The concept is to anticipate when vsync will occur, and keep checking for flipper presses right up until then, instead of blindly going into an idle state waiting for vsync after the frame has been rendered.   To accomplish this, it inserts small delays to “smooth out” the physics steps so they’re closer to real time instead of doing everything in a bunched up way between vsyncs.

The risk of using it is mainly that it will cause stutters if you use too big a value.   If you’re saying it’s eliminating stutters for you, that’s even better news.

You need to login in order to like this post: click here

When I enter the 00000019 value, when i open again the key, the Hex values is 19 again, I did something wrong for sure.

I have MinPhysloopTime under MechTilt.

You need to login in order to like this post: click here

This is what was written about it previously :

“Player” / “MinPhysLoopTime” artificially lengthen the execution of the physics loop by X usecs, to give more opportunities to read changes from input(s) (mainly useful if vsync is enabled, too) (try values in the multiple 100s up to maximum 1000 range, in general: the more, the faster the CPU is, recommended tuning factor is 900 (90%))

– I’m still having troubles understanding how we ended up with hex 19. Lower is better – if PC can handle it ? … or ? @djrobx

Wouldn’t it make sense to have some kind of value related to the vsync ? Lets say half, 1/4. Not over ? I understand that this is experimental, and that is what I want to do, but, experiment with a bit more understanding of why I would pick one value over the other.

You need to login in order to like this post: click here