Search the Community

1. Hi, I was inspired a long time ago by this thread and others where people installed a mini DMD screen in the apron. I always thought that was a wonderful idea. After all, you are usually looking down at the flippers and not at the DMD. https://pinside.com/pinball/forum/topic/watch-that-dmd VPM only renders one display. I'd actually want a mirror so that I'd have a display in the usual spot on the third monitor and one on the apron. But I don't see anyone interested in developing for this, so I have written a script using ffmpeg to capture the display, scale it down to a smaller size image and stream it through the localhost network loopback. I then use ffplay to play back the stream in a window on my apron. Actually, like the video embedded in the thread above, I'm displaying dual streams, one on each side of the apron. As I am just capturing an area of the screen, it doesn't matter if it is a render from VPM or B2S. Most of displays are set to default dimensions and position, but not all of my installed tables are the default. I am capitalizing on the presence of a rom tag in the xml to read the precise size and position of the DMD and automatically size the playback window whether it is a regular display or one of the supersized displays like Mary Shelly's Frankenstein. B2S dimensions are read from screenres.txt. I am using ffmpeg's built in mpeg4 codec, and latency is very low in most cases. I do have an experimental alternative in the script that uses the libx264 source which cuts latency even more but at the risk of introducing compression artifacts on playback. Right now, this is exposed by including rom names in an array at the beginning of the script. Twilight Zone and Monster Bash work very well with libx264. Jurassic Park, not so much. Serious artifacts with the stream playback. I need to do some more testing to see if more tables see a good benefit from using the libx264 codec. If so, I'll have to consider tweaking the script and adding another tag to the xml. 2. The timing was right as I was doing this at the same time I was consolidating VP executables into one system and one database as suggested by horseyhorsey here: http://www.gameex.info/forums/topic/14632-multiple-exe-for-vp/#entry138633 That is, it is the script that actually launches VP and it is PinballX that launches the script. Should work just fine with vpx files as long as they are assigned the correct executable in the xml. For the script to function the xml requires two new tags: B2S to tell whether you want to capture a B2S display or not and exe to tell which executable to run If no rom is entered and B2S is False then the script will simply bypass all of the streaming code Example xml: 3. The rest are features I carried over from my previous scripts. VPinball991 and VP_Physmod2 share a registry and so I have to change nudge settings if I switch from one to another. Kill a persistent B2S exe for Captain Fantastic that fails to close in the usual manner. Maps my exit table button and has my coin door simulate the behavior of a real door for those tables that support a Coin Door open switch. User inputs are at the top of the script: Filter is the parameter that ffmpeg uses to scale down and rotate the display as needed: Enter the scale down factor in the parentheses. It can be a fraction or a decimal value. Ex: I use a custom resolution for my third screen that is 768x432 and the DMD default size is 768x192. I scale this down by three (in other words, a factor of 1/3) so that it will be around 256x64 when I play it back on my apron. I have a p2k-style cabinet where the DMD is vertically flipped. 'transpose=3' flips the image again and rotates. Users who don't flip the original image will probably want 'transpose=2' which only rotates Mirror1PosX and Mirror1PosY are the coordinates for the playback window of stream 1 (left side of apron) Mirror2PosX and Mirror2PosY are the coordinates for the playback window of stream 2 (right side of apron) The frame of reference is based on the standard configuration where the playfield screen is 1920x1080 resolution and is in landscape orientation with the user standing at the left side of the cab. Here's the script: requires xpath.ahk - a link is commented in the script ffmpeg - use the static build here: http://ffmpeg.zeranoe.com/ My specs - Intel i5 3570k, 8Gb RAM, GTX660 - runs dual streams well. Might be struggling a bit with Mary Shelley's Frankenstein where having a supersize display means a substantially larger area to capture. My test bed - a notebook with an NVidia Quadro with 1 Gb VRAM struggled with this but I always have a huge number of windows open.