357 replies to this topic

[toxie]

 

Plus: If VP9 runs even faster than VPX (which i assume) on your system and you do not use VSync, then all the overhead and delays of VP itself (and its interactions with the drivers and OS) are basically subtracted from the equation.

Or do you also limit VP9 to the same framerates?

Exactly. I can exclude hardware related lag (monitor, input) and other delays involving OS/Drivers..

I don't limit VP9 because is super smooth even without v-sync enabled. No need to enable it.

With VPX I've tryied v-sync on 1 (60 FPS - heavy lag. Unplayable), v-sync on 2 or 120 (much better but LAG still there) and v-sync OFF (same as 120, but with stutters).

 

 

Okay, that explains it then.

 

As VPX is overall slower/lower FPS, this factor must be added here in addition to the hardware&driver "delays" mentioned above.

Maybe you could also fool around though with the fast sync option i mentioned above (so leave vysnc turned off in VP itself, and just use the NVIDIA setting), which will give you the benefits of smooth vsync, but (usually) not more lag.

[lodger]

One thing that I'm not sure about is the idea that real machines have no latency between button and flipper. I think that there is definitely some there, especially when playing on older em style games. Does anyone know if there is any correlation between solenoid strength and latency? 

[Ben Logan]

I looked into fast Vsync. Sounds like the absolutely fastest option (for those who want flipper speed above all else) is to not use Vsync -- even the fast option introduces the tiniest bit of lag. I'm on the older NVidia driver with my 750ti. It doesn't have the fast Vsync option as far as I can tell. I'm afraid to update the driver because everything is running stable for the moment!

I've dialed all visual settings way down in VP video options, largely as an experiment. Disabled desktop composition as well. I'm getting just a bit of tearing and a bit of micro ball stutter, but the flippers have never been snappier! The difference is huge, probably because I was going for maximum visual eye candy before. When VP10 was in testing, these settings made tables near unplayable in terms of stutter. It seems now that the engine (and perhaps table building in VP10 too) has been streamlined to the point that they're a viable option. Lots more flexibility to steer hard either way: Better graphics vs Better performance.

For now I'm happy with the trade off. Shots feel even more accurate. I can make upper flipper shots that were especially hard to time (at least I can properly blame myself for missing them now!). I set FPS limit to 120.

Faster graphics card and high refresh rate monitor are on my list. By the time I have saved up enough money, the technology will have seriously advanced. Bright future for VP!

[gtxjoe]

Here was jimmyfingers discussion on possible USB polling increases. http://www.vpforums....showtopic=29207

 

The other thing that has been done in vPinmame table scripts to improve flipper response time is to rotate the flipper immediately when the flipper button is pressed, instead of waiting for the flipper button press to be passed to vpinmame and then vpinmame to activate the rom flipper solenoid and then VP rotates the flipper.  This can introduce as much as 30msec lag.  EM tables won't have this delay as vpinmame is not used

 

Here are some example timings of the delay

38582.59 sec: Flipper button pressed

38582.62: Flipper Solenoid triggered 27.34375 msec later

38582.89 sec: Flipper button pressed

38582.91: Flipper Solenoid triggered 11.71875 msec later

38583.2 sec: Flipper button pressed

38583.21: Flipper Solenoid triggered 15.625 msec later

38583.49 sec: Flipper button pressed

38583.51: Flipper Solenoid triggered 15.625 msec later

38583.83 sec: Flipper button pressed

38583.85: Flipper Solenoid triggered 15.625 msec later

38584.24 sec: Flipper button pressed

38584.27: Flipper Solenoid triggered 27.34375 msec later

38584.55 sec: Flipper button pressed

38584.57: Flipper Solenoid triggered 15.625 msec later

38584.85 sec: Flipper button pressed

38584.87: Flipper Solenoid triggered 15.625 msec later

 

 

You can do this by adding this to the top of the  keydown routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToEnd
	if keycode = RightFlipperKey Then rightflipper.RotateToEnd

and this to the top of the keyup routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToStart
	if keycode = RightFlipperKey Then rightflipper.RotateToStart

The side effect though is that the flippers will always be active even when the game is not started or is tilted

[toxie]

Also it could be that newer graphics card drivers in general feature less lag, due to all the improvements that happened for VR.

But i never verified this for VP, could well be that this is not the case here, as its still based on DX9.

@gtxjoe: Excellent point. I constantly forget about this one. There should be some way to also get this improved, but so far, i also do not know how yet.

[toxie]

Quick idea to improve gtxjoe's workaround:

 

What if one would wire the flipperkeys to the flippers directly (as he did in his script example), BUT had a timer in addition that would correct the rotatetoend/rotatetostart if the solenoid was actually not fired by VPM later-on? (so that one would always get perfect response during gameplay, but could not move the flippers if not in gameplay (maybe they would move a tiny bit, but maybe it would not even be visible??))

The sound, DOF, etc could still be wired to the solenoid from VPM, as there the latency should not matter that much?

 

Some VP script/table wizard up for this experiment?

[Drybonz]

 

Higher frequency display makes a huge difference.  I can play on my 144hz monitor, then compare to my old 60hz monitor and everything is laggy and choppy... not extreme, but when you compare the two you can really tell the difference.  I would not be able to go back to any kind of gaming on a 60hz monitor.  The monitor makes more of a difference than we generally admit.

 

What size and make & model monitor are you using?

 

 

I am using a 27" 144hz computer gaming monitor (you can see my setup here if you like:  http://www.vpforums....0&hl=+desk +cab).  Because I'm using a gaming monitor designed for high speed 3D pc games (think Call of Duty, etc) the performance is good... but that is where it gets tricky for everyone  with a cab that needs a large TV monitor.  There are different things to consider.  I can connect my monitor via DVI or Display Port which support higher refresh rate... many TV's (mostly the cheaper ones unfortunately) only have HDMI connections, which cap off refresh at 60.  Many TV's get around this by having a bit of a 120hz "hack".  When you are shopping for a TV you want to distinguish between 120hz and "true 120hz", and you also want to consider how it will connect to your graphics card (DVI, HDMI... do any TV's have Display Port?  I don't know).   Here's an article I just found while I was looking around on this subject (please, do not try this stuff if you don't know what you are doing)  http://www.blurbuste...120hz-pc-to-tv/

 

So, basically what I'm saying is I can't help you too much if you need a large TV for a cab... you will have to do a bit of research.  As it stands most people buy the cheapest, largest TV they can find and end up with a 60hz HDMI only model.  There are other options if you feel like reading up on it and looking at some customer reviews, and of course cost becomes a factor.

 

For guys that are using a rotating PC gaming monitor, like me, I can tell you what I'm using.  Both my monitors are 144hz gaming monitors.  The top one is a Benq 24" XL2411 (obviously, you don't need the high quality just for the backglass monitor, but I like that they are matched and I use it for other stuff).  The bottom one is an Acer 27" GN276HL.  The Acer I bought, specifically, so that I could upgrade my PF monitor from 24" to 27".  At the time I bought it (this summer some time) it was the best value vs. performance I could find.  I also use it for PC gaming and it is great.  Neither of my monitors have Gsync, which is a very nice feature that controls vsyncing via hardware instead of software so you get the benefits of vsync with no lag.  That feature will bump you up into another price bracket.

 

So, I really don't know that much about this stuff, but maybe some of that helps head you in some direction.  I always recommend reading up on products before buying something expensive.

Edited by Drybonz, 12 October 2016 - 04:51 PM.

[Ben Logan]

 

The other thing that has been done in vPinmame table scripts to improve flipper response time is to rotate the flipper immediately when the flipper button is pressed

 

You can do this by adding this to the top of the  keydown routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToEnd
	if keycode = RightFlipperKey Then rightflipper.RotateToEnd

and this to the top of the keyup routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToStart
	if keycode = RightFlipperKey Then rightflipper.RotateToStart

The side effect though is that the flippers will always be active even when the game is not started or is tilted

 

 

Awesome! I'll try it. Thanks, gtxjoe!  I miss jimmyfingers' input on this kind of thread. That guy was passionate about flipper physics / latency. 

 

EDIT: Tried adding this code to Super Mario Bros VPX (super beautiful, but somehow one of the more flipper-lagging tables on my machine). Holy smokes! This code works wonders for eliminating flipper lag. Totally recommend trying it, if you're  interested!

 

This little gem honestly makes my day. Thanks again gtxjoe!

 

Quick idea to improve gtxjoe's workaround:

 

What if one would wire the flipperkeys to the flippers directly (as he did in his script example), BUT had a timer in addition that would correct the rotatetoend/rotatetostart if the solenoid was actually not fired by VPM later-on? (so that one would always get perfect response during gameplay, but could not move the flippers if not in gameplay (maybe they would move a tiny bit, but maybe it would not even be visible??))

The sound, DOF, etc could still be wired to the solenoid from VPM, as there the latency should not matter that much?

 

Some VP script/table wizard up for this experiment?

 

Sounds brilliant, Toxie. Creative idea. 

 

___________

 

Drybonz, 

 

Thanks for all the hardware specific info. I'm definitely in the cheap TV / HDMI only camp at the moment. I'm bookmarking your post for when it comes time to do some shopping a year or so from now.

Edited by Ben Logan, 12 October 2016 - 09:39 PM.

[nFozzy]

Has anyone had any luck with fast sync in VP10? Seems crashy as hell

[BorgDog]

 

 

The other thing that has been done in vPinmame table scripts to improve flipper response time is to rotate the flipper immediately when the flipper button is pressed

 

You can do this by adding this to the top of the  keydown routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToEnd
	if keycode = RightFlipperKey Then rightflipper.RotateToEnd

and this to the top of the keyup routine

	if keycode = LeftFlipperKey Then leftflipper.RotateToStart
	if keycode = RightFlipperKey Then rightflipper.RotateToStart

 

EDIT: Tried adding this code to Super Mario Bros VPX (super beautiful, but somehow one of the more flipper-lagging tables on my machine). Holy smokes! This code works wonders for eliminating flipper lag. Totally recommend trying it, if you're  interested!

 

 

 

 

So that would point to vpinmame as the lag culprit.....?

 

 

Has anyone had any luck with fast sync in VP10? Seems crashy as hell

 

Tried it out for a bit on my cab, seemed to work fine but only played a few games.  Latest 10.2 beta in forced exclusive full screen, latest nVidea drivers.  Did not notice any huge difference though in flipper or table responsiveness. Was playing BOP beta and one of my em's.

[DJRobX]

Given that VP could run extremely fast and using something like NVIDIAs Fast (V)Sync (https://www.reddit.c...cial_fast_sync/) that decouples the engine/rendering from the actual display

OR that one turns off VSync completely (either NVIDIA control panel or in VP itself)

AND that one fools around with the "Maximum Pre-Rendered Frames" in either VP or the NVIDIA control panel (lowest can be better, but must not be overall, only testing will tell you, see for example here: https://www.reddit.c...x_prerendered/)

one will still face aboves issues:

 

So to do some math for the lowest/ideal world one can get at the moment:

a) ~8ms (USB = 125Hz)

b) ~17ms (TV = 60Hz, not counting that a lot of current TVs will add one additional frame at least of post-processing/display buffering, e.g. overall ~33ms or even more)

c) ~17ms

 

With new/non-existing hardware/tweaked settings:

a) ~1ms (USB = 1000Hz)

b) ~8ms (TV = 120Hz, with a CRT-style direct output of the image)

c) ~8ms (most likely even less when in a VRish mode)

 

now compare that to the close to 0ms lag of a real pinball machine.  :/

 

Don't forget to add the VPM latency.   The input currently goes into the ROM during the VBLANK period.    Output probably then comes at the next VBLANK period (60hz, not tied to actual vsync). 

 

At least with that unspeakable filthy machine I've been working a lot on lately, there's up to 34ms of latency between the time you press the button, the time it's received by the input handler, and the next vblank period when solenoid output is refreshed.    We should look into pulling/pushing those values immediately when the ROM requests and sets them instead, at least for flippers.   The ROM is checking way more frequently than 60hz. 

Edited by DJRobX, 12 October 2016 - 10:36 PM.

[toxie]

Thats where my tweak comes in for gtxjoes's suggestion: By eliminating the VPM turnaround completely, VPM would not play a role at all anymore. One would just correct all the cases where the flippers should not move at all 'afterwards'. So they would move a bit if they should not be allowed to move, but then again this case should not matter at all for 99% of the users.

[gtxjoe]

Quick idea to improve gtxjoe's workaround:

 

What if one would wire the flipperkeys to the flippers directly (as he did in his script example), BUT had a timer in addition that would correct the rotatetoend/rotatetostart if the solenoid was actually not fired by VPM later-on? (so that one would always get perfect response during gameplay, but could not move the flippers if not in gameplay (maybe they would move a tiny bit, but maybe it would not even be visible??))

The sound, DOF, etc could still be wired to the solenoid from VPM, as there the latency should not matter that much?

 

Some VP script/table wizard up for this experiment?

 

With VPX, you can easily check if there are active balls on the playfield.  That could be used to decide if the flipper should be activated early by the keydown routine, so the changes become:

Top of the keydown routine

	if (uBound(GetBalls)> 0 and (keycode = LeftFlipperKey)) Then leftflipper.RotateToEnd
	if (uBound(GetBalls)> 0 and (keycode = RightFlipperKey)) Then rightflipper.RotateToEnd

and this to the top of the keyup routine

if keycode = LeftFlipperKey Then leftflipper.RotateToStart
if keycode = RightFlipperKey Then rightflipper.RotateToStart

Note: there are some tables that have captive balls or balls on the table to simulate primitive objects getting nudged so in some cases it has to be adjusted slightly, uBound(GetBalls)> x, where x = number of balls on the table when table is not running

[toxie]

True. Sometimes the simple solutions are really the best (e.g. we developers tend to think too complicated ). Thanks a lot!

 

Minor nitpicking: It would still not be true to the real table all the time (some ROM settings allow to flip for example during bonus count, etc).

Edited by toxie, 12 October 2016 - 11:50 PM.

[Drybonz]

Has anyone had any luck with fast sync in VP10? Seems crashy as hell

 

I tried it a couple times, before and after it was in the official nvidia drivers.  I didn't see too much benefit, but it didn't crash or give me too many problems in VPX.  However, it did seem to cause a whole lot of problems in other 3D games and media apps.  I decided to let it develop for a while and I will try it again later.

[BorgDog]

gtxjoe, I'm guessing there is a way to read Tilt as well so the flippers would not activate when tilted.

 

Or can you tell when the game is started and when it ends and only have them active then?

Edited by BorgDog, 13 October 2016 - 12:30 AM.

[nFozzy]

gtxjoe, I'm guessing there is a way to read Tilt as well so the flippers would not activate when tilted.

 

Or can you tell when the game is started and when it ends and only have them active then?

You can have a timer uses the flipper switches as call-and-response, but it gets tricky if there's any lane change features.

 

Also some games will kill the solenoids after 10 minutes or so of rapid use to prevent them from overheating, Twilight Zone does this. I did get Terminator 2 working almost perfectly except for high score name entry. JimmyFingers says he has scripts that will work for games with dual lane change.

 

I don't think I've tried quickly rotating flippers back to start though

Edited by nFozzy, 13 October 2016 - 12:45 AM.

[Ben Logan]

I love that Toxie and you guys are talking about sophisticated ways to steer around VPM related lag that preserve tilt and rom flipper freezes following drain. That said. I'm blown away that cutting and pasting a few simple lines of code into the key up key down section has such an amazingly positive impact on gameplay for now.

This coupled with nFozzized flipper code has VP feeling startlingly close to the real thing flipper physics-wise. Love it!

[gtxjoe]

True. Sometimes the simple solutions are really the best (e.g. we developers tend to think too complicated ). Thanks a lot!

 

Minor nitpicking: It would still not be true to the real table all the time (some ROM settings allow to flip for example during bonus count, etc).

 

About flipper support during bonus count, in between balls, I think the table will behave correctly.  If there is no ball on the table, the new immediate keydown flipper rotation won't get triggered, but the slowere vpinmame flipper solenoid call/solenoid flipper action should kick in 11-30 ms later

 

As for monitoring tilt, I don't recall how to, but I think there are tables that do this, so hopefully someone can chime in here

Edited by gtxjoe, 13 October 2016 - 01:48 AM.

[DJRobX]

Quick idea to improve gtxjoe's workaround:

 

What if one would wire the flipperkeys to the flippers directly (as he did in his script example), BUT had a timer in addition that would correct the rotatetoend/rotatetostart if the solenoid was actually not fired by VPM later-on? (so that one would always get perfect response during gameplay, but could not move the flippers if not in gameplay (maybe they would move a tiny bit, but maybe it would not even be visible??))

The sound, DOF, etc could still be wired to the solenoid from VPM, as there the latency should not matter that much?

 

Some VP script/table wizard up for this experiment?

 

I thought of that too.  Should work, although I think it could get a bit weird for sounds/DOF contactors in some cases.    Lets say, for example, the game has a video mode or a screen where you pick something on the DMD.   You REALLY don't want the flippers moving or sounds/contactors firing in that case.   You could associate the sounds/contactors with the VPM output, but that feedback is really critical to make it feel like the latency is gone.

 

Speeding up VPM would be easier I think.   It's really not hard to tell when the ROM is looking for input, or writing to a solenoid state.   I just would want to make it optional, because it probably will come with some performance penalty.    But on today's machines the performance loss is probably not even going to be that noticeable compared to the gain of the increased responsiveness.

 

In "that evil machine" I can cut out half the latency by just moving a single line of code. 

Edited by DJRobX, 13 October 2016 - 05:04 AM.