Drybonz Posted October 24, 2016 Share Posted October 24, 2016 Just to make sure... if we use the VPM 102416 or higher, GI will be broken on any tables that don't update for the new GI controller? Link to comment Share on other sites More sharing options...
DJRobX Posted October 24, 2016 Author Share Posted October 24, 2016 7 minutes ago, Drybonz said: Just to make sure... if we use the VPM 102416 or higher, GI will be broken on any tables that don't update for the new GI controller? If you add support for ROM controlled GI and then use an older VPM, the table won't break but the lights simply won't turn on. Or more specifically, you won't get a gi update telling the lights to turn on. That means you could code the table to turn them on initially (maybe in TableInit). Then VPinMame will just turn the GI off and back on again, if it supports it. That way anyone with any VPM can play, but they have to update to get the full light show. Link to comment Share on other sites More sharing options...
Drybonz Posted October 24, 2016 Share Posted October 24, 2016 Oh ok... thanks for the response. But, for people that are wondering, if they update to the 102416 VPM, say, for example, if they play the LOTR table, the GI will still be working (using the old code), even if the table is not updated to support the ROM controlled GI yet? Link to comment Share on other sites More sharing options...
DJRobX Posted October 24, 2016 Author Share Posted October 24, 2016 8 minutes ago, Drybonz said: Oh ok... thanks for the response. But, for people that are wondering, if they update to the 102416 VPM, say, for example, if they play the LOTR table, the GI will still be working (using the old code), even if the table is not updated to support the ROM controlled GI yet? Yep, if a table is not coded to receive GI updates, nothing bad happens when VPM updates them. They just get ignored and all is well. The old "faked" GI code will continue to do what it does. There's a super remote possibility that someone attempted to connect GI updates in vain and that their "dead" code attempt will be woken up by the new VPM, but there's probably a 1% chance of that happening. We saw something like that with new solenoids in Star Trek Pro. Link to comment Share on other sites More sharing options...
Drybonz Posted October 24, 2016 Share Posted October 24, 2016 Awesome... sounds great. Sorry for all the base questions... but also wondering what we will see with the ROM controlled GI? I'm assuming since it will be controlled as the game originally intended we will see the GI go off and on more, etc? Link to comment Share on other sites More sharing options...
DJRobX Posted October 24, 2016 Author Share Posted October 24, 2016 1 minute ago, Drybonz said: Awesome... sounds great. Sorry for all the base questions... but also wondering what we will see with the ROM controlled GI? I'm assuming since it will be controlled as the game originally intended we will see the GI go off and on more, etc? They're very good questions. The amount of change will depend on the game. My Family Guy machine pretty much never changes the GI. I never even thought about it until someone mentioned that GI support wasn't working, so I tried it and saw that my FG does in fact turn the lights off if I tilt it. It also flickers them if you bump it ("DANGER"). A lot of games turn it on and off when the ball drains. That's pretty easy to fake though. It gets more complex if the game turns it off during a bonus feature or something like that. Those things are a big pain for table authors since there's not really a simple way to identify what game mode is actually going on from a table script perspective. If you have the ROM controlled support you just connect it and your'e done. Same goes with the modulated flashers. There is a ton of scripting in Scared Stiff to try and simulate what the ROM does on its own. It only gets you so far. Now that support is here it's way less work for the table authors to get more accurate light show. Link to comment Share on other sites More sharing options...
Drybonz Posted October 24, 2016 Share Posted October 24, 2016 Fantastic. It sounds great all around. Great work. Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted October 25, 2016 Content Provider Share Posted October 25, 2016 New Build based on the latest version of DJRobX commits with modular DMD drivers in the first post here PIN2DMD driver looks for pin2dmd.pal file in a subdirectory of your pinMame installation directory called altcolor/GameName e.g. you have to copy your palette file for TZ_92 into PinMame/altcolor/tz_92/ named pin2dmd.pal Link to comment Share on other sites More sharing options...
DJRobX Posted October 25, 2016 Author Share Posted October 25, 2016 Here's an update that fixes an issue with misfiring on the AUX solenoids that Dozer found. I found a better method than counting writes to reliably get the right target solenoid bank. Instead I use that same port the GI is on and look at bits 5 and 6 (similar to how the Tron LE ramp light selection works). vpm102516.zip Link to comment Share on other sites More sharing options...
Content Provider bent98 Posted October 26, 2016 Content Provider Share Posted October 26, 2016 Does this version include Luckys modular pindmd support? Link to comment Share on other sites More sharing options...
Content Provider lucky1 Posted October 26, 2016 Content Provider Share Posted October 26, 2016 No but this version does http://vpuniverse.com/forums/forums/topic/2728-sam-build-with-modular-dmd-drivers-for-pindmd123-and-pin2dmd/ Link to comment Share on other sites More sharing options...
DJRobX Posted October 26, 2016 Author Share Posted October 26, 2016 Some really fantastic news! Herweh has released the B2S sources. This allows us to fix some issues that were very painful to work around. Please test the following B2S build. It fixes: 1) Increases the lights to 400 from 251 to support games like Star Trek LE 2) Converts modulated solenoids to booleans internally so using the WPC/SAM modulated mode doesn't negatively impact or crash B2S. Full range should still be passed to DOF. 3) Passes GetRawDMD commands through to VPM, so dual controllers are not necessary for things like Cirqus Voltaire, or hopefully ... eventually native VPX DMD rendering. https://www.dropbox.com/s/5o61qx0gahc8r24/b2s102516b.zip?dl=0 Link to comment Share on other sites More sharing options...
Rysr Posted October 26, 2016 Share Posted October 26, 2016 49 minutes ago, DJRobX said: Some really fantastic news! Herweh has released the B2S sources. This allows us to fix some issues that were very painful to work around. Please test the following B2S build. It fixes: 1) Increases the lights to 400 from 251 to support games like Star Trek LE 2) Converts modulated solenoids to booleans internally so using the WPC/SAM modulated mode doesn't negatively impact or crash B2S. Full range should still be passed to DOF. 3) Passes GetRawDMD commands through to VPM, so dual controllers are not necessary for things like Cirqus Voltaire, or hopefully ... eventually native VPX DMD rendering. https://www.dropbox.com/s/5o61qx0gahc8r24/b2s102516b.zip?dl=0 Wow, things are really advancing, isn't cooperation great!! Do we just copy the DLL for existing installations, or copy all files and run the Servregister.exe again? Thanks Rich Link to comment Share on other sites More sharing options...
stevegooner123 Posted October 26, 2016 Share Posted October 26, 2016 On 10/24/2016 at 5:09 PM, DJRobX said: Bugfix build: SAM solenoid 51 was getting skipped. vpm102416b.zip This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL? Regards Steve Link to comment Share on other sites More sharing options...
DJRobX Posted October 26, 2016 Author Share Posted October 26, 2016 47 minutes ago, Rysr said: Wow, things are really advancing, isn't cooperation great!! Do we just copy the DLL for existing installations, or copy all files and run the Servregister.exe again? Thanks Rich Just replace the DLL and EXE. Re registering should not be necessary. 38 minutes ago, stevegooner123 said: This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL? Regards Steve Interesting. This is a 32 bit DLL so that shouldn't be an issue. I'll check AC/DC on my cab later. Link to comment Share on other sites More sharing options...
Content Provider CarnyPriest Posted October 26, 2016 Content Provider Share Posted October 26, 2016 Hi, gang. Posting here adds more to the confusion, but I am having trouble today updating the SAM build in the downloads section. Or uploading any files for that matter. I've been working with djrobx to integrate all of the great changes that have been happening in the last few days so that we have one updated build. Version 2.41 is up to date with official VPM source to revision 4044 this includes the latest sound cores DMD brightness maps for AlvinG, incorporates the universal devicedmd.dll - this means that one build now supports all real DMD solutions [lucky1] modulated flashers for WPC and Whitestar, ROM controlled GI support for Whitestar [djrobx] S.A.M. AUX solenoids, modulated flashers, ROM controlled GI support [djrobx] compiled/optimized with VS2015 update 3 Please continue to post on any issues. https://dl.dropboxusercontent.com/u/45430846/VPinMAME_SAM_2.41.zip [Edit - new fixes have been committed to address devicedmd.dll - will post an update later this evening] Link to comment Share on other sites More sharing options...
Rysr Posted October 26, 2016 Share Posted October 26, 2016 Carnypriest, Why are your Dll's around 1.6 k and DJRobx's versions are around 6k in size? Do you use a different compiler? Just wondering? Rich Link to comment Share on other sites More sharing options...
DJRobX Posted October 26, 2016 Author Share Posted October 26, 2016 Good question. It's probably mainly because I have debug symbols turned on in release mode. That way if I spot something I can attach and look into it. Now, if you're wondering why I don't just use debug builds for my own testing, debug builds come with additional baggage (runtime checks, optimizations are turned off, and pinmame debugger gets attached), which makes them too slow to play. Aside from build size bloat, having it built with debug symbols shouldn't otherwise affect much if anything. Link to comment Share on other sites More sharing options...
Content Provider CarnyPriest Posted October 26, 2016 Content Provider Share Posted October 26, 2016 Lol, I'm no developer. If you leave debug code in I just merge it in with everything else.Simple answer: I pack the dll with upx, same as PinMAMEdev. I'm not sure there's a clear advantage for doing this though. If someone wants to test performance packed and unpacked then I can provide both.Sent from my iPhone using Tapatalk Link to comment Share on other sites More sharing options...
DJRobX Posted October 26, 2016 Author Share Posted October 26, 2016 Should be no issue using UPX. It's generally more efficient to keep file size smaller as processors can unpack much faster than something can be loaded from disk. It doesn't affect runtime performance either way. Link to comment Share on other sites More sharing options...
Content Provider CarnyPriest Posted October 26, 2016 Content Provider Share Posted October 26, 2016 1 hour ago, DJRobX said: Should be no issue using UPX. It's generally more efficient to keep file size smaller as processors can unpack much faster than something can be loaded from disk. It doesn't affect runtime performance either way. Ok, I'll keep packing it then. I'm interested in improving runtime performance, so I updated the compiler to the latest stable Visual Studio release. Microsoft touts that some built-in C/C++ optimizations made it into this release so I'd be interested if the difference was generally noticeable. Link to comment Share on other sites More sharing options...
toxie Posted October 26, 2016 Share Posted October 26, 2016 Don't expect wonders from that. If you want to experiment with compilers you should try to get your hands on the Intel Compiler, that -could- maybe make a bit of a difference. Link to comment Share on other sites More sharing options...
DJRobX Posted October 27, 2016 Author Share Posted October 27, 2016 9 hours ago, stevegooner123 said: This works great thanks on VP10 but when I use this DLL my VP Physmod 5 of ACDC won`t load? Is it because this is the 64bit DLL & I need the 32Bit DLL? Regards Steve I checked out AC/DC. I also use a PhysMod5 version and it runs no problem on my cab. When you say it won't load, what happens? Have you tried Carny's build? Some people have stated they need a reboot. I did a bunch of playtesting and Carny's build looks good to me. ? Link to comment Share on other sites More sharing options...
stevegooner123 Posted October 27, 2016 Share Posted October 27, 2016 1 hour ago, DJRobX said: I checked out AC/DC. I also use a PhysMod5 version and it runs no problem on my cab. When you say it won't load, what happens? Have you tried Carny's build? Some people have stated they need a reboot. I did a bunch of playtesting and Carny's build looks good to me. ? It works now with the New download Revision you posted on here,Thanks very Much DJRobX Link to comment Share on other sites More sharing options...
Content Provider CarnyPriest Posted October 27, 2016 Content Provider Share Posted October 27, 2016 Version 2.41a is up to date with official VPM source to revision 4059 includes the commits for fixing/optimizing the universal devicedmd code https://dl.dropboxusercontent.com/u/45430846/VPinMAME_SAM_2.41a.zip Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.