Jump to content

DJRobX

VIP Class
  • Content count

    460
  • Joined

  • Last visited

  • Days Won

    45

Everything posted by DJRobX

  1. I've just finished up a new feature for VPX - full 3D surround sound output for table effects. There are a few different ways this can be set up: 1) Basic 2CH audio - this should operate exactly as it did before. Forward/rear panning is ignored. 2) All effects to rear - Moves the table sounds to the back audio channels. This allows you to move the sounds into the cab like we were able to before, but without needing a second sound card. 3) Surround, front is front - This is the best setting if using a dedicated card for the surround sound table sounds. It makes the front channels the front of your cab (closest to you). This way if you use older versions of VP, the old legacy output still works well. 4) Surround, front is rear - This is a pretty "vanilla" surround setup. If you were to play on a home theater or with virtual 3D headphones, it's the most appropriate. The "front" speakers are in the rear of the cab (furthest from you). If VPinmame is also on the same card, will shares the audio with these front channels. 5) 7.1 surround (aka 6ch audio). If you want to drive your backglass, and 4 channel table sounds all off of one card, this is the setting to use. It shifts all of the table audio to the side and rear channels, leaving the fronts available for VPM and backglass sounds. This might also be a good setting to try if you are using just 2 speakers in the cab and 2 in the backbox,, the table sounds will pan partially towards the front in 4 speaker mode, letting the backbox give some of the surround effect. Please note that these modes are used in conjunction with the Windows speaker configurations. You can use any mode on any speaker system. Some sound cards even have virtual surround options that would work with this setup. You could set up a full 7.1 setup and dedicate it to just the playfield if you wanted with option #3 or #4, and use a separate card for VPM. I have tested the 7.1 mode and it works great, but I will use the #3 option for now as it is the most backwards compatible with VP9 and VP9 PhysMod5. Next up, we have changes to VPX to let us actually use these. There's a much revamped sound manager that lets you tweak the positions without touching the table script. So you can select the flippers and drag them down to the front of the cab right from there. There is also a new Fade parameter added to the PlaySound command that lets the scripts fully position the sound. Making the ball go full surround is fairly easy. Most tables are already set up for left/right panning, so you just add an additional, very similar function for front/rear fading: function AudioFade(ball) Dim tmp tmp = ball.y * 2 / Table1.height-1 If tmp > 0 Then AudioFade = Csng(tmp ^10) Else AudioFade = Csng(-((- tmp) ^10) ) End If End Function Then add the 9th parameter to PlaySound to include this function. For example, in Scared Stiff it looks like this: PlaySound("fx_ballrolling" & b), -1, Vol(BOT(b) )*1.2, Pan(BOT(b) ), 0, Pitch(BOT(b) ), 1, 0, AudioFade(BOT(b)) I've also done some pretty extensive work to fix the issues that required a VP restart every time you change the sound config. You can now flip the output between backglass and table or change the target sound cards without a restart. WARNING Because of the new sound manager features this increases the VP file version. Please make sure to back up your tables if you experiment with this build. Hey @toxie, I've committed this into my github here https://github.com/djrobx/vpinballx if you'd like to review and integrate. I spent quote a lot of time on this one, it's much more robust than the original 2-output hack that you integrated from me the last time. I know you want to move to BASS at some point. This isn't mutually exclusive with that. and might help you somewhat since I tried to eliminate some of the rampant code duplication, and steer some of the DirectSound stuff into PinSound.cpp. vpinballx.zip
  2. Per request, I am updating the original post in the topic to include a set of builds related to my changes. I don't think I had planned for the journey ahead when I started this thread. VPM http://vpuniverse.com/forums/forums/topic/2933-sambuild29-beta-thread/ * LE Aux Board Support * WPC Modulated solenoids * Miscellaneous sound and graphics fixes * (12/17/16) Reduce GTS3 Vblank interrupts, to fix overly fast animations in Tee'd Off and possibly others. * Minor tweak to modulated solenoids (fix AFM monsters). B2S 11/26/16 (** Now included in official release and VP 10.2 installer **) http://www.vpforums.org/index.php?app=downloads&showfile=12553 * Fix intermittent string error when modulated solenoids are in use * Add support for 128 bit LED segments (for World Poker Tour) * Add some missing VPM interfaces * Increase number of supported lights DOF 12/06/16: https://www.dropbox.com/s/qncfdegwj899fby/dof120616.zip?dl=0 * Contains a small fix to prevent over-firing when modulated solenoids are in use * Fix to the fix - so combined effects like drop targets fire properly Please use these in conunction with official vP 10.2 or later. : http://www.vpforums.org/index.php?showtopic=35311 An updated core.vbs script included in VP 10.2 is required for some of the newer tables to work correctly. If you see errors related to "ModSol", then VP has picked up an old version of the core.vbs script. ---=== Original post from Sept 8 ===--- So it turns out, LE aux driver support is already present in sam.c. There's just a hack that's preventing it from working properly. Near line 512 in SAM.C look for: case 6: sam_bank[4]++; if ( sam_bank[4] == 1 && bank >= 0) Change the last line to: if (core_gameData->hw.gameSpecific1 == 0 && bank >= 0) And bam, you can see all 8 of the LE solenoids fire as Solenoid 33 through 40! Tested using the X-Men LE rom. Not much concern of this code change breaking something else. That block of code only updates the solenoids2 variable. The sam_bank[4] stuff appears to be some sort of hack that's also present on the other solenoid bank to prevent misfires. It causes it to ignore the first attempt to set the solenoid. But the way the ROM is updating the LE driver bank, we miss the event if that hack is there. There are a couple conditional blocks of code below it for a SAM Mini-DMD. I'm guessing this connects to the same port on the SAM board. I added the check that hwgameSepcific1 is 0 to ensure that games with alternate hardware connected to that port doesn't trigger the solenoids.
  3. My wiring diagram looks like Rusty's but there's only one 2.1 amp, the other two (that go to the playfield) are 2.0. The key difference in mine is that I have bass routing enabled in Speakers Properties in control panel, and I have my rears defined as small size speakers, and front (where the 2.1 amp is), as large:
  4. SAMBuild3.0 beta thread

    Yep, Freezy's the magic sauce in this case. And his DMDExt.dll is completely open source, so if he abandons the project it could still be done. Freezy popped up recently asking about crashing, I'm hoping this means he's going to do more work soon. I'd love to see support for non-SAM colorization go in.
  5. Don't forget his backhanded slap to everyone else who's releasing tables: "Table alone is awesome. Rare one with no major bugs" On behalf of myself and everyone who else who works on these things and PROVIDES THEM FREE OF CHARGE and might put something out that isn't perfect, let me sincerely apologize for the inconvenience these "major bugs" cause you. I'll be sure to issue you a full refund,
  6. SAMBuild3.0 beta thread

    If you had done stuff to try and troubleshoot the crashing, you may need to undo those things. Double check that Use External DLL is turned on for the color ROM in the VPinMame Setup, test, game options menu for Metallica LE color. Also make sure the Pin2DMD.PAL file is in the correct place in the altcolor folder. .
  7. SAMBuild3.0 beta thread

    I don't think there have been any changes recently that would negatively impact Freezy's DLL. I use his DLL myself, so my cab would break badly if that was messed up. There is a change that hopefully improves the stability a bit with some SAM games when his DLL is in use (fixed some intermittent TWD color crashing on my cab).
  8. SAMBuild3.0 beta thread

    Yeah on mine it is plenty sensitive. If i get anywhere near it, it sucks the ball down. Mike's post is from April 2017 when the bug was in place. It looks like I introduced the bug on April 2nd, and Carny fixed it May 24.
  9. SAMBuild3.0 beta thread

    @jesperpark I looked through there, there is some commentary about the coffin lock. I know there is an old version of VPM where this was broken, but I think it was fixed a while ago. I played the 3 different versions of Metallica LE that I have with the "latest" and they all worked fine.
  10. Pirates of the Caribbean

    I dunno, it looks pretty good on my LCD. There might be some missed palette switches, but for the most part it looks quite good, and it's a large improvement over the non-color patch. I could swear that in-frame coding was the first thing Freezy coded. It was kind of a trigger for me to start working on getting the serial mechanism to work.
  11. 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.
  12. SAMBuild3.0 beta thread

    Nobody has brought it up with me. If someone can give me details that would be helpful.
  13. Stern Sam - Pinmame Source Code

    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.
  14. 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.
  15. 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.
  16. Wheel Of Fortune

    Yep shouldn't be a problem.
  17. 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.
  18. 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!
  19. Wheel Of Fortune

    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.
  20. 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!!
  21. 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
  22. 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.
  23. TRON Legacy Night/Dark Mod

    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.
  24. 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.
  25. 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.
×