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

630 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Need more details. Plunger has nothing to do with VPM. . When you say the plunger doesn't work what do you mean exactly? Is the ball in the shooter lane but you can't launch it? Do you have a mechanical plunger? If so what type? If NOT you may have a game controller plugged in that VP thinks is a plunger.
  11. @freezy If you add: this.ShowActivated = false; to the VirtualDMD() constructor in VirtualDMD.xaml.cs, it stops the focus problems
  12. Note that HyperPin+FPlaunch doesn't currently support VPX. You have to rename VPX's to VPTs. There's a file called VPExeTables.txt that you can use to tell FPLaunch which version of VP to use for a VPX file. If you're new to virtual pinball you might consider PinballX instead. It's newer, more supported, and easier to set up.
  13. Do you have the latest FPLaunch installed? I think FPLaunch has its own log also.
  14. Some people have reported minor performance issues with that build. It works fine for me though. If it's working for you, do feel free to keep using it as it appears to fix the crashing bug. It's otherwise based on the latest code. Once VPX dev gets around to starting the 1..3 cycle you can switch to theirs as it will also have a similar fix in place.
  15. I'm really glad you reported the crashing problem. It was just obscure enough that I would have assumed my cab was unstable or something like that. And having to play Metallica LE so much trying to reproduce it really sucked. I'll have to keep testing this update to make sure there are no other bugs ...