740 replies to this topic

[DJRobX]

 

 

If Vsync = 1 and Pre =1 in video settings Left Flipper rotate averages 18ms and EOS averages 34ms.

If Vsync = 0 and Pre = 0 in video settings Left Flipper rotate averages 5.4ms and EOS averages 16ms.

 

Expected behaviour. Vsync = 1 (enabled) always increases delay/latency vs Vsync = 0 (disabled). I wouldn't worry about the numbers and just focus on playing cause 18ms is low enough that you won't notice a perceivable delay between pushing the button and the flipper reacting. 50-100ms, you might start to notice.

 

 

An increase is expected but that delta seems a bit too high to me, unless the video card is rendering at something super fast like 150+fps (in which case NVidia's "fast vsync" option would be worth looking into).    Which table are you doing this test with?   What framerate do you get with vsync = 0?
 

Edited by DJRobX, 04 November 2017 - 04:36 PM.

[Reaper802]

Those numbers were taken using the newest Scared Stiff.

 

With Vsync off I get well above 100 fps until a flashing effect happens.  It's really noticeable on a table like AFM.  When you hit the saucer it does the crazy flashing strobe effect and lags like crazy.

Edited by Reaper802, 04 November 2017 - 05:12 PM.

[bassgeige]

Out of interest due to the same feeling in AFM while editing a dB2S.

 

Is anyone able to play AFM http://www.vpforums....&showfile=11603

or http://www.vpforums....&showfile=11702

or http://www.vpforums....&showfile=11665
together with this dB2S http://www.vpforums....&showfile=13109

without a heavy stutter after hitting the middle saucer?

 

Preferred together with fast timing:  Timings.PNG   3.72KB   15 downloads

Edited by bassgeige, 04 November 2017 - 05:31 PM.

[DJRobX]

I play the Groni version on an underpowered GTX960 in 4k, no saucer lag at all.    I had a different B2S that was much smaller.   I "upgraded" to the version you linked to.  Saucer destruction is still as smooth as silk.

 

That said, I used to always have problems with certain DirectB2S files slowing my tables down.   I used to sometimes have to either find different .directb2s files that took less resources, or I'd just give up and use a static image.     Until I upgraded to Windows 10.    Since that switch, the B2S that's in use never seems to impact VP at all.    

[xenonph]

When I use dB2S backglass files that are huge in size, Say over 50MB,  I also get the stutter.

Only with the huge file sized dB2S backglasses.

The rest have no problem.

I am using one monitor to show both dB2S backglass and table on same screen.

This problem has been there for me for a long time. (So I don't think it is something new that was changed with new version of VP.)

And thanks for the work you guys do for us!! It is appreciated!!

Carry on.

[nFozzy]

Noticed something strange today in regards to Vsync and Pre-rendered frames vs. Left Flipper rotate and EOS timing values provided via F11:

 

If Vsync = 1 and Pre =1 in video settings Left Flipper rotate averages 18ms and EOS averages 34ms.

 

If Vsync = 0 and Pre = 0 in video settings Left Flipper rotate averages 5.4ms and EOS averages 16ms.

 

Why would these settings add 3 times more flipper lag on rotation and double EOS timing?

 

I'd love to run with Vsync = 0 and Pre = 0 for the reduced lag but many tables stutter badly with those video settings.  That is using a 980Ti at 4K resolution on the playfield.  Also driving a 720P backglass and the DMD monitor.

 

Is this expected behavior or is it a bug?

Lag is unavoidable because the roundtrip between the emulated code and VPX. The discrepancy is because VP10 handles solenoid updates every rendered frame (-1 timer interval on pinmametimer) and therefore will update faster at higher framerates. Good for performance, but not great for setups running at 60fps/vsync.

 

Wouldn't an interval of 1 make more sense for faster flipper updates? Looks like at 1 the response is below 17ms like 90% of the time, but sometimes it's totally instant (on my i5 machine anyway)... maybe we could add lag here and there to get a highly consistent 1-frame flipper response.

Edited by nFozzy, 04 November 2017 - 11:37 PM.

[bassgeige]

I play the Groni version on an underpowered GTX960 in 4k, no saucer lag at all.    I had a different B2S that was much smaller.   I "upgraded" to the version you linked to.  Saucer destruction is still as smooth as silk.

 

That said, I used to always have problems with certain DirectB2S files slowing my tables down.   I used to sometimes have to either find different .directb2s files that took less resources, or I'd just give up and use a static image.     Until I upgraded to Windows 10.    Since that switch, the B2S that's in use never seems to impact VP at all.    

 

That is very interesting! Do you use two 1920 x 1080 monitors together with a pindmd and pinled?

Which CPU and how much RAM do you use?

[bassgeige]

Here you can see what I can see with the following table and db2s combination:

https://youtu.be/WIme6hHKXLQ

 

http://www.vpforums....&showfile=11603

http://www.vpforums....&showfile=13109

 

Settings used:

 

 settings.PNG   37.43KB   14 downloads

 

 

I like to see if there is a solution to see no stutter. (Pindmd and pinled, Windows 10 64bit, latest drivers, slightly overclocked Intel 2600k, two last year Nvidia GPUs in none sli with two monitors 1920 x 1080, (D:) visual pinball SSD and 16 GB RAM, no problems with latest 3DMark.) If for example the older Mainboard and RAM and CPU combination is the problem I know what to do.

Edited by bassgeige, 05 November 2017 - 10:02 AM.

[fuzzel]

I fear that the bottleneck here is the COM interface where everything is communicating with each other. I can't say something how pindmd is working but if a lot of lights have to be handled the overhead is quite high.
I guess we can't do much about that other than integrate db2s into VPX, but that needs some developing time to do it right.
A faster CPU together either faster RAM will help here until we developed an alternative.

[bassgeige]

DJRobX does seem to have a better combination. Maybe he can help me with a few more hardware details. I am very happy with every visual pinball detail and for me it is only interesting to see if for example newer hardware helps or maybe others found better solutions with settings I do not know. For me there is also no need to rush since everything does need its time to improve.

I think it is probably interesting for more players to compare and also may help us to understand software and hardware interactions more precise.

[Rajo Joey]

I've played all three tables with your backglass and no stutter. All tables are running smooth.

Win10 64b, GeForce 1060 6GB, 16 GB RAM, Intel i6700 k.

Backglass with 1600x1200.

 2017-11-05 11_51_12-Video Options.png   28.02KB   22 downloads

Edited by Joey2001, 05 November 2017 - 10:52 AM.

[bassgeige]

I've played all three tables with your backglass and no stutter. All tables are running smooth.
Win10 64b, GeForce 1060 6GB, 16 GB RAM, Intel i6700 k.
Backglass with 1600x1200.
2017-11-05 11_51_12-Video Options.png

Great news! That does maybe mean that the COM interface is not a big bottleneck. For me it does mean that the dB2S does have more future potential too since it could be my CPU, RAM, mainboard is a factor to think about an upgrade. How do players with better hardware than mine and also a pindmd see it? Do you see the same stuttering as in the video shown? Please help to clarify this subject too. Thanks!

Edited by bassgeige, 05 November 2017 - 11:19 AM.

[nFozzy]

 

Noticed something strange today in regards to Vsync and Pre-rendered frames vs. Left Flipper rotate and EOS timing values provided via F11:

 

If Vsync = 1 and Pre =1 in video settings Left Flipper rotate averages 18ms and EOS averages 34ms.

 

If Vsync = 0 and Pre = 0 in video settings Left Flipper rotate averages 5.4ms and EOS averages 16ms.

 

Why would these settings add 3 times more flipper lag on rotation and double EOS timing?

 

I'd love to run with Vsync = 0 and Pre = 0 for the reduced lag but many tables stutter badly with those video settings.  That is using a 980Ti at 4K resolution on the playfield.  Also driving a 720P backglass and the DMD monitor.

 

Is this expected behavior or is it a bug?

Lag is unavoidable because the roundtrip between the emulated code and VPX. The discrepancy is because VP10 handles solenoid updates every rendered frame (-1 timer interval on pinmametimer) and therefore will update faster at higher framerates. Good for performance, but not great for setups running at 60fps/vsync.

 

Wouldn't an interval of 1 make more sense for faster flipper updates? Looks like at 1 the response is below 17ms like 90% of the time, but sometimes it's totally instant (on my i5 machine anyway)... maybe we could add lag here and there to get a highly consistent 1-frame flipper response.

 

Maybe setting up UseSolenoids in core.vbs to update solenoids on a separate, faster timer would be a worthwhile improvement? I made this core.vbs mod, it's kind of goofy, but it wouldn't require any table modifications.

https://pastebin.com/VFFxNSpd

Seem to increase response time at lower framerates, although it's still has some inconsistency.

[fuzzel]

Ok good to here that you found a solution. Sup now please back to topic

[DJRobX]

I fear that the bottleneck here is the COM interface where everything is communicating with each other. I can't say something how pindmd is working but if a lot of lights have to be handled the overhead is quite high.
I guess we can't do much about that other than integrate db2s into VPX, but that needs some developing time to do it right.
A faster CPU together either faster RAM will help here until we developed an alternative.

 

Yeah ... when I had this problem it was very perplexing.    The performance dip was always directly attributed to the .directb2s file that's in use.   But there was seemingly no correlation on the complexity of .directb2s file and the stutter.   Scared stiff with its spinning spider was no problem at all, but some practically static backglasses with almost no animation would cause huge lag.   But switch it out with a different one, and then it was magically fine?! 

When the B2S source finally came out what I learned about its inner workings made this even more surprising - when you use it in EXE mode, the B2S EXE is a completely separate process, isolated by a registry entry.    When the table changes a solenoid or light, all the COM server does is update a registry key.  The EXE process polls this key and reacts to the changed bits accordingly.   So the com server's behavior is always the same regardless of B2S backglass complexity.    

I was curious to dig into this further, but as mentioned, after the upgrade to Windows 10, the issue vanished completely.  Despite having a video card that's barely scrapes by 4k demands, this B2S that causes problems for bassgeige is no sweat now.   In fact I recently went through and re-enabled all of the directb2s files that I had disabled due to performance degradation.   Not a single hint of performance change with them on now.

 

My sistem is a Ryzen 1300X with 8gb RAM, GTX 960, single stick of RAM (should fix that).    Backglass is 1920x1080, DMD monitor is 1280x768, and playfield 3840x2160, all on the same card. 

Edited by DJRobX, 05 November 2017 - 05:26 PM.

[JSpradlin]

I started another thread about an error I was having after updating to the latest beta of VPX4 (v3242). I was trying to run some newly updated/released tables and some worked perfectly fine, but there were some were causing a strange error. Two of the tables in question were Class of 1812 by TT & Ninuzzu and Cyclone by Sliderpoint. Both of the tables were downloaded from other sites (not sure that really matters). The BG and DMD would load, but as the table neared the end of loading an error window would display. The text in the error window simply said 'plop' and nothing else. Other tables like Pinball Champ '82, recently released here by 32assassin, loaded fine. 

 

This error occured when running the tables directly from VPX, and I had to kill the program in Task Manager to get out. The same tables with this beta version (v3242) of VPX ran without error on my less capable test system. 

 

The reason I am posting this here is that I was able to copy the old VPX4 executable back and the tables ran fine. I'm not exactly sure which version the old one was, but it was one of the previously released betas. When I copied it back, I only copied back the executable. The additional files such as scripts and dll files were still from the latest beta download. I'm fine running an older beta for the time being, but I thought this information might help fix a potential problem.

[fuzzel]

Please redownload the latest VPX again. The plop message was a debug message I forgot to remove.

[manples]

Noticed something strange today in regards to Vsync and Pre-rendered frames vs. Left Flipper rotate and EOS timing values provided via F11:

If Vsync = 1 and Pre =1 in video settings Left Flipper rotate averages 18ms and EOS averages 34ms.

If Vsync = 0 and Pre = 0 in video settings Left Flipper rotate averages 5.4ms and EOS averages 16ms.

Why would these settings add 3 times more flipper lag on rotation and double EOS timing?

I'd love to run with Vsync = 0 and Pre = 0 for the reduced lag but many tables stutter badly with those video settings.  That is using a 980Ti at 4K resolution on the playfield.  Also driving a 720P backglass and the DMD monitor.

 

Well I did make a strange discovery too on my setup (Win10, FX-8350, GTX970, 40" 1080p Samsung TV, all sofwares up-to-date, last VPX beta with forced fullscreen and all options maxed out),

 

So the ball stutter disappears (absolute flawless fluidity) and flipper are instantly responsive when I use "FPS Limiter/VSync 2" in the VPX video options and "FPS Limiter/VSync (-1=def) 1" on the table user customizations...

 

The Nvidia parameters are: http://hpics.li/3718a44

 

At least 2 other users have tried this tweak and reported the same improvements, I'm not sure what's going on but for those in the quest of the perfect experience, it's a quick try out that doesn't hurt and could change your life :-)  

Edited by manples, 06 November 2017 - 08:31 PM.

[toxie]

It should be the same though if you simply pick 1 in the global options and -1 in the table options. Could you please retest this?

[Slydog43]

that is what I was thinking.  I thought that is the purpose of individual table settings to override the defaults for certain special cases.  Hope thats the case