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

[freezy]

43 minutes ago, Thalamus said:

x-mas is almost over. Was hoping for a solution to the cycle of colors for pindmd3 :-)

Hmm can you try this one?

DmdDevice.dll

[CarnyPriest]

I can give a try, but I take it that there are only changes to address the pindmd3 issue? 

Just to confirm, when I did move over to SysWOW64 I moved over both the dll and the ini. The ini did not require any changes at that point. Running through Setup -> Test works and the display actually came up faster with the files in SysWOW64 vs. the VPM folder (C:\Games\Visual Pinball\VPinMAME). In-game crash still occurs.

I've been testing solely with trn_174h. I should try some different SAM tables and PM5.

Test config

VPinballX21_Minimal, SAMbuild 2.8b02, and toxie's build of B2S from 12/26

NVidia 4K DSR downsampled to 1080p, AA disabled, in-game AO, anisotropic filtering enabled, ball reflection on playfield enabled, ball trail disabled, no VSync, Max pre-rendered frames zero. Unlimited max texture, and slider all the way to the right for Elements Detail Level. I always run B2S in exe mode/plug-ins enabled. I may have a beta 2 of DOF installed somewhere but I do not have any toys installed and I have the controller config setup to not use DOF.

 

[Thalamus]

Now the color cycling is gone and I'm back to standard orange.

But, the dll doesn't seem to honour registry. I tried to change color and it stayed on the default orange.

I didn't try adding a palette file though.

And, I stayed in vpinmame folder - no need to put into any system folder it seems. But I observed that I didn't get any log file.

Weird.

[TerryRed]

freezy:

I use virtual DMD on a monitor.

One thing I noticed with your latest DLL files, is that, yes the colouring for VPMame virtual DMD does work, but only with tables that have palette files, and only with the colours in those files.

If a table doesn't have a palette file, or I have colorizing disabled, then it goes back to only being orange, and doesn't use the colours I chose myself in VPMAME.

Your earlier DLL from Dec 23 works with custom VPinMAME colour settings (my own colours,etc) properly and doesn't just stay at Orange.

I also had copies of my files in syswow64, system32, and PinMAME fodlers.

 

 

Maybe you guys can clarify my understanding....since I'm new to DMD colouring, etc....  Correct me if I'm wrong about the following:

- All non-SAM DMD tables can only use a maximum of 4 colours. These can be either from your own VPinMAME settings, or a palette file (I used lucky's collection, renamed by sensless, worked great)

- SAM DMD tables can use up to 16 colours, but these must use a palette file and the rom must be customized to use this. (Walking Dead LE worked great for me with the 16 colours)

- can we get customized SAM roms for 16 colours (that someone has done) on this site?

- is it possible to use full 24 bit RGB images (or any other format) for DMD use with VPMame in any way? Or are we limited to the 4 and 16 colour options only?

- we can use 24 bit images with real DMD / virtual DMD in Pinball X

 

Thanks for any clarification you can give....

[freezy]

17 minutes ago, TerryRed said:

freezy:

I use virtual DMD on a monitor.

One thing I noticed with your latest DLL files, is that, yes the colouring for VPMame virtual DMD does work, but only with tables that have palette files, and only with the colours in those files.

If a table doesn't have a palette file, or I have colorizing disabled, then it goes back to only being orange, and doesn't use the colours I chose myself in VPMAME.

Your earlier DLL from Dec 23 works with custom VPinMAME colour settings (my own colours,etc) properly and doesn't just stay at Orange.

That seems to be a bug then, I'll have a look at it tomorrow.

Duh, inline quoting is either insanely complicated or I'm too dumb. To your other questions, Lucky1 correct me if I'm wrong:

- No, 2-bit (4-color) frames can also be enhanced to 4 bit, so you'd get 16 colors also on non-SAM ROMs.
- No, it can also work with non-patched ROMs. Patched ROMs are the result of coloring with Pinball Browser, but you can also do it with Steve's editor, which doesn't touch the ROMs.
- Yes, see Lucky1's uploads here. Note that those are only binary patches that need to be applied to the ROMs.
- No, not currently. But I guess technically, this would be partly possible by extending Lucky1's coloring algorithm. However 16 are usually fine.
- PinballX can output RGB images and vids (if I'm not mistaken)

EDIT: Updated first answer

[doogie2301]

Also these latest builds of DmdDevice.dll are causing stuttering/echoing in the rom sound for me.  It's nice to finally see all the pretty colors on my PinDMD3 though.

[freezy]

Oops, it was a regression from a previous refactoring. There you should now have the correct palette even without external file when it's enabled in VPM.

@doogie2301 Are you sure that this is related to DmdDevice.dll? There was lots of talk about sound issues with VPM but it wasn't related to the display driver as far as I know. If you updated to VPX2 then it's probably due to that. Does the stuttering occur when you disable external display as well?

DmdDevice.dll

[doogie2301]

26 minutes ago, freezy said:

Oops, it was a regression from a previous refactoring. There you should now have the correct palette even without external file when it's enabled in VPM.

@doogie2301 Are you sure that this is related to DmdDevice.dll? There was lots of talk about sound issues with VPM but it wasn't related to the display driver as far as I know. If you updated to VPX2 then it's probably due to that. Does the stuttering occur when you disable external display as well?

DmdDevice.dll

Yes definitely DmdDevice.dll.  There's no sound stuttering when disabling external display, nor with the officially released version of DmdDevice.dll (without the colorization support).

[freezy]

Got some more details so I can try to reproduce? Which display, config, ROM, link to VPM you're using?

[doogie2301]

Just now, freezy said:

Got some more details so I can try to reproduce? Which display, config, ROM, link to VPM you're using?

This is latest SAMbuild 2.8b02 at http://vpuniverse.com/forums/files/file/4236-sambuild/, but I also tried a few older versions to rule that out.  Many ROMs seem to be affected, the most obvious ones for me are TOTAN and Gilligan's Island (easily noticeable in the theme song at the start of game).  Can you be more specific about the display & config information you are looking for so I provide the right thing? 

[freezy]

Well, basically about your hardware. Are you using a physical DMD or the virtual one? Also if you added non-standard config params to the .ini file it would be good to know.

EDIT: Ah sorry just saw above that you got a PinDMD3. Did you disable it in the .ini though? Or is the virtual DMD running simultaneously?

[doogie2301]

5 minutes ago, freezy said:

Well, basically about your hardware. Are you using a physical DMD or the virtual one? Also if you added non-standard config params to the .ini file it would be good to know.

EDIT: Ah sorry just saw above that you got a PinDMD3. Did you disable it in the .ini though? Or is the virtual DMD running simultaneously?

Yeah PinDMD3, and in .ini file I have everything as enabled=false except [pindmd3], which I also have port=COM3.  So now I disabled PinDMD3 in the .ini and enabled virtual DMD, and there is also no sound stuttering, so hopefully that helps narrow it down.

[freezy]

Yes, that's a good hint, thanks! Means I need to get up and walk to my cab for every test, though. Ugh.

[doogie2301]

2 minutes ago, freezy said:

Yes, that's a good hint, thanks! Means I need to get up and walk to my cab for every test, though. Ugh.

Here's another interesting observation: it only seems to be an issue if there is a palette file present.

[freezy]

Cheers. Feel free to continue commenting here.

[lucky1]

It is most likely caused by the frame rate limited by the 1MB bandwidth of your comport. Since you use full RGB transfer
your comport will most likely not keep up with the framerate coming from pinMame. It is the same issue with pin2dmd and 
freezys dmddevice.dll, but pin2dmd simply drops the frames which it can´t handle in realtime which leads to some frames missing
in the scenes. I already told you about that.

[freezy]

Hmm no I wasn't aware of the frame dropping. How do you know when you need to drop a frame?

EDIT: So for 128x32 frames at 25 frames per second, that equals 128*32*3*25*8 = 2,457,600 baud for a 921,600 baud connection? Are you saying the damn port only supports 10 frames per second of RGB frames?

[lucky1]

I don´t know. I just don´t process additional usb input if the input buffer isn´t empty.

Yes, since you only have 1Mbit available at the comport, it seems that pindmd3 only supports
10 picture updates per second with 12288bytes per picture in full RGB mode. I would update the
RGB buffer in memory by the rate given by the input data and send a snapshot of it 10 times a second
to the usb. Maybe you can make that configurable that you can set the update framerate for pin2dmd and pindmd3
in the ini file. pin2dmd is able to handle about 25 updates per sec in RGB mode, but this is still not enough for some scrolling scenes.
In "native" mode with calculating the color on the device  I naturally don´t have that problem. That is the method I use in
my pin2dmd drivers but that is unfortunately not supported by pindmd3 and not implemented in your pind2md driver.

[freezy]

Uhm so why not pick just a faster interface for the damn display? USB is way faster than that? Are the controller more expensive or what's the problem?

I'll have a look at manually doing some congestion control but this sucks.

[lucky1]

Guess what I did with pin2dmd. I took one of the most powerful processors available. Even the latest Teensy MK64 is now only even (or 10% better) in performance compared to the STM32F4 we use. And we still have the option of using the STM32F7 with only a little code change which is twice as fast as the current STM32F4 and MK64. But maybe using Aurora for teensy as a starting point was the faster and easier way to get a picture on the RGB panels.

[DJRobX]

4 hours ago, lucky1 said:

Guess what I did with pin2dmd. I took one of the most powerful processors available. Even the latest Teensy MK64 is now only even (or 10% better) in performance compared to the STM32F4 we use. And we still have the option of using the STM32F7 with only a little code change which is twice as fast as the current STM32F4 and MK64. But maybe using Aurora for teensy as a starting point was the faster and easier way to get a picture on the RGB panels.

I think he means the serial UART interface that pin2dmd is using.    USB 1.0 supports up to 12mbps. 

The STM32F4 appears to support high speed USB:

http://fab.cba.mit.edu/classes/S62.12/people/moritz.kassner/usb_phy.html

 

[lucky1]

I know ! But the limit here is not the interface but the processor which is not fast enough to handle the data it is getting from the interface.

[freezy]

Sounds like a major failure to me. @russdx, care to comment? Can you send more than 1mbps to PinDMD3? Why did you use a crappy serial port instead of USB?

 

[lucky1]

Since it is a virtual comport using the USB it should ignore the baud rate setting and run at 12MBits, but as I said I think it is the
processor limiting here not the interface. Converting the RGB data to output data for the panels keeps it busy. I think adding a fps limiter code is the best approach to get a acceptable result. Alternative would be to update the teensy code.  

[roar]

Just got all my files updated and played MET with the colour dots... my goodness... that is AMAZING! Thank you so much freezy for getting this working with the pinDMD3, lucky1 thank you for all your work and letting it work on the pinDMD3 to boot! And to the folks who colourize the dots... holy smokes, bang up job! Now to go find some more tables and try and the other ones.