Search the Community

Hi, following up on this thread, http://www.gameex.info/forums/topic/15882-visual-pinball-mini-dmd-screen-3-b2s-for-apron/ , I've added a new feature: a flash viewer that displays instruction and score cards associated with the table. Requires ffmpeg and Adobe flashplayer http://ffmpeg.zeranoe.com/builds/ https://get.adobe.com/flashplayer/ As a demo, here's a crappy phone video https://www.dropbox.com/s/nrgpig9azh1b28b/afm.MOV?dl=0 This is a kludgy solution requiring multiple scripts, but it supports swf and png formats (same as PBX) including animated instruction cards. The downside is that all of the instruction card media that is available on the FTP or at VPForums are oriented for viewing on the BG screen which is usually configured for landscape. VP Cabinet tables are rotated in the program to be viewed in portrait but the screen back buffer is still oriented in landscape. This means that the media that I want to display on the apron must also be rotated. Sadly, I found a high percentage of the media could not be directly converted and rotated. So, I could not just simply convert files from the PBX Instruction Cards folder on-the-fly. I had to do screen caps and rotate the resulting images and store them in a folder prior to running the script. I have a batch script that will be included in this post. The output will need to be stored in a separate folder, and secondary score or price cards should be stored in a new folder named "Score Cards". By default I scale the images using the aspect ratio for Stern and latter day Williams/Bally as reference here: http://www.pinballrebel.com/pinball/cards/Card_sizes.htm It is possible to properly scale and display all the rotated images by manufacturer, but that might be a future update. Similar to the previous script, the correct media is displayed based on matching file names to entries in VisualPinball.xml. Matching images for the table are presented in a loop until VP is closed. I've attached a generic Instructions card and a Score card which I display at the beginning of the loop. In my collection, I have an instruction card for every table installed. So, between the generic card and the card associated with the table, I always expect that there will be multiple images to loop. Instruction cards are displayed on the left side of the apron. I don't have score or price cards for most tables, so the generic price card would be all that there is to loop. Rather than loop the same image, I have some code to check the number of files in the loop and if it is just 1 image then the program will not loop. Score cards are displayed on the right side of the apron. The script assumes the playfield aspect ratio is 1920x1080. If your screen is something different then the script must be tweaked to properly scale the images. I have not tested against all tables, but hopefully the images are not covering any play areas. The X,Y coordinates for displaying the images are user configurable. Consider where the instruction and score card images will be displayed, and leave room for the mini-DMD which will be automatically placed below the instruction and score card. The scaling of images is automated based on the the width of DMD defined in the VPM registry or in screenres.txt along with the Filter setting in the User Input section at the top of the script, so that the card images will be lined up directly over the mini-DMD. Card_Width is a failsafe setting in case there happens to be a table installed that does not use VPM and B2S is set to False in the xml. I haven't tested it. I'm not sure I have that situation in my install. The amount of time each images will be displayed before looping to the next is also user configurable at the top of the script. This is definitely for advanced users. This requires a custom xml as explained in the thread for the previous script. I may also be using different VP executables, so the script may require tweaking to fit another install. This is a secondary script for looping instruction cards. It must be compiled and named DisplayCard1.exe This is a secondary script for looping score cards. It must be compiled and named DisplayCard2.exe And here is the ffmpeg batch converter for rotating instruction cards for use in the viewer. You define where the source images are and the script will convert and save the images in %A_ScriptDir%\rotate. arrayc is where you define any animated instruction cards. There are not many at all that I could find. STAT at VPF created the two I put into the array. When the script encounters these files during processing ffmpeg will make a 30 second capture, rotate, and save as an swf file. I originally pursued this solution hoping that the text on the instruction card images would be more legible than what VP tends to render. But I have a standard width table and a 39" screen. It's still a pretty small area, so I don't think it looks much better or clearer than what VP was already doing. But since any sort of video or image content can be displayed, it becomes another creative platform for people to do interesting mods. I hope to see more animated cards or custom backgrounds for the mirrored DMD/B2S: This would be possible with some tweaking to the main script: https://pinside.com/pinball/forum/topic/watch-that-dmd#post-1043384 https://pinside.com/pinball/forum/topic/dmd-extender/page/2#post-754826 Cheers!

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.