312 replies to this topic

[roar]

From the settings application for PinballX go to the PinballFX2 page, in the Launch Before section add the following:

 

Enable Launch Before: Yes

Launch Before Working Path: C:\<ENTER OR BROWSE TO THE PATH OF YOUR COPY OF DMD Extension>

Launch Before Executable: dmdext.exe

Launch Before Parameters: mirror --source=pinballfx2 --no-virtual -q

Launch Before Wait for Exit: No

Launch Before Hide Window: Yes

[mrangrygrandpa]

This looks awesome, but I can't get it to work for some reason.

 

I am able to get normal Visual Pinball tables running fine on the DMD, but for some reason the DMDEXT.EXE it can never find my PINDMDv3. I've hopped over to the command line, and tried testing it multiple times, but it fails to send the info to it.

 

Has anyone else run into this issue before? I tried reading through all the messages looking to see if someone else had the same problems but didn't see anything.

 

I've tried the test, and tried it by booting up PBFX2 and running it. I've also tried it going through Pinball X with no luck.

 

I'm running a Windows 10 machine, and I believe I put my files in the C:/Pinball X/Scripts/ folder (if that makes a difference).

 

Any help is appreciated. Thanks!

[freezy]

Logs please. What you've typed on the command line and what it said. Start with "dmdext test".

[mrangrygrandpa]

C:\PinballX\Scripts>dmdext test

 [1] 2016/07/18 18:22:04.140 DEBUG | PinDMDv1 device not found.

 [1] 2016/07/18 18:22:04.187 DEBUG | PinDMDv2 device not found.

 [1] 2016/07/18 18:22:04.187 DEBUG | PinDMDv3 device not found.

 [1] 2016/07/18 18:22:04.187 DEBUG | PIN2DMD device not found.

 [1] 2016/07/18 18:22:04.343  INFO | Added VirtualDMD renderer.

 [1] 2016/07/18 18:22:04.390  INFO | Press CTRL+C to close.

 

Then I closed it with CTRL+C

 

 [5] 2016/07/18 18:23:36.048  INFO | Source for 1 renderer(s) stopped.

 [5] 2016/07/18 18:23:36.064 DEBUG | Disposing render graph.

^C

 

 

pinDMD_log:

locating device:         FAIL ()

creating connection:     FAIL ()

I also just tossed it in the root dir to see if that would fix anything. First few times it would crash the program when I went to run it (at the pinDMDv3 part) but after I adjusted the settings to run as admin and security permissions it repeated the exact phrasing as my post above.

[mrangrygrandpa]

For future reference, the fix is to make sure you have the pinDMD.dll in the same folder as the dmdext.exe file. I didn't see this anywhere in the documentation so I didn't know. Sorry for the bother!

[freezy]

Hmm I've compiled pindmd.dll into dmdext.exe, so it should work without. Thanks for the heads up, will look into this.

[bent98]

Has anyone added support for this  in hyperpin launcher?

[bent98]

What is the suggest command line for pin2dmd? I am using the command below it colors dont look right.

 

 mirror --source=pinballfx2 --no-virtual -q

 

 

Also, how are people launching  dmdext and DOFFX2 at the same time via pinball X?

[TerryRed]

What is the suggest command line for *******? I am using the command below it colors dont look right.

 

 mirror --source=pinballfx2 --no-virtual -q

 

 

Also, how are people launching  dmdext and DOFFX2 at the same time via pinball X?

 

I used the Pinball X QuickLaunch plug-in for doing multiple "Launch Before" for other systems. You could try that route.

 

It allows you to have multiple "Launch Before" and "Launch After" options for each system instead of just one. However, it also has the extra option of "Also Launch".

 

The only issue is the "QuickLaunch" plug-in has a couple of bugs......it works perfect if you know what the bugs are:

 

1. It doesn't see every Pinball X "system" in the program. PFX2 was missing for me.

2. When you add a new Launch Before, and add your arguments...after clicking OK, it then says you have no arguments.

3. Sometimes the settings.xml for the plug-in gets erased.

 

The solution to this is to just add at least one thing from one "system", then close the plug-in. Then go to the settings.xml (for quicklaunch)and add your "arguments", change the "system" to the one you need. Then you can just copy and paste the entire entry and change what you want for as many things as you need. I did this for DOFFX2 for PFX2, The Pinball Arcade, Future Pinball, MAME, and PC Games...and they all work perfectly with DOFFX2 this way....and while having it detect each process and waking up. I also set the settings.xml file to "Read Only" to prevent it from getting erased. Works perfect after that.

[TerryRed]

I've been trying to get dmdext to mirror the screen of PinMAME's DMD output to dmdext's virtual DMD.

 

The main reason is because I want to be able to use VPX in exclusive full screen. To do that ddraw for pinmame must be ddraw=0. Unfortunately that messes up my dmd scaling which I need to be 1280x320. PinMAME won't go that high with ddraw=0.

 

So I thought I would try to have dmdext capture the "native" default of PinMAME which is  259x67 (256x64 plus 3 pixels for frame) and output it to the virtual dmd.

 

PinMAME is set to 259x67 at position 0,0.

 

(PinMAME won't go as low as 128x32 for me)

 

If I capture at 256x64 (at pos 0,2 to offset the borders) and output to 256x64...it seems to capture it perfectly, pixel by pixel, but the virtual dmd output is always VERY dim in comparison.  The pixels of the DMD being captured are perfect squares with NO anti-aliasing.  Is there a way to brighten the screen capture, or is this just not feasible for what I am doing?

 

Has anyone had luck in trying this?

Edited by TerryRed, 14 August 2016 - 06:15 AM.

[Carny_Priest]

Go bigger on the source. Best and brightest is 771x195.

Another option is do what I do on my setup without dmdext and set my third monitor to a custom resolution for VPM and dB2S. In my case, since my aspect ratio is 16:9, I set the resolution to 768x432 for an edge-to-edge image. You will need to do some calculations to figure out a good custom resolution that will fit your aspect ratio and any space taken up by a bevel.

By the way, you are pretty much boned if you are needing to use ddraw=0 for tables that have secondary playfield displays like TSPP, Ripley's, or Monopoly. Because VPM renders extra border space to accommodate the secondary display. I've run ddraw=0 for years to get a pixel perfect display, but these tables are ones that I have to stretch.

I get around these issues in PinballX using a custom launcher I coded in AutoHotkey.


Sent from my iPad using Tapatalk

Edited by Carny_Priest, 14 August 2016 - 06:11 PM.

[freezy]

@bent98:

I've just added it as "launch before", with the -q option that makes it quit when Pinball FX2 quits. What's wrong with the colors? What's DOFFX2?

 

@TerryRed:

The "problem" with the PinMAME window is that the DMD's pixels are surrounded by a grid, i.e. if you look at a four-pixel rectangle at 256x64, only one pixel is the real dot, the others being white space around it. Since dmdext sizes that down to 128x32, that's why the brightness is a fourth of what it's supposed to be.

 

Good news is that I've implemented a processor that removes the grid before resizing. Bad news is that's it's only active for the Pinball FX2 grabber, not the screen grabber. I'll add it to the render graph in the next version if you want.

Edited by freezy, 14 August 2016 - 07:37 PM.

[TerryRed]

@bent98:

I've just added it as "launch before", with the -q option that makes it quit when Pinball FX2 quits. What's wrong with the colors? What's DOFFX2?

 

@TerryRed:

The "problem" with the PinMAME window is that the DMD's pixels are surrounded by a grid, i.e. if you look at a four-pixel rectangle at 256x64, only one pixel is the real dot, the others being white space around it. Since dmdext sizes that down to 128x32, that's why the brightness is a fourth of what it's supposed to be.

 

Good news is that I've implemented a processor that removes the grid before resizing. Bad news is that's it's only active for the Pinball FX2 grabber, not the screen grabber. I'll add it to the render graph in the next version if you want.

 

 

That would be excellent!.

 

If I could get a colourful bright render of PinMAME with dmdext's excellent "dots", that would look really sharp, and be much more preferable to other methods I may have to do.

 

I can't have PinMAME set to 128x32 because, like you said, it requires the "white space" as you call it. The next closest I can get is 256x64.

 

dmdext is definitely picking up each pixel correctly. I adjusted the different shade levels, etc in PinMAME to just one colour for the brightest shade, and black for the other shades....so that way I could have clean one pixel wide text for it to read.   The output is perfect....just lacks the same colour brightness.

 

 

DOFFX2 is a program that lets you control the RGB LEDS and outputs of an Led-wiz or sainsmart with keyboard keys.

 

 

Edited by TerryRed, 14 August 2016 - 07:57 PM.

[Carny_Priest]

Good to know about the proximate causes. If the source image is 768x192 then more pixels in the real dot => brighter image output. But that's as large as VPM will render without it starting to place large borders around the DMD at ddraw=0. And even at the optimal 768x192, the image is not as bright as it is capable of being, say, if you were to turn on ddraw and stretch the image while the display is at its native resolution. It is what it is. VPM uses DirectX 7 and I doubt that there will be any more work done on DMD rendering when the better solution down the road would be multi-monitor support and having VP handle the rendering as it is currently doing in DT mode for some tables. 

 

As a stop-gap would not it be better if dmdext could capture from memory and render as it is designed to do for TPA? It might be able to give the best and brightest current virtual display at native resolutions.  Of course, it might just be me and TerryRed who would go through the bother.

Edited by Carny_Priest, 14 August 2016 - 08:16 PM.

[TerryRed]

Good to know about the proximate causes. If the source image is 768x192 then more pixels in the real dot => brighter image output. But that's as large as VPM will render without it starting to place large borders around the DMD at ddraw=0. And even at the optimal 768x192, the image is not as bright as it is capable of being, say, if you were to turn on ddraw and stretch the image while the display is at its native resolution. It is what it is. VPM uses DirectX 7 and I doubt that there will be any more work done on DMD rendering when the better solution down the road would be multi-monitor support and having VP handle the rendering as it is currently doing in DT mode for some tables. 

 

As a stop-gap would not it better if dmdext could capture from memory and render as it is designed to do for TPA? It might be able to give the best and brightest current virtual display at native resolutions.  Of course, it might just be me and TerryRed who would go through the bother.

 

 

That would be lovely....  the reason why dmdext is so preferable is because it renders its "dots" at whatever resolution you are using it seems. Since my middle screen is 1366x768, those dots would look really nice!

....and your're right Carney.  I either have to use a custom resolution to make 768x192 fit (which does work but its a pain), or use ddraw=1 (with 1280x320) which works great and looks very vivid and bright at native res, but I can't use fullscreen for VPX with this.

[freezy]

Well, the best method would be adding generic support for driving DMDs into PinMAME. Would need to define an API and if let's say realdmd.dll is in the PinMAME folder, PinMAME would pick it up and send frames to it.

 

This would be particularly useful for the DMD coloring stuff that's currently going on, because we could move the colorization code to a module independent from PinMAME or the DMD firmware, which would be cool because it would then also support all displays (read: PinDMDv3, and virtual). Also "legal issues" by ColorDMD threatening everybody doing "color" and "dmd" simultaneously would be separated. Lastly, DMD support for new devices would be easier to implement because a DMD vendor could just supply its realdmd.dll instead of having to patch the PinMAME source code.

 

I've talked to Lucky1 about this and we both agree that this would be pretty cool. The only problem is I don't have the time for this and Lucky1 is understandably reluctant about basically adding color support for PinDMD devices that got him banned here at VPF... Reinstating his status would apparently reevaluate his position.

[Carny_Priest]

Yes, as long as the source is good whether it is from mirror or from VPM itself. It may overcome the compromise between pixel perfect output and pixel brightness. There are still limitations:

 

One, the tables with secondary displays as mentioned above. Might be able to work around it with a custom launcher.

 

Two, the Sega tables with super size displays - 192x64  because the current aspect ratio only supports 4:1 and not 3:1. I'm not sure what you are doing for those, TerryRed?

Well, the best method would be adding generic support for driving DMDs into PinMAME. Would need to define an API and if let's say realdmd.dll is in the PinMAME folder, PinMAME would pick it up and send frames to it.

 

This would be particularly useful for the DMD coloring stuff that's currently going on, because we could move the colorization code to a module independent from PinMAME or the DMD firmware, which would be cool because it would then also support all displays (read: PinDMDv3, and virtual). Also "legal issues" by ColorDMD threatening everybody doing "color" and "dmd" simultaneously would be separated. Lastly, DMD support for new devices would be easier to implement because a DMD vendor could just supply its realdmd.dll instead of having to patch the PinMAME source code.

 

I've talked to Lucky1 about this and we both agree that this would be pretty cool. The only problem is I don't have the time for this and Lucky1 is understandably reluctant about basically adding color support for PinDMD devices that got him banned here at VPF... Reinstating his status would apparently reevaluate his position.

 

Somebody would have to chime in about the current status of color editing support for PinDMDv3. I've never seen anything presented, and I have not seen anything mentioned in a long time.  

[TerryRed]

Yes, as long as the source is good whether it is from mirror or from VPM itself. It may overcome the compromise between pixel perfect output and pixel brightness. There are still limitations:

 

One, the tables with secondary displays as mentioned above. Might be able to work around it with a custom launcher.

 

Two, the Sega tables with super size displays - 192x64  because the current aspect ratio only supports 4:1 and not 3:1. I'm not sure what you are doing for those, TerryRed?

Well, the best method would be adding generic support for driving DMDs into PinMAME. Would need to define an API and if let's say realdmd.dll is in the PinMAME folder, PinMAME would pick it up and send frames to it.

 

This would be particularly useful for the DMD coloring stuff that's currently going on, because we could move the colorization code to a module independent from PinMAME or the DMD firmware, which would be cool because it would then also support all displays (read: PinDMDv3, and virtual). Also "legal issues" by ColorDMD threatening everybody doing "color" and "dmd" simultaneously would be separated. Lastly, DMD support for new devices would be easier to implement because a DMD vendor could just supply its realdmd.dll instead of having to patch the PinMAME source code.

 

I've talked to Lucky1 about this and we both agree that this would be pretty cool. The only problem is I don't have the time for this and Lucky1 is understandably reluctant about basically adding color support for PinDMD devices that got him banned here at VPF... Reinstating his status would apparently reevaluate his position.

 

Somebody would have to chime in about the current status of color editing support for PinDMDv3. I've never seen anything presented, and I have not seen anything mentioned in a long time.  

 

The SEGA big DMD tables aren't VPX yet, so I can still just use DRAW=1 and scale it to my larger upper DMD area like I did before.

[Carny_Priest]

 

Yes, as long as the source is good whether it is from mirror or from VPM itself. It may overcome the compromise between pixel perfect output and pixel brightness. There are still limitations:

 

One, the tables with secondary displays as mentioned above. Might be able to work around it with a custom launcher.

 

Two, the Sega tables with super size displays - 192x64  because the current aspect ratio only supports 4:1 and not 3:1. I'm not sure what you are doing for those, TerryRed?

Well, the best method would be adding generic support for driving DMDs into PinMAME. Would need to define an API and if let's say realdmd.dll is in the PinMAME folder, PinMAME would pick it up and send frames to it.

 

This would be particularly useful for the DMD coloring stuff that's currently going on, because we could move the colorization code to a module independent from PinMAME or the DMD firmware, which would be cool because it would then also support all displays (read: PinDMDv3, and virtual). Also "legal issues" by ColorDMD threatening everybody doing "color" and "dmd" simultaneously would be separated. Lastly, DMD support for new devices would be easier to implement because a DMD vendor could just supply its realdmd.dll instead of having to patch the PinMAME source code.

 

I've talked to Lucky1 about this and we both agree that this would be pretty cool. The only problem is I don't have the time for this and Lucky1 is understandably reluctant about basically adding color support for PinDMD devices that got him banned here at VPF... Reinstating his status would apparently reevaluate his position.

 

Somebody would have to chime in about the current status of color editing support for PinDMDv3. I've never seen anything presented, and I have not seen anything mentioned in a long time.  

 

The SEGA big DMD tables aren't VPX yet, so I can still just use DRAW=1 and scale it to my larger upper DMD area like I did before.

 

 

But no exclusive fullscreen for VP, right?

[TerryRed]

 

 

Yes, as long as the source is good whether it is from mirror or from VPM itself. It may overcome the compromise between pixel perfect output and pixel brightness. There are still limitations:

 

One, the tables with secondary displays as mentioned above. Might be able to work around it with a custom launcher.

 

Two, the Sega tables with super size displays - 192x64  because the current aspect ratio only supports 4:1 and not 3:1. I'm not sure what you are doing for those, TerryRed?

Well, the best method would be adding generic support for driving DMDs into PinMAME. Would need to define an API and if let's say realdmd.dll is in the PinMAME folder, PinMAME would pick it up and send frames to it.

 

This would be particularly useful for the DMD coloring stuff that's currently going on, because we could move the colorization code to a module independent from PinMAME or the DMD firmware, which would be cool because it would then also support all displays (read: PinDMDv3, and virtual). Also "legal issues" by ColorDMD threatening everybody doing "color" and "dmd" simultaneously would be separated. Lastly, DMD support for new devices would be easier to implement because a DMD vendor could just supply its realdmd.dll instead of having to patch the PinMAME source code.

 

I've talked to Lucky1 about this and we both agree that this would be pretty cool. The only problem is I don't have the time for this and Lucky1 is understandably reluctant about basically adding color support for PinDMD devices that got him banned here at VPF... Reinstating his status would apparently reevaluate his position.

 

Somebody would have to chime in about the current status of color editing support for PinDMDv3. I've never seen anything presented, and I have not seen anything mentioned in a long time.  

 

The SEGA big DMD tables aren't VPX yet, so I can still just use DRAW=1 and scale it to my larger upper DMD area like I did before.

 

 

But no exclusive fullscreen for VP, right?

 

 

 

Since they are VP9 tables (or PM5), I didn't think that was even an option? I though exclusive full screen was only possible with VPX?

 

I'm running into a VPX full screen issue problem with b2s backglasses not showing / loading when launching from PBX. I've tried having B2S enabled in PBX / No backglass media, etc... and no change.

 

It works fine with VPX directly....even when using the delay function of 10.2....I only have this issue with PBX.

Edited by TerryRed, 14 August 2016 - 09:05 PM.