Currently, there are 0 users and 0 guests visiting this topic.
Viewing 10 posts - 21 through 30 (of 30 total)
  • Author
  • #122249

    I think as long as vsync is enabled it will work. But rob would know better

    Messing with the VPinball app and push notifications.
    So if you haven't downloaded app yet what are you waiting for!?
    for IOS and Android



    @draifet : I would say. Go for it – it is experimental so, maybe something magical happens ;)


    Something magic like a broken computer maybe? Haha, just kidding. Thanks for sharing your knowledge.


    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.

    Higher is better.    The more delay you can insert without affecting your framerate, the more opportunity VP has to process the flipper input before vsync hits.   Add too much delay though, and you’ll miss vsync and get a visible stutter.

    It’s not a static delay – if the system is processing a heavy table it should skip the delay anyway, but there’s always a bit of a fudge factor with these things.



    Ok thanks, now is working I think, I will try for a few days. If I run tables with uncapped frame rate and Gsync enabled is useless?

    Hard to say what it will do.  It’s designed for a static frame rate.   On the other hand we know vpx does not do well with uncapped frame rates in general, which  is why setting FPS limiter at a high value that the system can reasonably support is usually recommended.


    Okay looking back at my rig, I did add this some time back.  I found 600 was my happy place for stutter vs frame rate vs flipper lagging.  I was playing in the 100s and never as low as 19.

    Back then it was chasing more flipper lagging/response time and before fastflips was a thing, but thought I would share my results


    Back then it was chasing more flipper lagging/response time and before fastflips was a thing, but thought I would share my results

    Yeah I think I run it at 600 too.

    The lag improvement will be in addition to what fast flips does.   But the improvement is not visible in the f11 readout since it improves the time when the button press is actually read (before the f11 measurement starts).


    I don’t have stutter but tried it anyways.  I don’t see a difference.  Running non exclusive fullscreen I still get stutter.  Tried hex settings of 19 (25) and 258 (600).  Given that I don’t see any perceivable difference, I deleted the registry key for now.

    Current Project: Perpetual updates of VPX physics.


    Interesting reading, not having the beefiest of systems I have had to tweak the detail setting on the odd table, just wondering which tables in particular you were seeing issues with?



    It is intended to reduce flipper latency when vsync is enabled.
    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.

    Wow this is a great thing! I have a lot of stutters despite using fast vsync, but I was afraid using this hack because I thought it might introduce latency which is the thing that worries me most.

Viewing 10 posts - 21 through 30 (of 30 total)
  • You must be logged in to reply to this topic.


Log in with your credentials


Forgot your details?

Create Account

The Vpinball app