SAM Build with modular DMD drivers for pindmd1,2,3 and PIN2DMD

[freezy]

6 hours ago, roar said:

I had trouble getting this dmddevice.dll to work with the colour roms for me. When I updated my dll in the vpinmame directory and tried to play a colour rom I'd get nothing on my pinDMD3,

Old DLL from the other day coloured roms work in colour with the Colorize DMD option NOT checked in Game Options

New DLL from this post coloured roms display in just orange with the Colorize DMD option NOT checked in Game Options. If I check Colorize DMD in game options then nothing is displayed on my pinDMD3.

All tests done with Use external DMD (dll) checked in Default Options.

Okay for PinDMD3 it was a trivial change so I didn't test it on mine, but maybe I still screwed it up. However, a log would be interesting in any case. You can find it as DmdDevice.log and it would be very helpful if anyone having problems could paste it here (use the "code" formatting).

@TerryRed: It should work like that: If "Colorize DMD (4 colors)" is checked in VPM, it searches for palette files. If none found, it just uses the color you have set in VPM. If that option is not checked, it renders orange. It shouldn't matter whether the DMD is virtual or not, If you see different behavior, let me know with a log please.

[lucky1]

45 minutes ago, freezy said:

@TerryRed: It should work like that: If "Colorize DMD (4 colors)" is checked in VPM, it searches for palette files. If none found, it just uses the color you have set in VPM. If that option is not checked, it renders orange. It shouldn't matter whether the DMD is virtual or not, If you see different behavior, let me know with a log please.

The default behaviour of my dmddevice.dll and the original pindmd3.dll if colorize is not checked is to use the color which is set under the colorize checkbox as 100% and calculate the rest of the colors to black from that instead of a orange palette.

[freezy]

14 minutes ago, lucky1 said:

The default behaviour of my dmddevice.dll and the original pindmd3.dll if colorize is not checked is to use the color which is set under the colorize checkbox as 100% and calculate the rest of the colors to black from that instead of a orange palette.

Yes, and that. By "orange" I meant the color from VPM

[lucky1]

But there seems to be a bug somewhere. It happens randomly that I get a orange palette although
I have set blue as color. Is there some kind of fallback to orange?

[lucky1]

It happens for example if I have checked colorize but no pin2dmd.pal file is found. Then it doesn´t take the settings from pinmame but orange instead on my pin2dmd.

[freezy]

Well, check out this code. _colorize is the boolean from PMoptions.Colorize set by PM_GameSettings. _color is also set through the same call from the first three value of the same PMoptions struct.

So what I'm doing in PM_GameSettings() is set the _colorize bool, the _color Color and run Init(), which runs SetupGraph(). So in any case, the color should already be set when running the block linked above. Do you have a use case where I can reproduce orange instead of blue showing up?

[freezy]

5 minutes ago, lucky1 said:

It happens for example if I have checked colorize but no pin2dmd.pal file is found. Then it doesn´t take the settings from pinmame but orange instead on my pin2dmd.

Yes, the default color when nothing is set is orange. I've just tested that use case. Removed palette files from AFM, checked colored in VPM. In this case, the 4-color palette of VPM is applied.

[lucky1]

31 minutes ago, freezy said:

Yes, the default color when nothing is set is orange. I've just tested that use case. Removed palette files from AFM, checked colored in VPM. In this case, the 4-color palette of VPM is applied.

Onscreen it is showing the correct color but on my pin2dmd it is orange

[freezy]

Okay then it's a PIN2DMD driver problem. Can you check if it's better with this?

DmdDevice.dll

[freezy]

And this is a version that doesn't send the RGB24 frame if the previous one was identical. If you have a minute to check that RGB24 is still working that would be great.

You'll see in the log how it's sent to the display. Best is to try with dmdext.exe, "dmdext test" should show (Bitmap => RGB24) when connecting. If the test image appears on the DMD that's already great, otherwise try dmdext mirror -s screen and move something in the upper left corner of your screen to check if more than 1 frame works.

DmdDevice.dll

dmdext.exe

[Thalamus]

@freezy I tried it yesterday night ( at work now and can't test the just release one ) and I believe now that is a good replacement. I set no virtual dmd in *.ini and only pindmd3 active. Used pallete files that lucky1 provided. Congo first try, was working as you describe. Same for Attack from mars, but Tron LE the DMD stayed black. IF even the folder /altcolor/trn_174h existed but wrongly named pallete files it still stayed black.

Except for this, awesome !

[freezy]

Thanks, that looks like the same bug roar described (PinDMD3 driver problem). If you got a log somewhere please post it, otherwise I'll have a look tonight.

EDIT: D'oh, just looked at the PinDMD3 code for RGB24 rendering and yeah it might be better sending the frame when it's not identical to the previous, instead of vice versa. Updated DLL attached.

DmdDevice.dll

[lucky1]

3 hours ago, freezy said:

Yes, the default color when nothing is set is orange. I've just tested that use case. Removed palette files from AFM, checked colored in VPM. In this case, the 4-color palette of VPM is applied.

No ! Still orange. I debug that later for you .

[roar]

Thanks freezy... I'll give it another go and I'll also turn logging on... I think I can find that somewhere so my feedback can be more helpful

[freezy]

6 minutes ago, lucky1 said:

No ! Still orange

Bugger.. Can you debug it? Pin2Dmd#SetColor() is run with the correct color, right?

[Westworld]

22 hours ago, freezy said:

@Westworld that looks like a compilation issue. You're using 32-bit VPinMAME, right? Here's another build I've just tested. Make sure you run the 32-bit setup.exe.

Still crashes - but:

Running (32 bit) VPinMame and click there test -> Crash
Run a VPX table using the same rom -> works!

For me that's good enough, I don't need the test feature, I just tried to minimize test environment and that was obviously the wrong idea.

Movie recording works fine for me, now recording time starts. Thanks again

[freezy]

Hmm, that's weird. Do you have any other DmdDevice.dll in SystemWOW64 or System32? When it crashes, does it also crash when external DMD is not enabled in VPM?

@Westworld which ROM crashes through setup.exe? I ran a few tests and for example Metallica Pro 1.70 crashes with SAMbuild 2.8b02 even without external DMD on my cabinet.

 

[Westworld]

10 hours ago, freezy said:

which ROM crashes through setup.exe? I ran a few tests and for example Metallica Pro 1.70 crashes with SAMbuild 2.8b02 even without external DMD on my cabinet.

apollo13

I tried to keep it simple. Default installation setup from Toxie for VPinballX 10.2, so official VPinMame without SAM. Setup for DMDExt as created by VPinBallX Installer. Then I replaced DMDDevice.dll and DMDExt.exe with the files provided here. As I wanted to reduce impact from other stuff I did it on a notebook, so no external DMD connected (there was never one connected, so no driver installed, etc) no PinballX installation, etc. Clean. Nothing installed in System32 or SystemWow64. I'll try the same on my cabinet next weekend.

Using VPinMame Setup.exe and Test button works with the integrated virtual DMD, but not with the virtual DMD from DMDDevice.dll. At least how it looks for me now. I normally rarely use that, just thought it could be an easy way to record some DMD videos on a notebook sitting in living room, without the need to install tables, backglasses, etc. Just use the ROMs.

[Thalamus]

I see the same symptoms. I only tested once - a ac/dc rom, since I already knew that westworld had reported the issue.

[CarnyPriest]

On 1/11/2017 at 6:26 AM, freezy said:

Thanks, that looks like the same bug roar described (PinDMD3 driver problem). If you got a log somewhere please post it, otherwise I'll have a look tonight.

EDIT: D'oh, just looked at the PinDMD3 code for RGB24 rendering and yeah it might be better sending the frame when it's not identical to the previous, instead of vice versa. Updated DLL attached.

DmdDevice.dll

Hi, I'm testing this version. trn_174h with color pal and vflip works consistently in VPinMAME Setup -> Test. And works in-game if I disable at91jit in the registry. It's all good so far. I'll try to do a colored patched rom soon.

 

Using a virtual DMD by the way. I've set the ini to not look for external DMD.

[DJRobX]

If the ROM isn't patched, you shouldn't need to disable AT91Jit.   That problem is specific to the commpatch. 

I'll dig into that issue as soon as I have some color patches that match tables that I use.   Every color patch that's out there seems to be for a Pro table that I use an LE version of.

 

 

 

 

[CarnyPriest]

On 1/11/2017 at 6:21 AM, freezy said:

And this is a version that doesn't send the RGB24 frame if the previous one was identical. If you have a minute to check that RGB24 is still working that would be great.

You'll see in the log how it's sent to the display. Best is to try with dmdext.exe, "dmdext test" should show (Bitmap => RGB24) when connecting. If the test image appears on the DMD that's already great, otherwise try dmdext mirror -s screen and move something in the upper left corner of your screen to check if more than 1 frame works.

DmdDevice.dll

dmdext.exe

Hi, I'm testing this version of dmdext.exe. Vflip works in FX2. Looks great! 

I've abandoned my mini-DMD mirror project on the apron. It's what I needed a rotate feature for. But it would be incompatible with VPX exclusive FS, and I need the performance improvement that true FS provides.

The remaining project for me to try is mirroring the DMD in SlamIt: Big Score. I currently use ffmpeg and ffplay but in Win 10 there is a noticeable latency. Worked very well for me in Win 7. The table's portrait mode is similar to how most people set up VP, so the playfield DMD image that gets mirrored has width as the short side. As a virtual DMD user I can probably adjust for this by rotating the third monitor into portrait mode. External DMD users might still need a rotate feature. 

And we'll have to see if there are contrast issues that affect visibility.

It's all very niche though. Not very many people bother to install this one.

[CarnyPriest]

23 minutes ago, DJRobX said:

If the ROM isn't patched, you shouldn't need to disable AT91Jit.   That problem is specific to the commpatch. 

I'll dig into that issue as soon as I have some color patches that match tables that I use.   Every color patch that's out there seems to be for a Pro table that I use an LE version of.

Hmm, crashes every time if I leave it enabled

Pal files on non-SAM are fine, of course

 

 

 

 

[DJRobX]

I have PAL files in use lots of SAM roms and they all work fine with AT91Jit.   As expected - if there's no patch, there's no difference to the emulation core.   The output chain isn't relevant to JIT/non-JIT.   

The colors are funky, but I assume that's because the PALs are supposed to be used with a color patch of course.

[freezy]

Yes, those of you having crashes, please make sure it's really the DLL causing it. You can test that by unchecking "External DMD" in VPM, if it still crashes it's not the DLL. If you're using dmdext's DmdDevice,dll, look for an exception at the end of the log, that's another hint. If you don't see a log, make sure that DmdDevice.log.config is at the same location as the DLL. If the DLL is at a location you cannot write to as non-admin (e.g. SystemWOW64), edit DmdDevice.log.config and change the path of the log file to another folder. This is important, I can't fix stuff without a log.