357 replies to this topic

[Ben Logan]

Pretty inspiring findings!

[fuzzel]

FYI: a new build is available with Toxie's latest changes (http://www.vpforums....=35311&p=350690)

[BananaBoat]

Before i go install the latest beta how do i accurately measure the actual flipper delay so that i can compare before and after?

Sent from my SM-G935F using Tapatalk

[toxie]

There are so many components involved that its hard to generalize.

 

My 'fix' you can measure with the table from http://www.vpforums....=36111&p=360947

 

Then there is the no-VPM flipper workaround from http://www.vpforums....=36111&p=359485 and you can meaure it there by also adding some Timer() calls to measure the difference

 

For the rest (USB driver, GFX driver, etc) one would have to install some pretty confusing profiling tools.

[BananaBoat]

Ok so ill start with your fix and revert with results

Sent from my SM-G935F using Tapatalk

[unclewilly]

Ok so I'm still following along. Haven't had time to test due to my 4 year old son.
Is there a concensus as to which code we should use in our vpm tables to give the best end user experience.
Just asking because i have a bad cats update and soon will have a pinball magic release that i would like to add the code to.
But I've been waiting for a solid solution first on this issue

[toxie]

From my understanding:

 

For every machine that has some kind of tilt solenoid or similar, use the de-coupled VP flippers, e.g. no roundtrip VP<->VPM, but directly wired to the key input,

see here for the machines: http://www.vpforums....=36111&p=360623

and here for the code: http://www.vpforums....=36111&p=360658

and use the solenoid to en/disable the VP flippers.

 

If this is not the case for the machine in question, then there is a reasonably simple workaround to disable the VP-flippers (with some minor caveats)

by Knorr here: http://www.vpforums....=36111&p=360571

[BananaBoat]

For my understanding is the latest rev supposed to solve the flipper delay for existing tables?

I tried the test table and it is a vast improvement with anywhere between 4ms to 12ms lag times.
Existing tables still display the cronic flipper lag..

Sent from my SM-G935F using Tapatalk

[toxie]

its not a general fix. it just fixes one component of all these separate issues mentioned in here.

[wrd1972]

Is my thinking here correct?

If a visible VP flipper is used. There is not a lag issue that impacts gameplay.

But if a prim overlay is used. Then there is a lag that impacts gameplay.

 

Is that correct?

[gtxjoe]

I would think with a prim overlay, the ball will still shoot the same.  The VP flipper whether its visible or invisible is what hits the ball.

 

The prim overlay visually may look laggy if the timer used to rotate the primitive is too slow (toxie suggested 8ms timer interval, i believe)

[wrd1972]

I would think with a prim overlay, the ball will still shoot the same.  The VP flipper whether its visible or invisible is what hits the ball.

 

The prim overlay visually may look laggy if the timer used to rotate the primitive is too slow (toxie suggested 8ms timer interval, i believe)

I cant seem to find the timer your speaking to. Can you point me in the direction?

[toxie]

Here: http://www.vpforums....=36111&p=361036

This is about the timer that polls the invisible VP flipper to sync with the visible primitive flipper.

[toxie]

Some updates on the topic:

 

First of all, the lag test table posted in here is flawed in its design, as it actually counts the timer updates to measure time, which is not the actual 'real' time though.

One must use the official VBS Timer function, which again has the problem that it only has a resolution of 1/64th second (although on my machine thats not always true it seems, and the resolution is more fine grained).

 

Then i had a stab at all the timer/physics update code again, which should again improve things a bit.

[Ben Logan]

Thanks so much for your attention to flipper latency, Toxie. Really appreciate it!  

[Slydog43]

WOW, that sounds like your going to continue improving things (as always I guess).  VP Devs ROCK!!!  Toxie can you come up with a better test table?

[toxie]

I also just added a more stable time function to the script functions: SystemTime()

That way one can get a real millisecond precision time.

This one can then be used to measure the difference between things.

[flupper1]

Thanks Toxie! And I did try to use the real timer, which gave me the result you are referring (low res timing). I even thought up a way of measuring total lag using lego mindstorms stuff from my son:

- a lego switch which you push in parallel to the flipper button

- a color sensor which is pointed at the end spot of the uprotated flipper (so the sensor notices what happens at the of the render pipeline, including tv screen lag), with a bright flipper and black background

- the mindstorms computer with a simple program to measure time

However:

I found that the maximum resolution of the mindstorms timer is 1/100ms, so only rough measurements. And second: I do not know if the color sensor has timing issues. So I only did this experiment in my mind...

[fuzzel]

A new beta build is available for testing

[toxie]

And i just added another tweak: The PinMAME timer is now triggered in sync with the FPS that one can reach (actually multiple times per frame update (currently 4x)).

 

So if in addition DJRobX can pull off some more magic on the VPM side, then at least this component will be close-to-optimal then.