357 replies to this topic

[jimmyfingers]

@JF: so i'm still a bit confused. i interpret it though that the current situation is good as-is (with the core.vbs switched to the 1 interval)? as the tap-pass should now solely depend on the coil ramp up vs strength and not the weird delay/bug that was in there before.

but i guess you could also not test the very latest revision yet, which should improve the VP<->VPM turnaround time substantially (e.g. better on the average than the 1 interval). please let me know how this revision works for you if you have some time/motivation for it. THANKS!

There's still 2 different things going on taking away from those flipper tricks / control aspects.  One seemed to be introduced since you sped up the flipper animations / physics and on non-VPM tables or VPM tables with flippers bypassing the VPM calls / returns that revision as when VPM / core.vbs PinMAME timer interval aspects were irrelevant for flipper response, they were not behaving as with going back a few previous versions and were not as controllable for that tap "pass".  The 2nd totally different angle was all introduced from core.vbs as that file when used as one of the latest ones, caused VPM tables to very noticeably fail on the tap pass where they could do so before.  This happened even when going back to an old VPX revision and was shown to be totally about the core.vbs.

 

But there's two separate issues going on, however, the one from the sped up flipper code is going to be harder to test, especially now that it's merged with these other changes you made.  Would be good again to be able to disable those changes you made somehow (around rev2825) for the visual aspects to help isolate as now it can't be removed from the latest syncing of the VPM calls per frame.  But, going back to the older versions and changes before and after that flipper visual speed code change, it appears to be less capable of delicate flipper action.  

 

I'll need to find / spend more time on that aspect and even with testing with this latest version, if the syncing / VPM calls are better and should be the same as with the PinMAMEInterval = 1, but now it's still going to be convoluted because of what it appears the flipper speed code changes showed were also affecting things and being that those are still included in this update.  

 

I can say though that rev2616, with the newer core.vbs with the PinMAMEInterval = 10 (versions before this latest one or two) totally showed problems with VPM tables and tap passes that was resolved by going to an older core.vbs that still had  PinMAMEInterval = 1 (nothing changed for VPX executable or pinmame, just the core.vbs).  But that's only half of it since the flipper speed-up changes have also appeared to play an adverse effect on tricks too.  

 

I get why it's confusing, because it is really It's tough to clearly describe all in forum posts / PMs without some interaction (especially when some testing sessions can be several hours and the nuances / criteria / combination of other aspects fairly involved).  Sometimes why VP get's frustrating because it takes way more time to type it out findings / issues then if people could actually resolve with a voice call / live interaction (for a few reasons).   Maybe we'll take this off-line and on a PM as well if it's confusing you then it's probably confusing everyone else too and I don't want to jam up the thread, however, I do believe we have a potential issue with these relatively recent flipper code changes that on it's own seems to have detracted from flipper subtleness / interaction and is affecting the flipper's initial stroke which is being seen around things like the "tap pass".  But with all these other elements some more verification of that is needed, even if that is focusing on previous builds / revisions to find out where things act different and both with VPM / core.vbs interaction and without (as that is complicating things with it's own changes also affecting the same general flipper quick on / off controls)

[toxie]

due to the suggestions by JF i looked into my flipper-speed-up fix again, and actually it turns out that it basically does -nothing- to the flipper-speed!

what it did was to 'fix' (by a sideeffect) the wrong behavior of the time measurement on the flipper lag test table posted here AND maybe make tap passes harder, so very good investigation here, JF, you're the man!

i'll revert that then.

Edited by toxie, 06 November 2016 - 08:06 PM.

[toxie]

okay, reverted.. let me know guys if you find this now behaving different again (in a bad way)..

in addition i added a new F11/debug output that shows the milliseconds from the keypress of the left key to the beginning of the rotation to the EOS event (using internal counting, to rule out all kinds of scripting side-effects).

Edited by toxie, 06 November 2016 - 08:53 PM.

[toxie]

another interesting fact: i also ported this internal measurement to VP9.9.X and there i have roughly the same internal delays as in VPX, IF one picks similar settings.

with the speed setting suggested by noah i can get 4.2ms in VP9.9.X with the default table, if i use the VPX settings from here (http://www.vpforums....=36111&p=360057) and the latest build, i get 2-7ms!

(in comparison: the default VPX table settings cause 33ms as-is)

[DJRobX]

Just to throw in, I'm working on improving it on the VPM side.  Now that VP is polling VPM more frequently I can get short-term gains without re-engineering things. 

 

I added mid-vsync throttling.    When I first added the ability to return flipper solenoids immediately, I didn't get as much as an improvement as I would have expected.  The reason was that VPM was still rendering a frame, then idling for a long time waiting for the next.   A modern processor can emulate these old CPUs really fast, so the simulation was "bunching up" between vblanks.  VP sent a flipper switch, you'd then have to wait until VPM finished idling before it could possibly respond.   VPM already supports a concept of a "vblank multiplier", so it was surprisingly easy to insert more throttling calls.   This gives us more opportunities to see and respond to a flipper switch.    This seems to have cut down on the variance quite a bit.   Now it seems to hover in the 1-15ms range (down from 1-30ms or so, which is down from up to 38ms before I started returning solenoid states immediately) .  It's still not responding as fast as I think it ought to, but I'll continue to look at different parts of the issue.  

 

I bet the same technique could be used in VP, to intentionally space out the timer intervals, but at least for the time being VP seems to call the VPM timer pretty smoothly from what I saw with Toxie's latest fix (at least on my laptop lol) 

 

Thank you for adding that to the F11 menu, that is SO much better than having to hack the script for tables that I'm trying to measure.  That will help me look at this on my cab where the hardware performs better, and get the debug window latency out of things. 

 

I'm really happy to see this issue being attacked from so many different angles.  Good stuff. 

Edited by DJRobX, 06 November 2016 - 10:27 PM.

[toxie]

indeed!

the thing though is that in VP we cannot as easily increase the rate for timer updates, as these can change the physics state and other states, which are currently not double-buffered, so weird things could happen during the rendering then.

[DJRobX]

From what I see now, VPM itself, and possibly the ROM code is now the weak link.    But all the improvements we've done have the RTT under 10ms most of the time now, sometimes 2-5ms, which is pretty good.   If I had the equipment, I'd measure my FG to see what the actual hardware delay is.  

Edited by DJRobX, 07 November 2016 - 06:02 AM.

[Ben Logan]

DJRobx, thanks for spending so much time and energy on this improvement effort. Totally appreciated.

[flupper1]

Since reality caught up with my lag-test-table, I removed it (not downloadable anymore), to avoid further confusion. At least it triggered some new investigation and subsequently big improvements!

[mpad]

Holy Sh***!
You guy's are unstoppable.
Fun thread!

[chokeee]

Forgive my ignorance but I would just like to confirm my observations. I can feel Flipper lag only in True Full Screen mode but I dont feel it in "old full screen". So this is the point of this topic? Or maybe we are talking about the lag in each of the options?

Edited by chokeee, 08 November 2016 - 08:12 AM.

[toxie]

There are many many different parts of the equation. True fullscreen vs old fullscreen is one of them, and this depends on OS, gfx driver, and their respective settings.

This thread is mainly about investigating the VPM<->VP communication part (so the emulation and overhead there), and the internal VP physics engine and timer processing part (so far).

okay, reverted.. let me know guys if you find this now behaving different again (in a bad way)..

in addition i added a new F11/debug output that shows the milliseconds from the keypress of the left key to the beginning of the rotation to the EOS event (using internal counting, to rule out all kinds of scripting side-effects).

 

there is now an official build that has these two changes, btw: http://www.vpforums....=35311&p=362274

[paulstevens]

For what it's worth...I hooked an oscilloscope to Monster Bash to measure WPC-95 latency from when the flipper opto board opto goes low (cabinet button pressed) to when the flipper solenoid drive signal goes low (flipper coil becomes energized). 

 

Range of time:  0.46mS - 4.14mS.  Both of those measurements are one-offs that I caught when repeatedly pressing the flipper button looking for outliers.

 

Several were slightly less than 1mS and others were slightly less than 4mS, but the vast majority were in the 2.54mS - 3.34mS range.

 

This suggests that at a minimum the USB scanning interval on the PC should be increased to 1kHz / 1mS discussed elsewhere.  If the 125Hz polling rate is kept, there could be as much as 8mS delay before the keypress is even detected.

 

(I did not yet measure cabinet button press to when the EOS switch is closed signifying flipper at full extension, only to when the flipper coil begins to be energized.)

[Ben Logan]

PaulStevens -- great to have you in the conversation! Nice to have some data to support the mere feeling that real pinball is snappier in terms of flipper response time. Thanks so much for taking the time to make some measurements. It's inspiring to see so many talented folks take an interest in moving this conversation forward, from such a variety of perspectives!

[paulstevens]

Okay my setup:  i5-4690K, GTX960, drivers 375.95, vsync OFF in VP and NCP, VPX 10.2 beta 2847, VPM beta 2.8.

43" LG 1080p 60Hz playfield monitor, 24" backglass monitor (1080p 60hz)

test table:  VPX AFM by Groni.  VP9X AFM 2.4

true full screen mode.  2nd monitor for b2s backglass

USB keyboard input (my keyboard is not overclockable - still at 125Hz even with faster driver)

 

Overall I think I have the flipper lag as low as I can get it on my setup.  I've tried the bypassing VPM code snippets in VPX.  I've used Noah's flipper settings on VP9.  They feel about the same.  Noah's settings in VP9 (0.955 speed setting) are pretty good, but there is still a lag I feel from pressing the shift key to the ball flipping.  IN the end, it is either my hardware setup (usb keyboard, display lag of 30mS) or VP9/VPX settings that will have some inherent lag that at least I am sensitive to.  I get a bit used to it but know it is not right.

 

Using F11 on VPX, left flipper delay is generaly high teens or low 20s mS delay,  occassionally as low as 7.8mS.  WPC delay is at worst 4mS, so the VPX delay itself is slower than WPC (and this does not take into account VPM delays).  FPS = 150 (no vsync).

 

Please - don't construe this as complaining - I am growing more and more fond of the incredible work everyone is doing.  These are just observations.

 

I think in my case I need to try a keyboard encoder plus leaf switches and see how it feels.  My display lag is 30mS - nothing I can do about that.

 

BTW the 0.7 and 10000 setting with a EOSTorque of 0.25 on AfM Groni is about as fast as I could get things, feels pretty good, no wierd ball behavior.  That was without VPX bypassing VPM.  Bypassing VPM it felt about the same.  So, I like those settings for me.

 

Anything else I can investigate?

 

Thanks for all the work.

Edited by paulstevens, 28 November 2016 - 12:18 AM.

[Drybonz]

Probably the display lag, Paul... like you said... nothing you can do about that except upgrade.  If you have access to a fast computer monitor or another TV you could plug it in just as a comparison.

[paulstevens]

switched to 24" Dell 1080P computer monitor, HDMI input.  MEasured lag at 11.7ms (43" LG TV measured 36.7mS)

 

Surprisingly little difference to my perception of flipper lag from SHIFT key press to ball flipping.

 

This is very hard and somewhat frustrating because the "feel" is completely subjective.  I can measure the display lag with the leobodnar tool - objective measurement.  But I cannot measure the "feel" from shiftkeypress to when ball flips.  F11 is a relative indicator between changing VPX settings, but even it does not begin to register until whenever it detects the keypress.

 

I would like to try one of Noah's machines one day, totally optimized, so I can get a "feel" for what it is supposed to be.  I may just be too picky or sensitive.

 

One interesting observation though - moving all the B2S* files out of the "Tables" folder, AfM Groni would complain about missing the B2Sbackglass.exe files, but the flipper lag "seemed" less pronounced.  Still there, but seemingly less so than with B2S running.

 

I also tried BadCats by Unclewilly w/o B2S.  It seemed better still, more responsive than AfM (even with VPM flipper calls bypassed) but again still just a bit off.

 

I'm still new to VPX - there is probably a way to disable completely B2S from VPX so it does not even look for it .  I didnt figure that out quickly so I just moved the files out of the tables folder.

 

My wife says I'm never satisfied - maybe she's right on this one.  It's really good but just not quite all the way there.

[Drybonz]

Is the Dell a 60hz monitor?  If so, you wouldn't see much difference.

[paulstevens]

Yes - both monitors are 60Hz.

 

Why would you expect there not to be much difference due to both being 60Hz monitors?  The display lag difference is 25mS, so I expected a difference due to that (which I can observe on Fathom and Bad Cats to some extent, not really so on AfM).

 

VSYNC is off, btw.

Edited by paulstevens, 28 November 2016 - 04:47 AM.

[Ben Logan]

Before I built my cab I threw together a quick controller with leaf switches, a u-hid board, and a jewelry box. The difference in feel was night and day compared to playing VP with a QWERTY keyboard. I totally recommmend it as a testing rig, Paul. Plus, it's a fun and relatively cheap little project. All the parts were around 50 bucks total.

Edited by Ben Logan, 28 November 2016 - 04:57 AM.