357 replies to this topic

[toxie]

This is all already done like you describe (in a nutshell).

 

So basically the input is handled as soon as possible (e.g. at the beginning of the to be rendered frame), and then all scripts and timers are run to handle this new input (and all the other stuff of course that the script does), then the movement of the flipperfinger is started due to this immediately as soon as the script triggers it. Then, also immediately, the physics engine starts handling the requested movement.

 

BUT: due to the way the PM5 physics code works, there is a bit of a "startup" phase in the physics, which might simply be an artifact of a hack done to fix something else. This is what my tweak does resolve mostly, but you guys have to find out if this is okay like-is or if it leads to other sideeffects.

 

I'll investigate behind the scenes to see what really happens.

[Slydog43]

With Flupper1 test table I get 40ms with left flipper with regular PinballX (10.2) and get 19ms with Toxie test VP build.  Still have to record this with a camera to see if there really is a difference.  It seems better, but it might just be that I want to see it better (or faster).   This is a GREAT topic and think it can only improve VP.  Thanks everyone, cause its very important!

[Ben Logan]

Thanks Toxie and Flupper1. Can't wait to test this when I'm back home tomorrow. You guys are brilliant.

[unclewilly]

One quick question about the flippers in general.
On a lot of tables like my bad cats release, primitive flippers are used overtop of invisible vp flippers. Due to them being timer based for the rotation, will that show even more lag even if the invisible vp flippers don't have as much lag?

Hope that makes sense

[toxie]

No, that should be pretty much perfect, if the timer runs at least with roughly 2x the FPS (so if you have 60Hz monitor: 120Hz = set timer interval of 1000/120 = ~8).

 

On a sidenote: Imagine the VP timers as not being real realtime timers that get triggered at each point in time that you specified, but these are always triggered at the beginning of each rendered frame, BUT in perfect sync with the rest of the script and the rest of the engine, e.g. there can be dozens of calls to the same timer callback within a short amount of "real system time", but in "VP simulation time" its all perfectly in sync so the script itself won't notice (unless you use a real VBScript Timer() call that gets you the actual system time).

 

This is also why all these timings done in here using the Timer() function can fluctuate so much between values. But nevermind, in the average its all good enough what we measure here.

[Slydog43]

I forgot to mention that I played Bride of Pinbot (an awesome table) a bit to test out the test build and flipper "tricks".  I could do a post pass very easily and hit every ramp that I tried (or at least very close).  This was without playing VP first as I stated earlier I think it tricks my brain to hit the flippers early.   This is such great findings.   Can someone post a table that seems to have very laggy flippers to test out on.

Edited by Slydog43, 25 October 2016 - 03:45 PM.

[toxie]

So i did some more digging around, and i think this is really just a hack from PM5 that went wrong.

Its a "useful" one maybe for the EOS case, but not when starting from the Park position and wanting to flip from that. I'll have a slightly more robust fix in soon.

[fuzzel]

Mr Fixer

[toxie]

I prefer 'Mr. Fixy' 

[tttttwii]

Hi Toxie, some time ago you introduced "new physics" in kind of a beta version of vpx. Together with this tweak, can your corrected flipper physics work better?

[flupper1]

I tested it for three settings (all no 4xAA and no AO,1080p):

10.2beta without fix (475fps): steady 40/41ms delay and able to screenshoot the delay (prim already up, normal flipper still down)

10.2beta with fix (475fps): 19/20ms delay and able to screenshoot the delay (prim already up, normal flipper still down)

10.2beta with fix (475fps) with mass halved and strength doubled on the left flipper: 9/10ms delay and still able to screenshoot the delay (prim already up, normal flipper still down)

 

And tested in WIP Diner (373fps, no 4xAA, no AO): the delay is sort of halved to 18-33ms, but still fluctuating and significant. With some mass and strength tweaks, it goes down to 9-25ms.

 

So my conclusion is for now:

Much better with this fix! So optimal lag reduction would need:

- this fix (~20ms reduced delay on my setup)

- primitive flippers who visually perform the "rotate to end" in one step (~visually 10ms) (or even in the 10.2 code something like this, so it is not only visible speed, but also physics)

- keyup and keydown interaction (something like what Knorr proposed) to reduce the fluctuating VPM delay (9-??ms)

[toxie]

The new tweak should reduce it even a tiny bit more, but i'll wait for fuzzel to do a new build.

 

In addition to your conclusion: Did you also try to set the pre-rendered frames in the video settings to '1'? Cause i changed the implementation to match NVIDIAs control panel setting nowadays.

 

@tttttwii: there were no real new physics tweaks recently, only minor details, or which changes do you mean?

i still have a lot of WIP code though lying around, but this is mainly targetting the actual collision handling code and the hacks around that (e.g. no lag reduction from that stuff).

[flupper1]

activating pre-rendered frames has no effect (1 or 2), still 19 or 20ms. But: activating FPS limiter to 1 reduces the delay to 5 or 6ms! And reducing the flipper mass to 0,5 made the measurement 0/1ms! However: it might move the delay out of the measurement, and into vsync delay, no way to know that for sure...

[toxie]

Yes, the pre-rendered frame setting will not change the thing you measure with the testtable, but 'just' the buffered frames within the gfx driver. But it gets more relevant if you have vsync enabled and/or a slow machine.

[Ben Logan]

Flupper, do you have a high refresh rate Playfield monitor? Activating Vsync makes my flippers feel laggy with my 60hz Playfield tv, so I'm leaving vsync off for now. Wondering if you're getting 5 or 6 ms delay as function of locking to 144hz refresh rate (?)

[BananaBoat]

Ive just come across this thread i have to say i am very pleased this is now being looked into. It is the single reason why i have stopped playing VP these last few years.

I am happy to test and provide feedback as needed. Toxie i will await the next release and test with hopefully some beneficial feedback.

Thanks to all who have persevered!

Sent from my SM-G935F using Tapatalk

[Ben Logan]

Welcome back, BananaBoat!

[BorgDog]

I just repeated yesterdays tests on my cab with toxies test builds, and got about the same results as Flupper1, 20-25ms less than before, and I noticed no other weird behavior playing several games.  Because I was curious I also ran through a few coil ramp up values just to see how much they effected flipper speed. Each increase of 1 in coil ramp up (from 0 to 1 to 2 to 3) added about 4-6ms of flipper movement time.

[flupper1]

Flupper, do you have a high refresh rate Playfield monitor? Activating Vsync makes my flippers feel laggy with my 60hz Playfield tv, so I'm leaving vsync off for now. Wondering if you're getting 5 or 6 ms delay as function of locking to 144hz refresh rate (?)

Ben, I just have a normal 60hz TV. And I only tested this with the test table.

[Seraph74]

Thanks to everyone for working on this

 

On my cab, i5 / GTX 760 1080p @ 60 hz

 

Can confirm that Toxie's TestBuild of VPX is about 20ms faster using Flupper1's TestTable

 

Intresting tho - playing with the vsync/fps settings in VPX

 

Table runs @ 236 fps  (vsync 0)

 

With vsync at 1 or 60 - have a max of 9 ms

                 at 61         -            -1  ms

        at 0 or 120         -           +10 ms

 

Note:      at 61 TAF showed microstutter. 

Edited by Seraph74, 26 October 2016 - 06:48 AM.