Jump to content

All my products and services are free. All my costs are met by donations I receive from my users. If you enjoy using any of my products, please donate to support me. My bare hosting costs are currently not met so please consider becoming a contibuting member by either clicking this text or the Patreon link on the right.

Patreon

Recommended Posts

Posted

With the new DLL, some significant changes...

So most affected tables (Iron Maiden, Futurama, Blood Machines, Die Hard) the PUP now closes properly, though some quicker than others (see some still fall back to kill process).  Now, instead, only in Batman '66 the PUP doesn't close, and didn't either attempt...  had to kill from task manager for both attempts.

Previously that was one that behaved when some others did not...

log.txt

Posted
4 hours ago, Tom Speirs said:

Awesome. Thank you for helping me fix this.

Ill get the release out and see what Mike says.

Never seek an opinion from an irrational Dutch individual :P 

but... I'm convinced !
I started multiple different games. Only the first was a bit slow on exit ( still in a couple of seconds)  and not a timeout to kill the process

 

05:39:49.15  12-5-2025:  Exit System Control Pressed
05:39:50.31  12-5-2025:  Found Visual Pinball editor window
05:39:51.63  12-5-2025:  Process Closed
05:39:52.56  12-5-2025:  Getting high score
05:39:54.56  12-5-2025:  Created DirectX BackGlass Window
05:39:54.59  12-5-2025:  Created DirectX Topper Window

I still have 1 time the  error for creating a screen (thought this was resolved as my topper didn't had position set) :

RESULT: [0x8876086C], Module: [Unknown], ApiCode: [Unknown/Unknown], Message: Unknown

There was one instance where the table (Back to the future) loaded but was not focused (it was in the foreground, yet the player did not respond to any key presses). I am unsure whether this was a VPX or PBX issue.
However, I closed the table (which is gladly super fast again) and I relaunched it , and I was able to play it.
Thank you very much @Tom Speirs for having the patience and time to fix this issue .
 I am confident that not only DJO Maverick and I are pleased with this fix, but numerous other users will also appreciate it.

I hope that by the time VPX 10.9 (or VPE) is released, we will have this configuration in place and will no longer need to inconvenience you.

Again, I really appreciate your help and full support on this !

Edit : Added my log from this morning. I will test with DOF plugin and XDMD for real support as well later this week, but think this thread can be closed)
 

log.txt

  • Like 2
  • Thanks 1
Posted

Thank you fellas.

Yeah, exit may just be a little slower now.

What works is closing the player then waiting just under two seconds and closing the editor. its a little more complex than that though as its done on threads  and using less common api calls as vpx was freezing up (blocking). i will try changing it back to the usual sendmessage and do some testing.

Posted

Here is a version for testing. It works well on my cab.

This one uses sensmessagetimout wm_close

This is the proper way to do things but I need to make sure it works. Please test. the semessagetimeout is set to ten seconds. So if it is taking 20 seconds (30 seconds including editor) to exit and kill we know there is a problem.

It should properly wait for both the player and editor to exit and work fine, closing the player first. It may be quicker or slower depending on your system speed and what visual pinball is doing (ie the table), Again, it is the proper way to do it. It takes the same sort of time on my cab for most tables which is ageing a bit now.

Cheers,

Tom

PinballX.zip

Posted

Actually, i am going to just release that. Pretty sure it is best.

Timeout should be the same for kill with this now.

If it doesn't close the player with sendmessagetimeout within 10 seconds it skips to kill. So shouldn't be a downside.

Posted (edited)

Okay.

6.77 is out.

I think that is as good as its going to get for Visual Pinball but let me know.

I have a few tables that exit in under a second now. Its going to scale and get faster depending on system specs and the complexity of the table.

Cheers,

Tom

PS: Now i really need to build that new PC for my cab and put it in there.

The i7 9700 and gtx 1650 is pretty dated now.

Edited by Tom Speirs
Posted

Perhaps you could consider slowing down the release cycle a bit, Tom? I was still in the process of testing version 6.76 this morning.🤣

I plan to resume testing tomorrow, as I am currently feeling fatigued, but my initial observations were positive. Even with the  DOF plugin enabled, the exit behavior was pretty good.

I needed to update the DOF plugin to meet the latest standards, and I've significantly reduced the processing time compared to the previous version, which was based on an very old version of DOF.

I've submitted a pull request to add my modifications on github to the original deployment

3 hours ago, Tom Speirs said:

Now i really need to build that new PC for my cab and put it in there.

The i7 9700 and gtx 1650 is pretty dated now.

Even my ryzen 5600x with rtx 3080 is already outdated 

Posted
1 hour ago, Tom Speirs said:

im adding another little update to 6.79. If it does not find the player window it just goes straight to killing the process.

Good job Tom. All still working great for me (no idea why i didn't have the issues others noted).

Bit cheeky, but while the exit code is still fresh in your head is there any chance you could look at this feature request. Basically, if possible, show the exit image immediately on the playfield when 'exit system control pressed' is logged while the exit takes place (just to avoid the two or three secs of black screen). 

 

  • Like 1
Posted
3 hours ago, scutters said:

Good job Tom. All still working great for me (no idea why i didn't have the issues others noted).

Bit cheeky, but while the exit code is still fresh in your head is there any chance you could look at this feature request. Basically, if possible, show the exit image immediately on the playfield when 'exit system control pressed' is logged while the exit takes place (just to avoid the two or three secs of black screen). 

 

Thank you.

That is not really possible unfortunately the way things are now. DirectX needs to be initialised before showing the image and cant really do that until its sure no other DirectX app is running.

  • Thanks 1
Posted

...with somewhat inconsistent results.  Restarted and retried the two current problem tables...  doing Batman '66 first, it APPEARED to close properly.  But then doing Blood Machines second caused something slightly different where the PUP failed to load correctly (DMD frame but no videos), and then it failed to shut down correctly as well.

log.txt

Posted

Interesting results with 6.83.

Churning through the full suite of mandatory-pup tables here...  most of them launched and closed without issue, and closed relatively briskly.  Blood Machines is the new problem child of this and the prior build.  On attempt 1 and attempt 4 in the log, it again mis-launched the PUP (score overlay without videos).  In attempts 2 and 3, it launched appropriately.  This did not happen (to my knowledge) in any build before this and the immediately prior one.  The PUP DID close down, however, whether it started correctly or not...  however it took much, much, much longer for this one table.  The DMD screen remained active long after others went dark.

The startup hitch actually used to happen on Batman '66 many, many builds back...  can't recall if that was mentioned way earlier in this thread or another.  Now it only affects Blood Machines.

log.txt

Posted

Nearly there, please try 6.85.

Note: i think the startup issues are because it is not exiting the previous launch cleanly. i have only been working on the exit code.

Posted

I had my hopes up for a minute...  started well.  BM still closing noticeably slower than others, but not as slow.  It started properly the first time.  I looped back to it at the end after doing the others though, and it glitched the startup again, twice in a row...  perhaps suggesting another did not close cleanly somewhere in the sequence, as you said.

log.txt

Posted

Hi Tom, previously i was unaffected by the slow/kill exit so i hadn't stayed on top of testing the new releases but it appears i now see the slow / killed process exit issue on releases after 6.81 (consistent on every exit).  Nothing fancy with the table in the testing, no pup pack etc.

log681.txt

log682.txt

log683.txt

log684.txt

log685.txt

But, that's all using VPX 10.7 (some tables still need to).

If i switch the system to use VPX 10.8 GL or DX versions 6.85 exits quickly with no kill

log685 10.8 GL.txt

log685 10.8 DX.txt

Window titles are the same except the version number in use (10.7.4 shows as 10.7.3) and the log shows it finds the editor window in the slow exits as well so don't think it's that.

image.png.0fbe1bd26a5788d1fdbcc5f4f273f776.png

image.png.a796e9673724d3e69617ce6940ef6f4e.png

It looks like VPX 10.7 and 10.8 just handle close requests very differently and the older method was great for 10.7 (and 10.8 for me), but the new method works for 10.8 only?

  • Sad 1
Guest
This topic is now closed to further replies.
×
×
  • Create New...