357 replies to this topic

[Ben Logan]

The only setting I hadn't tried was reducing bloom strength to zero (in addition to the rest). Tough to tell, but I think it may have improved things a bit.

Turning off a through e on the list makes a big difference on my machine.

[Drybonz]

Kernel or Voglidicane... did you guys have a chance to test toxie's recommendations, above?

[flupper1]

Here is my addition to this discussion, I think I read the whole thread and this has not yet been mentioned or discussed (I hope). Here it goes:
It could be that the perceived lag is not related to VPM or machine performance, but due to how the VPX flippers rotate/work. I used the default table with some additions to prove this (default table does not have a rom involved):

 
In this picture there are:
- 2 normal bats with coil ramp up set to 0 (to rule that out), controlled by keydown and keyup
- 2 primitive bats also controlled by keydown and keyup
- a measurement of the time it takes for the left prim bat to end angle compared to the normal bat.
- my fps for this setup (583fps) should rule out performance issues
- you can see the difference between the prim bat angle and the normal bat angle, I made this screenshot by simultaneously pressing shift and prtscr)
The difference between the prim bats and the normal bats is that the prim bats do no follow RotateToEnd, but directly jump to the end angle.
The left bat falls back down in sync with the actual flipper, the right bat just jumps back to the start angle in one go (this makes it easier to see the difference).
I marked all the code (all in the beginning of the script):
- '################## is for the added code for the prim bats to work (together with Timer1)
- '## measure code ## can be removed, it is just for the measurement (also remove Timer2 which is set to 1 ms and textbox1/textbox2)
With this setup it is easy to test flipper settings:
- double mass make the delay worse
- improved strength shortens the delay
- etc
If the measurement does not work properly after changing settings, increase the number 0 in line 73 to 1 or 2 or 3 or 4 or .. (at some values for the bats, the end angle for the normals bats is not exactly the same anymore of the prim bats, don't know why).
 
https://mega.nz/#!MIJlnKqY!qiNjm6wgHTHxf-aHYd7V9XoKfDtqRLLEfvvISBmZXbQ
 
And on the reason for this:
The flippers are modelled to be physically exact I guess, but the time it takes to rotate to end is added on top of machine delays (usb, windows, graphics, VPX render pipeline, screen). To be correct: the rotate to end time should be shortened for machine delay. Since many 60Hz TV's already have a lag of 25-60 (?) ms, the delay I am seeing in the screenshot (~40ms) should not be added on top of the machine delay.
 
I have not yet tested how it feels if you make the normal bats invisible, and the prim visible and non collidable. Don't know if you would still feel lag.
 
Hope I am making sense and this adds useful information to the discussion. 

*** edit *** at 7th nov. : this testtable cannot be used anymore (is inaccurate and there is a measurement now in vpx itself), so I removed the link. If you want to know why, read the next 20 or so pages of this thread.

Edited by flupper1, 07 November 2016 - 06:23 AM.

[toxie]

Yes, indeed, also very interesting!

 

Could you do the same experiment for VP9.9.2 maybe? And PM5?

Is there a large difference for these? (just to get some idea if this got worse in VPX)

 

But in general, there has to be some delay for the flippers to rise and fall to the extreme positions, as this is also necessary to do some of the flipper tricks! (its just the question if this is 'too much' in VPX currently)

[flupper1]

It could be that we only need the visual flippers to do this, and the physics flipper can be as is (if not too different in speed). If I test my test table, I can not really see the lag directly (for the left one). But the lag is still there (see the measurement and the screenshot).

[toxie]

Still, would be really interesting what the 'delay' in VP9 and PM5 is in comparison.

[flupper1]

I did a quick check with PM5 and an old version 9.2.1:

- PM5 also shows delay, can also be reduced by tweaking the flipper settings (also ~30ms); I do get a very high FPS (1396fps).

- 9.2.1 shows no difference at all (either 0 or 1 ms)

And to investigate the effect of VPM I added the code to my WIP of Diner (with the rom controlling the normal flippers): delay is 40-50ms (and usually 40ms).

Interestingly not much additional lag effects of that compared to no VPM!

Edited by flupper1, 24 October 2016 - 08:28 PM.

[fuzzel]

hmm nice test table thank you for that The process is the following: first VP calculates the animation of the real flipper and updates the internal currentAngle variable, then a COM request is processed to get the current angle. After that another COM request is processed to the primitive to rotate by that angle and then VP renders the primitive again. I have no clue how fast Windows processes COM requests but I hope it is negligible The rest could be the problem: before VP renders a frame the physics are calculated (ball movement, collision detection and so on) after that the real rendering of the dynamic elements starts and after that the post processing is done and everything starts again. So it can take quite a time until the next calculation of the next currentAngle of the flipper arm is done.

[toxie]

@flupper1: so at least we did not screw up with VPX, and this specific effect is really due to the changed physics code. Thanks!

[vogliadicane]

Kernel or Voglidicane... did you guys have a chance to test toxie's recommendations, above?

I am sorry, sorry, sorry, No. At the moment I am moving my "prototype" VPin to the real cab, so mostly, it is not working. But this is on my list, I promise, I will test this as soon as possible. Sorry for not being helpful now.

[BorgDog]

@Flupper1, @toxie so if I'm reading the code right you are basically measuring the time from when the button is pressed until the flipper is at end correct?  

 

So to add some more data to the testing I added a simplified version of this to the AFM that I've been messing around with that caused me the biggest lag issues (just didn't mess around with the primitive part of it).  Anyway what I recorded was the following:

 

time in ms from button press to flipper at end:

 

with vpm controlling the flipper: 48 to 58 ms, and it mostly just hit those two values not much in between

with vpm bypassed: 29 to 32 ms

 

So I still am definitely seeing a measurable difference with VPM in the flipper controlling mix.

 

Interestingly when I changed the a-e settings toxie posted earlier, I had no difference in the numbers.

 

my simplified code is as below, and commenting out the solcallback:

Sub AFM_KeyUp(ByVal Keycode)
   If keycode = leftflipperkey Then
	maxdelay = 0
	Timer2.enabled = True
	Leftflipper.rotatetoend
   end if
   ...
End Sub

Sub AFM_KeyUp(ByVal Keycode)
  if keycode = leftflipperkey then 
	timer2.enabled = false
	LeftFlipper.rotatetostart
  end If
   ....

dim maxdelay														'## measure code ##

Sub Timer2_timer													'## measure code ##
	If  Leftflipper.CurrentAngle > Leftflipper.EndAngle then maxdelay = maxdelay + 1			'## measure code ##
	Textbox1.text = maxdelay
End Sub	

[Slydog43]

what timer2.interval are you using?  I was working on something similar.  Will show results when I get more data.  Just taking high speed pictures of my hand tapping the flipper button and looking how many frames go by before I see the flipper move.  I definitely see more delay with VPM as expected.   

[BorgDog]

what timer2.interval are you using?  I was working on something similar.  Will show results when I get more data.  Just taking high speed pictures of my hand tapping the flipper button and looking how many frames go by before I see the flipper move.  I definitely see more delay with VPM as expected.   

Interval of 1, copied the timer from fluppers table.

[Ben Logan]

 
But in general, there has to be some delay for the flippers to rise and fall to the extreme positions, as this is also necessary to do some of the flipper tricks! (its just the question if this is 'too much' in VPX currently)

Re: Flipper tricks

I agree with the "fall" part -- that once flipper is fully extended, VPX benefits from a code loop that discriminates between an ultra fast "reflip," (for flick passes, for example) vs a slower reflip that would return flipper to rest and then spring it back up again to full extension. This requires some delay (a small time window during which VP monitors gap between button held-in / re-press) -- otherwise there would be no chance to communicate a low-voltage reflip request to the engine. I realize I'm not saying anything new here! Side note: Believe it or not, TPA's flipper physics on their newer tables feel pretty realistic in this regard (but they're more laggy than ours).

But in my experience, no added delay is ever necessary to move flipper from rest to rise. That should be snappy / low-latency as our digital devices allow, imo.

Flupper and Borg -- great testing! Unless I'm misunderstanding, Flupper's conclusions seem to line-up fairly closely with Noah's (?) Is this correct?

Edited by Ben Logan, 25 October 2016 - 05:42 AM.

[toxie]

 

Interestingly when I changed the a-e settings toxie posted earlier, I had no difference in the numbers.

 

Thats perfectly fine, as these settings only address the gfx driver/card part of the latency.

[toxie]

I just tweaked a constant (that i already flagged as 'make configurable' in my checkout ) that will be there in fuzzels next build, that reduces the delay in the testtable dramatically.

Let me know if this is okay like-is, or if it leads to other sideeffects.

Or wait, here is a testbuild directly

Attached Files

•  VPinballX_test.zip   8.38MB   16 downloads

[flupper1]

Sound great! What is the magical constant? What does it do?

[Kernel]

Gr8 findings flupper1.

 

Kernel or Voglidicane... did you guys have a chance to test toxie's recommendations, above?

 

 

The only setting I hadn't tried was reducing bloom strength to zero (in addition to the rest). Tough to tell, but I think it may have improved things a bit.

 

Same for me. I'll try reducing bloom as soon as I can.

[toxie]

@flupper1: This was put in in PM5, and is related to a special handling for the contact phases EOS and BOS/Park. I tweaked the BOS/Park one, but to be honest i do not understand (yet) why this is even done the way it is, as i think its more of a hack to fix something else. So please test the new build and see if this breaks some flipper behavior/flipper tricks/etc.

In the meantime i'll see if i can find some more time to actually really look into all the code that is influencing the behavior in that phase.

[flupper1]

hmm nice test table thank you for that The process is the following: first VP calculates the animation of the real flipper and updates the internal currentAngle variable, then a COM request is processed to get the current angle. After that another COM request is processed to the primitive to rotate by that angle and then VP renders the primitive again. I have no clue how fast Windows processes COM requests but I hope it is negligible The rest could be the problem: before VP renders a frame the physics are calculated (ball movement, collision detection and so on) after that the real rendering of the dynamic elements starts and after that the post processing is done and everything starts again. So it can take quite a time until the next calculation of the next currentAngle of the flipper arm is done.

If I understand correctly, the physics are calculated realtime based on a fast physics timer ("first VP calculates the animation of the real flipper and updates the internal currentAngle variable"). And then displays the changed flipper rotation whenever the renderpipeline is ready for that ("After that another COM request is processed to the primitive to rotate by that angle and then VP renders the primitive again."). 

Maybe I am not understanding the way it works, but wouldn't be a possible solution/workaround to do the physics calculation for the "rotate to end" not in realtime timerbased, but as fast as possible at the exact time the player pressed a flipper button until fully rotated to end (not timerbased)? That should give you the proper steps in physics of the flipper ball interaction, but a reduced time for that. This is all invisible to the player, but the physics could/should be intact. 

 

About the testbuild: I will check tonight at home, but also very curious to how this behaves on other people's machines ofcourse!