1622 replies to this topic

[randr]

@mjr is there really any reason a pindmd2 user even needs this freezy dll? Seems pby needs 1.7.2 but I don’t see any reason I even need it but maybe I’m missing the whole point of the dll...

[mjr]

@mjr is there really any reason a pindmd2 user even needs this freezy dll? Seems pby needs 1.7.2 but I don’t see any reason I even need it but maybe I’m missing the whole point of the dll...

 

If you just want basic device access, you can use the vendor's original DLL instead.  dmd-extensions is all about the extensions - "Features for DMD owners that aren't officially supported", as freezy puts it.  Both versions of the DLL implement the same standard interface, which is defined by VPinMAME, so they're interchangeable at the basic level.

 

Examples of extended features that might be useful for a monochrome device: capture to video file; FX2/FX3/TPA support.

 

(I'm assuming that the vendor provides a 64-bit version of their DLL.  If not, and you're using 64-bit PinballY, then you can add "support for 64-bit programs" to the list above.  You always need a 64-bit DLL when working with a 64-bit EXE.  That's not my rule; if you don't like it, you'll have to take it up with Mr. Gates.)

Edited by mjr, 08 March 2019 - 03:56 AM.

[randr]

So I can replace with the dll I use in pbx and I’ll have dmd in pby? I did try that but I get an error about needing 1.7.2 for pby. FYI I’m running 32 bit pby did try the 64 bit version and realdmd fails on table exit too. I guess I’m just not sure why I need 1.7.2 to begin with but I’ll stop messing up this thread with a pindmd2 issue as I get it it’s not really your issue

[mjr]

So I can replace with the dll I use in pbx and I’ll have dmd in pby? I did try that but I get an error about needing 1.7.2 for pby. 

 

Okay, this whole situation is pretty confusing since there are so many different versions of the DLL out there.  Here's the decision matrix:

Are you using dmd-extensions or are you using your vendor's version of DmdDevice.dll?

   dmd-extensions:  you need version 1.7.2 or higher of dmd-extensions
   vendor's version:  there are no special version requirements

If you're using your vendor's DmdDevice.dll, and you're getting an error from PinballY about needing version 1.7.2, let me know - whatever generated that error message is wrong.  

 

The thing is that situation isn't really "you need dmd-extensions 1.7.2 with PinballY". A better way to put it is: "don't use dmd-extensions 1.7.1 with PinballY".  There are two ways not to use dmd-extensions 1.7.1.  One way is to use dmd-extensions 1.7.2.  Another way is to not use dmd-extensions at all and use a different DmdDevice.dll instead. 

 

Does that make sense?

 

So in your case, you should be able to use your vendor's DmdDevice.dll without complaint from PinballY, because it's not dmd-extensions 1.7.1, right?

 

It's always entirely possible, indeed highly likely, that I screwed something up in the code.  It wouldn't surprise me if my warnings about using dmd-extensions 1.7.1 are so indiscriminate that they mistake your vendor's DmdDevice.dll for dmd-extensions.  If that's the case, I should fix it, so if you could double-check with the vendor DLL and see if it generates some kind of warning/error from PinballY, let me know and I can look into it.

[Thalamus]

@mjr : A few things to keep in mind here. PinballX comes with pindmd.dll - old version used to crash with a black screen all the time if dmddevice.dll was in the vpinmame folder. My goal was to get rid of the old pindmd.dll and here is some history that partly still apply. https://vpinball.com...-dmddevice-dll/

 

It is like you say a question of what "vendor" you have. If it is from the not allowed to mention. Then lucky1 is your source. Everyone else should go with Freezy. At the moment - my recommendation is actually to run with your version of 1.7.1 for the dmddevice.dll and 1.7.2 for dmdext as it supports FX3.

 

I made a archive that I shared on dropbox. That is a known combination of dll' that will work together without crashing any components. You have in my case. PinballX, UltraDMD and VPM that needs to work together. I probably should have updated the archive with the latest version of dmddevice.dll with yours or freezy 1.7.1 - this was made back late in 2017. https://www.dropbox....indmd3.zip?dl=0

 

Just adds to the confusion - I know. And look. No libdmd.

Edited by Thalamus, 08 March 2019 - 05:42 AM.

[mjr]

@mjr : A few things to keep in mind here. PinballX comes with pindmd.dll - old version used to crash with a black screen all the time if dmddevice.dll was in the vpinmame folder. My goal was to get rid of the old pindmd.dll and here is some history that partly still apply. https://vpinball.com...-dmddevice-dll/

 

It is like you say a question of what "vendor" you have. If it is from the not allowed to mention. Then lucky1 is your source. Everyone else should go with Freezy. At the moment - my recommendation is actually to run with your version of 1.7.1 for the dmddevice.dll and 1.7.2 for dmdext as it supports FX3.

 

I made a archive that I shared on dropbox. That is a known combination of dll' that will work together without crashing any components. You have in my case. PinballX, UltraDMD and VPM that needs to work together. I probably should have updated the archive with the latest version of dmddevice.dll with yours or freezy 1.7.1 - this was made back late in 2017. https://www.dropbox....indmd3.zip?dl=0

 

Just adds to the confusion - I know. And look. No libdmd.

 

Thalamus - thanks for the explanation.  I was operating under the misapprehension that all of the physical devices (the three commercial PinDMD versions, the unmentionable one, any more out there?) had their own custom DmdDevice.dll versions, and then there's also the freezy universal one... but that's not true, is it?  The actual situation is that we have (1) the original VPinMAME version and (2) the dmd-extensions versions. 

 

So I guess you're saying that the VPinMAME version is even more problematic, and that randr should not, in fact, try to back out to that one?

 

Wow, this is quite a mess.

[Thalamus]

Freezy is universal. But, since I only own the pindmd3 I can't really guarantee how it works. But, since there is only the unmentioned and pindmd3 that has true color it isn't really important for the others to run outside of the official - unless they want to run other emulators. FX3 pr. example.

 

Yes. That is true. We kind of have two versions. All the color stuff is not in the official vpm. So, in order to have any color at all you still need the Carny build. VPM supports Sterns now, so it is only the color stuff that is the reason why Carny is still compiling those and well, he releases often - it is that too

 

I can't really say much about the status for the non-color stuff ( official ) - believe it is a universal non-color - but, I haven't looked at those releases in over two years.

 

Mess ? A huge understatement. Add to the mix that outhere is running the beta that is after 1.7.2 named 1.53 r3 or something odd low number. Would at least prefer that never stuff has higher version numbers ;-) That one gives me stutter on the pindmd3, might not be a problem with the other hw solution or lcd.

Edited by Thalamus, 08 March 2019 - 06:28 AM.

[randr]

I will add the media capture worked perfectly for 375 vpx tables(I am missing a lot hard to keep up)
Still hope you can fix pindmd2 everything is fine just don’t work in pby

[Thalamus]

I think it is wrong having the warnings in the frontend. For me it is currently a no go'er. I know why I run the versions I do. Why would I change my dof if everything is working and the fixes has been made to hardware I don't own ? Why force people to run freezy when the regular is working great for people not using color. It should be a flag to turn those checks off. The idea is great and useful for most people. But, to force it is just wrong if you ask me.

[mjr]

I will add the media capture worked perfectly for 375 vpx tables(I am missing a lot hard to keep up)
Still hope you can fix pindmd2 everything is fine just don’t work in pby

 

Did you ever try the workaround mentioned at github.com/mjrgh/PinballY/issues/41 of putting a copy of the DLL in the PinballY folder?  You said you were using 32-bit mode, I think, so it might not be at all related, but it seems at least possible that it's similarly related to device contention.

 

 

I think it is wrong having the warnings in the frontend. For me it is currently a no go'er. I know why I run the versions I do. Why would I change my dof if everything is working and the fixes has been made to hardware I don't own ? Why force people to run freezy when the regular is working great for people not using color. It should be a flag to turn those checks off. The idea is great and useful for most people. But, to force it is just wrong if you ask me.

 

What forcing are you referring to?  There are some warnings written to the log file, but I don't think there's anything that actually stops you from using whatever version you want, is there?  If there's something I'm forgetting that's constantly bugging you about it, point me to it (screen shot or just a description of where it occurs) and I'll try to make it less obnoxious.

[randr]

If your referring to moving 64 dll to pby folder that has same result. Everything is perfect as long as I disable my real pindmd2 device in pby. All tables load fine, play fine and exit fine. If I enable real dmd it will work for 1-3 loads(maybe) then crash pby on table exit. I will add autodetect don’t work for pindmd2 I have to force always on maybe that will help point to issue?
Also does pby support wheel underlays? And would be nice to hide wheel in attract mode like nailbusters frontend does that’s a great feature of popper.

[mjr]

If your referring to moving 64 dll to pby folder that has same result. 

 

Didn't you say you're using the 32-bit PinballY.exe, though?  In that case you'd want to move (or just copy) the 32-bit DLL to the PinballY folder. 

 

(The 64-bit DLL will be ignored completely if you're using the 32-bit version of the EXE, so that wouldn't make any difference one way or the other.  So if you're using the 32-bit PBY EXE, then you might try moving/copying the 32-bit DmdDevice.dll to see if that makes any difference.)

[randr]

I also had the 32 dll in folder as well. But will try again with only that dll in pby folder with nothing else give me a few min

[mjr]

If I enable real dmd it will work for 1-3 loads(maybe) then crash pby on table exit. 

 

Oh, so there's a random element to it?  That's interesting... might be some kind of timing issue with the USB device access or something.  The underlying error from the log you posted looks like a USB device conflict, but it's hard to tell, because freezy only reports the generic failure on writing to the USB.

 I will add autodetect don’t work for pindmd2 I have to force always on maybe that will help point to issue?

 

For that, it would be helpful if you'd do this:

 

1.  Go to options (press the letter O (for "Options") key)

2.  Go to the Log File page

3.  Make sure the checkbox for Real DMD logging is checked

4.  OK out of the dialog

5.  Right click in the main window and set real DMD mode to Auto

6.  Quit out of the program

7.  Run the program again

8.  Quit again

 

Now take a look at the log and see what it's reporting about real DMD detection.  That should have a bunch of information telling you what's going on with the DMD initialization attempt.

[randr]

Same worked for 2 loads and exits then crashed on a table exit. Same as before but log shows it does use the dll in pby folder. Again auto detect not seeing the pindmd2 but always on does make it work so maybe that’s causing issues? Or part of problem as it don’t autodetect?

[mjr]

Again auto detect not seeing the pindmd2 but always on does make it work so maybe that’s causing issues? Or part of problem as it don’t autodetect?

 

I can't see any way it would be related to autodetect, but the autodetect not working is a separate matter that I should fix.  When you're in autodetect mode, does the log explain why PBY is disabling the DMD?  There should be comments in the log explaining the choice to enable or not enable.

[mjr]

Also does pby support wheel underlays? 

 

No, but I can easily add that sort of thing if anyone's interested.  Let me know what you have in mind - a screen shot mockup would be great.

 

 

 And would be nice to hide wheel in attract mode like nailbusters frontend does that’s a great feature of popper.

 

There's actually a new option for that in Beta 8, and it's enabled by default.  (Someone else pointed out that the wheel icons can be a burn-in hazard if you're using one one of the styles with a fixed background shape.)

Same worked for 2 loads and exits then crashed on a table exit. 

 

I took a little look at the dmd-extensions code that's crashing, and I have some ideas about what to do about it.  I filed an issue against dmd-extensions so that freezy is aware of it, but I can also try tweaking the problematic code myself and see if I can come up with a fix or workaround.

[mjr]

For those following along at home with randr's dmd-extensions issue, it looks like we've found the solution.  It was a timing-related bug in the DLL.  I've posted a patched 1.7.2 that should fix it.

 

https://github.com/m...7.2+mjr20190309

 

It looks like the same bug will affect PinDMD v1, v2, and v3, since they all had similar code with the same problem.  The patch fixes it for all three versions.  Not that I've heard from anyone experiencing the same problem, but that could just be a matter of no one having tried it yet.

[Thalamus]

You wouldn't mind making this patch for 1.7.1 too ? This one has the same problem as freezy' 1.7.2 - no color for vni/pal altcolor. I can see that it is probably a perfect fix for Randr though.

 

About forcing messages :

How do you turn off swf warning in PBY ? I don't have flash installed. PBX seems to have that integrated.

 

Same question almost for DOF :

If I choose to enable dof while browsing, there is a warning message. It used to work flawlessly in your earlier.

 

I understand that the error from missing flash is because of my swf resources in PBX. What if I don't care about them for the moment. They are hidden normally when I run PBX (instructions). I could probably just rename the PBX folder. But, that would not really make PBY compatible with PBX would it ?

Edited by Thalamus, 10 March 2019 - 10:43 AM.

[TerryRed]

For those following along at home with randr's dmd-extensions issue, it looks like we've found the solution.  It was a timing-related bug in the DLL.  I've posted a patched 1.7.2 that should fix it.

 

https://github.com/m...7.2+mjr20190309

 

It looks like the same bug will affect PinDMD v1, v2, and v3, since they all had similar code with the same problem.  The patch fixes it for all three versions.  Not that I've heard from anyone experiencing the same problem, but that could just be a matter of no one having tried it yet.

 

I'd be VERY curious if this is also related to the problem that "a couple of people" had mentioned in relation to PuP-Packs not closing out when VPX is closed out. I've been saying that the problem they had was most likely related to DMD related files with their hardware (and not a "bug" with PuP), as I noticed it was those with PinDMD 2,3 that had this issue (the other DMD vendor and LCD users do NOT have this problem...works fine for hundreds of people). They require dmdext DLL to use PuP-Packs, and if there is a problem with timing and things not closing out.... well if any part of VPinMAME / b2s server / dmdext DLL etc is not closed out correctly and "cleanly".... that would keep PuP open as it can't close out if dmdext or VPX can't close out correctly.

 

I hope that this can help with their problem, as using taskkills should not be the solution there and should NEVER be needed to close out PuP (or any other program, really).  I've never had any problems with PuP closing out (or anything else without needing taskkills) with PBX or Popper when VPX was completely closed out properly and cleanly. It's also important to make sure the table script's exit (and UltraDMD files) didn't have problems as well, which many tables do.

 

I'd like to see these guys enjoy these stellar PuP-Packs on their cabinet, no matter what front-end they use.

Edited by TerryRed, 10 March 2019 - 12:36 PM.