VIP Class
  • Content count

  • Joined

  • Last visited

  • Days Won


DJRobX last won the day on July 20

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,254 profile views
  1. Happy to see you back Freezy! Your virtual color DMD driver has been one of the best things to hit my cab! For the JIT crashing - Please try the latest SAM beta builds. I believe there are issues with long memory jumps in the JIT code. My theory is that JIT starts up, allocates a small pool of memory, opens up DMDDevice.dll, and its dependent libraries, and then finally starts running the ROM. It then allocates more memory for generated code on the fly, but when DMDDevice is in use, the new blocks end up further away from the code it generated in the first page and this sometimes results in crashing. When you don't use DMDDevice the dynamically generated pages end up closer to the initial code page, so they don't crash. In x86 assembly you use different JMP instructions depending on the distance. I very recently changed it to pre-allocate a larger block on startup to prevent this issue, and it stopped crashing in TWD on my cab. There's still a bug in there somewhere. It's not an easy problem to solve. I'm far from an expert on dynamic recompliers (frankly I'm pretty proud of myself for having found and fixed as many issues with it as I have ). There's a reason I've put a bunch of effort into the JIT core in the first place - The serial LED support used in the LE games requires precise, responsive handling of IRQ events. The C++ core doesn't check for these events as frequently as the checks are costly. If JIT is off you may experience timing failures in the serial LED stuff which results in the lights dying, and the DMD frames running slow.
  2. Nobody has brought it up with me. If someone can give me details that would be helpful.
  3. It is the same structure, but instead of just getting a 0 or 1 you get 0-255. What the 0-255 represents depends on the table. Some lights will be a dimmable single-color at 0-255. Other tables use R,G,B values that get mixed together (white will be 255,255,255). The indexes aren't at any specific location, VPinMame doesn't know what color one light is, it is the table's responsibility to mix them. Load the Star Trek LE table and go to its script, you can find the mapping of light IDs to the specific color mixtures for lamps. Star Trek LE is the only one that really uses that method to a crazy extent. Other tables have more single lamps with just a few mixed ones.
  4. Hey @toxie, I made a couple small fixes to the surround code. Now that I have 7.1 going in its full glory I noticed a really odd positioning thing, seems to be a DirectSound "feature" of some sort that changes the behavior very significantly if either the fade or pan was exactly at 0. Added a tiny fudge factor to keep that from happening, and it works much better now. Also fixed an issue with the backglass device not routing correctly if you only have 1 card. It was sharing the one instance which isn't really what you want in the case of a 3D sound mode. Super pumped with my setup now. I can *FINALLY* use my cab's subwoofer with the table audio and Vpinmame at the same time using the bass routing feature of my sound card. Other thing of note to people trying this: Pick the actual sound card, not "Primary Driver". Primary Driver works fine, but it will cause VPinMame's audio to get a little quieter. That :"little quieter" becomes significantly quieter if you enable your sound card's enhancements like bass routing. It all works beautifully as long as you pick the sound card's actual output.
  5. Yep I would think so too. You can grab the build in the first page to try it out. Toxie integrated it into the mainline VP so tables you save will be compatible. I also have used VPX 10.3 to load a saved table, and they give you a warning but they don't break, so it's pretty safe to use.
  6. Yep shouldn't be a problem.
  7. Yep. I put IF version_major > 10 or version_minor > 3 around the 9 parameter version of the PlaySound calls, so it will work with 10.3 or 10.4. The only thing about the VST plugin is that I don't know what will happen with a surround-sound source. It should be fine as long as the software supports multi-channel setups, but the built-in Realtek EQ for example only seems to have an effect on the front 2 channels.
  8. Ahh this is great. Now that I have Vp9 and PhysMod with surround, I switched to a single sound card 7.1 6ch setup "permanently". The best part is that the volume control finally works uniformly. Thanks again Toxie!
  9. Heh it's definitely not still in current production. Table should be a breeze to re-do with the newer VPM versions that handle the wheel for you. I can help out with the scripting if someone can work on the table.
  10. Just checked it out. Seems to work perfectly. Awesome! As I mentioned before the "Front is front" and "front is rear" are identical in VP9 because nothing deviates from the middle. But I think it's best to leave it exactly as it is. Thanks!!
  11. It will be the same as running VP 10.3. Which is to say it will send the table sounds out the FR and FL channels. That's not ideal (and is horribly not ideal if you're using a single sound card). which is why we're talking about backporting the speaker config changes. Yes! With this new surround feature you can now run everything off your U7. You can also use your current setup with just the U7 now and have it use the backglass speakers for surround effect, or you can add another 2.1 amp and put more speakers inside the cab. For all speakers off the U7 in 7.1 mode, connect FR and FL to the backbox, SR and SL to the rear of the cab, and RR and RL to the front of the cab. Tell windows you have no center channel and no sub to make it a 6.0 setup. And for anyone who's looking at this and wants an example table, Alessio took my updated WCS 94 table, which will do surround sound if it's running on 10.4
  12. Yep. Really that's fine, as long as the user can input their config and have the table sounds coming from the correct speakers it's worthwhile. I think the only option that becomes redundant is the "Front is front" and "Front is rear" options, as they'd be the same without forward/backward positional control. The remaining 3 options (all rear options, "front is front" and 7.1) will still will place the table sounds in different positions on the virtual field even without scripting or sound manager settings.
  13. Have you seen what they're supposed to look like? They're really not fine. They don't fade and blend colors like they're supposed to. I didn't realize they weren't fine until I played a real Tron. That's what inspired me to go home and fix VPM so we could do it correctly. As for VPX, try turning down the detail settings, turning off playfield reflections, etc. The end result still looks miles better than VP9 but it runs smooth as butter even on a VM in my mac laptop.
  14. Yes that's really easy, just leave all the sound manger stuff out of it. It is worth noting though that having the extra stuff data at the end of the sound entries surprisingly doesn't appear to break backward compatibility. I converted WCS back to VP 10.3 by just loading it in 10.3 and re-saving. It gives you a warning, but the older VP seems to be able to skip over the extra data without a problem.
  15. Oh I think doing so is a very good idea. Like you said, unless VP9 / PhysMod gets the update, you can't assign the sounds properly off a single card, and I really want to ditch my second card. Too many VP9 / PhysMod tables to ignore, so it's worthwhile I think. I'm pretty sure this sound code hasn't changed much (except you guys straightened out the nasty "*BG* hack thing) so it should be easy to backport.