VIP Class
  • Content count

  • Joined

  • Last visited

  • Days Won


DJRobX last won the day on January 27

DJRobX had the most liked content!


About DJRobX

  • Rank
    Advanced Member
  • Birthday 11/13/1974

Profile Information

  • Gender
  • Location
    Valencia, CA

Recent Profile Visitors

1,074 profile views
  1. Thanks for the fix, Westworld! If you can share the updated source I'll update the official repo.
  2. Hi Westworld, A user on Facebook (I don't know his user ID here) posted an issue with this change. When your B2S aspect ratio feature adjusts the backglass image position, it is also mis-aligning the DMD image meant for a third screen. See the attached screenshots. He is able to work around the problem by making a per-backglass screenres.txt file with the DMD position values counter-adjusted to compensate, but the aspect ratio settings ought to not affect the DMD window position. This has all reminded me that we need to get this change merged into the official source. I will do that once we get this small issue fixed. Thanks!
  3. I've never considered VPM to be stable on anything but the first "fresh" run of a ROM. Once you stop the table, subsequent runs are frequently plagued with weird issues. It has been this way for years. VPX doesn't unload VPM completely when you close a table, and things get into a pretty weird state on subsequent runs unless you close VPX completely. In fact you CAN'T load VPX+VPM in debug builds more than once, you'll get a weird file IO pointer assertion deep in the bowels of Microsoft's runtime libraries (which means we're probably doing something really evil somewhere ) I think the latest tables people are building compound those kinds of issues with memory problems. Just today I was looking at a TWD:LE issue and VP often couldn't quite make it to the initial render on my laptop VM. Then I'd close some other running program and it'd be fine for a few runs. Thankfully it's relatively stable on my cab, but moving to 64 bit might offer some stability in this respect. There will almost certainly be a performance hit, especially with SAM. The JIT core would need to be re-written for x64 to really get it right.
  4. It should be committed now.
  5. Hi, can you commit your fix for the AC/DC LE left ramp diverter solenoid to the code repository? Thanks.

  6. Hi @CarnyPriest, please make a build. I fixed a small issue with the external DLL support that was preventing Metallica 1.7 LE color patch from passing palette commands properly.
  7. If you want the light show you can turn off 4xaa for this table and you should be able to handle it. That's what I do for my 960. Fortunately this table doesn't have a lot of wire ramps, so the quality doesn't suffer too much from disabling 4xaa.
  8. My DOF patch is still current and recommended. Swisslizard is on hiatus still I think. The VPM build you can use Carnys latest. I recommend the most recent beta he posted. The B2S update is included with official VP 10.2 now. I updated the first post to reflect all of this.
  9. The specific JIT crash this fixes has to do with color ROMs that have the serial side channel enabled. In some cases the patch produces "self modifying code", so additional logic had to be added to recompile modified code. Spider man color was one that would definitely not run. Jus for clarity, this is NOT a fix for the "intermittent" crash that some of you are running into with unpatched roms when used with Freezy's DMDDevice.dll.
  10. Yeah I'm afraid I'm already at the extent of my testing, it does not reproduce on this machine. That machine hadn't been patched since 2014. It worked fine initially. Updated to the latest-everything, continued to work fine. Tried turning on windows defender and a bunch of other stuff. PinballX, B2S, DOF, color DMDDevice.dll .... no ill effect, all runs fine. Tried rebooting several times, even loading multiple tables back to back without closing VP. Raw CPU won't help if you run into timing problems. What I mean is that bringing the non-JIT code up to functional parity with the JIT code will potentially slow it down a lot more.
  11. I remembered that I do have one other WIn7 x64 machine hooked up to a TV with 8GB and a Radeon graphics chip that does load VP. Unfortunately no luck so far reproducing the crash issue. I hate it when I can't reproduce issues other people have.
  12. I fixed that a couple weeks ago, but I guess it would help if I alerted @CarnyPriest to make a build. That was easy peasy. Just a matter of the game specific hack looking for "mt_145h" and the "mt_145hc" name not matching. I changed it to be 'anything that starts with mt_145h" and now it works fine with the color ROM. Mustang Pro and LE are the only ROMs that really require the game specific hack. TWD uses a "default hack" of blasting garbage data ta the serial port. Star Trek LE, Metallica LE, and AC/DC do not appear to look for any response from the serial port, so they don't need hacks. I hope some day, someone gets bored and determines what the real response the game wants from the serial LED boards is.
  13. JIT stands for "Just in time" compiling. It translates the ARM processor code into native x86 code and runs it directly. The non-JIT code, in contrast, is a standard C program that looks at each instruction and simulates its behavior. JIT specifically refers to the way the translation happens - it translates things on the fly as needed - "just in time" for use. JIT is significantly faster. I think MJR added this to VPM to better support the sound board in WhiteStar II games, which was later promoted to be the primary CPU in SAM. When I started working on the LE lighting for SAM, I discovered that I needed to emulate a serial port. Serial ports rely on something called an IRQ - Interrupt ReQuest - a hardware signal that tells the processor "Stop what you're doing!" - that some event (such as: "data has arrived and is waiting!") has occurred and needs to be handled. The IRQ support in the existing SAM and ARM processor emulation was very basic - up until the serial port, it was basically only being used for timers, and those are very predictable. To make the serial port work correctly, it required more frequent checking on each executed instruction that could possibly trigger an event. This meant that SAM emulation was going to slow way down unless I found a solution to make it go faster. So I spent a good solid month trying to track down various bugs in this existing JIT compiler that were preventing SAM games from running properly. JIT gave me more overhead to check for IRQ events on essentially every possible case that might trigger one. So, the non-JIT code works, but may not work as well. You might find stuff like slow DMD frames or the light strings "dying". Those are timing sensitive problems that took a long time to iron out completely on the JIT side. Fixing them might come at the expense of an even bigger performance hit. TL:DR = If you want all this to work right, I strongly recommend you install Windows 10. This is seriously complicated stuff, so a fix is probably not coming soon. At least not from me, since I don't currently have an environment to repro it.
  14. I suspect the problem is that the JMP calls made by JIT are not 4GB safe, but VP has that option enabled. Loading a .NET assembly in the middle of VPM might tip things over to where this is an issue. Windows 10 might use a different memory allocation strategy that makes this not a problem. Everyone with issues seems to be on Win7. Unfortunately VP doesn't run on our remaining Win7 machine (Intel graphics), so I won't be able to debug this. For now your options are to upgrade to Win10 or disable JIT.
  15. So I found out what was going on with the "No DMD device driver found" error I was seeing. I found that I am not able to load DMDDevice.dll if the table script loads VPinMame.Controller directly, it would only work through B2S.Server. The LoadLibraryEx call in VPM currently limits the DLL search to only the specified folder. So it would find the DMDDevice.dll, but then it couldn't locate a DLL it depended on (mscoree.dll). If loading through B2S, it - also being a .NET dll - loads this DLL first, so it bypasses the issue. Changing the LoadLibraryEx line to: hModule = LoadLibraryEx(filename,NULL,LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS); appears to take care of it and allows me to load VPM directly with the external DMD working. I committed the fix to Carny's repo.