B2S Effects VPX Performance, the difference between 'exe' and 'standard' modes

[scottacus]

This is a fairly important finding that I just figured out that I wanted to pass along to anyone who might find themselves in a similar situation.

I recently upgraded my cab with a new motherboard, processor, graphics card and a 4k OLED playfield screen.  The screen can handle 120 FPS so I set up vpx and the nvidia controls for 120 FPS and expected to have no issues.  What I found was that I got significant FPS drops in my Nags table whenever the ball was bouncing around in the rotating pops and the table was using the new B2SSetPos method.  B2SSetPos is a new method that allows snippets (little images) to be moved around on the B2S backglass so when this method is in use in Nags, there is a lot of B2S communications.  I found that if I used the 180 horse method (turns on individual snippets and meant for older versions of B2S) or if a horse had won a race (no horse movement after this) then the game showed a rock solid 120 FPS.  Based on these findings I knew B2S was the issue.

To further rule out other causes I ran Task Manger performance and also used mjr's pinaffinity to set three cores to just vpx and associated pinball programs like VPinmame, B2S, DOF etc.  That way something like a Windows update or other background tasks could not interfere with the pinball processes.  Looking at both the cores and gpu, none of the cores were over 80% usage and the gpu was chugging along at about 30%.

With my old rig I found that running B2S in 'exe' mode gave better performance so these tables were running in exe.  I asked @jarr3 (current B2S "owner") about this an he told me that the difference between 'exe' and 'standard' B2S modes is their method of communications.   'Standard' uses the dll for communications and vpx regards this as 'fire and forget'.  In other words vpx sends a B2S command and doesn't care if B2S sees it or not.  

'Exe' mode uses the registry as the means of communications which is totally nuts!!!  The registry uses a 'lazy write' method for determining when to write to disk and only does this slow write when a program ends or if it is forced to do this.  B2S needs frequent communications from vpx so it is constantly forcing ultra slow writes to the hard drive and B2S then slowly reads these and reacts.  VPX appears to be locked up while this communications take place.  It seems that a SATA SSD can read/write to the HD and keep up with about 60 FPS in 4k but once it gets past this, lag can occur, at least on my system.

I changed Nags to 'standard' (right click the B2S and set both "this table" and default to standard) and presto magic, solid 120 FPS all the time.  I found that I was having occasional FPS drops during Medieval Madness during times of little physics action (like a castle being destroyed) and that also went away once the B2S was changed to 'standard'.

If you hit F11 and see FPS drops on your system, consider a change to 'standard' B2S mode for performance improvements.   I am using the most resent B2S from the github repo.

[robertms]

Thanks for sharing your findings Scott! I have also found B2S to be the culprit on a few of my tables after a very similar hardware update. It's great to finally understand the difference between the two modes. Interestingly, I had seen frame drop issues caused by the standard mode on a few tables, so I guess it all varies on case-by-case basis. Using the registry for communications and writing to the hard drive seems very inefficient, especially considering demands of newer 4K 120hz+ systems. Hopefully @jarr3 continues to find new ways of optimizing the server, we certainly owe him a debt of gratitude for picking up and continuing to develop this orphaned project. 

[jarr3]

On 8/17/2025 at 5:35 AM, scottacus said:

This is a fairly important finding that I just figured out that I wanted to pass along to anyone who might find themselves in a similar situation.

With my old rig I found that running B2S in 'exe' mode gave better performance so these tables were running in exe.  I asked @jarr3 (current B2S "owner") about this an he told me that the difference between 'exe' and 'standard' B2S modes is their method of communications.   'Standard' uses the dll for communications and vpx regards this as 'fire and forget'.  In other words vpx sends a B2S command and doesn't care if B2S sees it or not.  

'Exe' mode uses the registry as the means of communications which is totally nuts!!!  The registry uses a 'lazy write' method for determining when to write to disk and only does this slow write when a program ends or if it is forced to do this.  B2S needs frequent communications from vpx so it is constantly forcing ultra slow writes to the hard drive and B2S then slowly reads these and reacts.  VPX appears to be locked up while this communications take place.  It seems that a SATA SSD can read/write to the HD and keep up with about 60 FPS in 4k but once it gets past this, lag can occur, at least on my system.

I changed Nags to 'standard' (right click the B2S and set both "this table" and default to standard) and presto magic, solid 120 FPS all the time.  I found that I was having occasional FPS drops during Medieval Madness during times of little physics action (like a castle being destroyed) and that also went away once the B2S was changed to 'standard'.

If you hit F11 and see FPS drops on your system, consider a change to 'standard' B2S mode for performance improvements.   I am using the most resent B2S from the github repo.

Hi Scottacus, 

I'm glad you got it working with Nags, but your description of the modes is slightly inaccurate.
 

1. If you run it as a DLL, everything is handled in the DLL (including painting and blinking lights), so there is no communication at all. Now, all of this is happening in the VPX process, which has loaded the DLL as a COM interface.
2. However, if you run it as an EXE file, the same DLL is loaded as a COM interface. Instead of painting or blinking lights, it pushes messages through the registry in a fire-and-forget manner. The EXE is a separate process that loops and reads the registry messages, as well as painting and blinking lights.

I guess the DLL works better for you, since you have the latest hardware with enough power to run everything in one process. However, it is possible that the registry could become a bottleneck when running as an EXE (even though I believe and hope that everything is in memory and is only written to disk occasionally).

I hope to find the time this autumn to change the registry to a more efficient technology, such as named pipes or stdout/stdin, anyone with experience any ideas?

 

Anyone who knows about Windows internals or development on Windows and would like to help, we would be very grateful for the support. You would make many VPIN users happy!

[scottacus]

Thanks @jarr3 for the clarification!   Thanks also for your work in keeping this ancient software system that is so critical to vpx running and up to date!

[scottacus]

I think I might have been mistaken about standard being the correct setting for better performance.  I took a look at a B2S backglass today and it shows this"

which if you look at the buttons seems to indicate that "Standard" is the default mode for B2S and there are no table configs in my B2STableSettings.xml so it should be running tables in 'standard' mode..  If you look at the header it clearly says that B2S is running in EXE so it must be EXE that is the preferred setting NOT 'standard' which uses the dll.

[jarr3]

yes, it is using the EXE, So glad that we are all on the same page 

 

You can try to "hover over" the B2S logo, and it should tell you which XML and res file is loaded.

You can set your own standard values in the top section of the xml file, and any new tables added will get these values automatically.

Edited August 19, 2025 by jarr3
spelling

[jarr3]

Thanks for your support!

 

And I need to find out why DOF doesn't work when you go to 2.1.4 builds...  nothing I am aware of has changed in the DOF handling.

[RabidUrko]

6 hours ago, jarr3 said:

Thanks for your support!

 

And I need to find out why DOF doesn't work when you go to 2.1.4 builds...  nothing I am aware of has changed in the DOF handling.

Still a beta build, probably issues.

[eliory]

Hey, how’s it going? I read what you guys wrote here and I changed the SCARED STIFF VPW table from STANDARD to EXE as you suggested, just to try and improve the FPS a bit since sometimes I get drops of about 10 FPS there, which really isn’t great. But I wanted to test it out on this table that I really love, and for some reason since I did that I’m now getting huge FPS drops of 40–50 FPS and the ball looks really bad during gameplay and even stutters. I don’t know what to do now, do you have any idea how to fix this? I switched it back to STANDARD but it’s still happening.../ =

@jarr3 @scottacus

[jarr3]

Well scared stiff is a beast, and it is stuttering here as well.

 

you should always use exe.

[eliory]

12 minutes ago, jarr3 said:

Well scared stiff is a beast, and it is stuttering here as well.

 

you should always use exe.

I get it now haha but at this point the game is unplayable for me, even during normal play without MULTIBALL the ball gets crazy lags, which never happened before… and when there’s a multiball it almost crashes. The weird part is that this only happens on this table now… really strange.

[eliory]

also : 

I removed the B2S and it works perfectly without any FPS issues at all. Do you have any idea why this happens?? How can I actually undo what I did before?

@jarr3

Edited October 3, 2025 by eliory

[brewedVFX]

I had an issue a few years back on one Back to the Future B2S with the FPS dropping. Doing EXE to DLL switches, EXE ran better but still some big drops. Running without B2S no issue. I was on Nvidia back then with Win 10. Closing browsers, Steam and setting OS hardware acceleration improved it. Since now I'm on AMD the issue does not happen. I'll get the table and B2S and give that a test and report back.

[eliory]

I’m writing this for people who might go through what I went through and waste a good few hours of their life for nothing. I probably clicked both the button I marked and also changed the EXE option in the selection window back to STANDARD, but it’s also important to click the button “START THIS BACKGLASS AS EXE.” I didn’t notice that it wasn’t checked, and all this time I thought I had reverted it to the previous state, which is why I was getting such a serious FPS drop. So I learned something new — endless learning in the world of VPX