DozerAUS Posted November 7, 2016 Share Posted November 7, 2016 15 hours ago, DJRobX said: VPM update: 1) Improve flipper latency 1.1) (All games) Throttle the CPU at more intervals in between frame updates. This gives more windows for the ROM and the table to communicate a change to each other. 1.2) (SAM,WPC) Make flipper solenoid changes immediately available to core, instead of waiting for VBLANK. 2) Another NGG update. I noticed watching videos that the wheel is pretty agile, it makes "sharp" movements when the pop bumpers are hit. Adjusted the simulation to more closely reflect this. Note that the table script should not change (and is the same as the one I posted earlier in the thread). Please note that #1.1 will change the distribution of CPU activity a bit. Previously it would emulate at full speed, then idle for a long time until the next vblank. This is bad because VPM can't respond to a flipper request if it's idling. I found this change actually made VPM operate better on my cab (no more scratchy sound with VP fps limiter is enabled). DOF update: Dozer is currently testing a small fix. I had included MJR's changes, but those caused performance issues on his cab. I rolled MJR's change back (but left my little tweak) and all is apparently looking good so far. It makes the boolean solenoids not re-fire, so if there's a lot of overlapping solenoid action it can be more responsive (as it was before modulated solenoids were enabled). Just backup, then replace your DirectOutput DLL with this one. It's based on the R3 beta. DOFR3b110616.zip vpm110616b.zip Just reporting that the DOF build you supplied on the weekend "nomjr" has been flawless for about 10 hours worth of play. Link to comment Share on other sites More sharing options...
DJRobX Posted November 7, 2016 Author Share Posted November 7, 2016 10 hours ago, toxie said: The new throttle tweak leads to some problems on some machines. For example SFII hangs on startup on both VP9 and VPX. (otherwise great stuff, of course :)) Fixed. Just a "tired programmer" mistake using min when I wanted max. This build also adds modulated solenoid support to NGG. NGG appears the be the only WPC that uses Aux Board #2 for solenoids. vpm110716.zip Link to comment Share on other sites More sharing options...
Content Provider arngrim Posted November 7, 2016 Content Provider Share Posted November 7, 2016 ehmm the flashers are not working yet, and sol51 is not working anymore Link to comment Share on other sites More sharing options...
Content Provider arngrim Posted November 7, 2016 Content Provider Share Posted November 7, 2016 or the numbers needs to be updated in the script?Sent from tapatalk Link to comment Share on other sites More sharing options...
ClarkKent Posted November 7, 2016 Share Posted November 7, 2016 The wheel in NGG stops too fast now. It's like a sudden stop. I think it should come to a stop more fluid, maybe just faster than in the last version but not a sudden stop. Somehow it looks unnatural at the moment, moved more natural last time. Link to comment Share on other sites More sharing options...
DJRobX Posted November 7, 2016 Author Share Posted November 7, 2016 Hi CK, check out videos of a real NGG. The wheel makes very fast, abrupt movements, particularly when it hits the pop bumpers. If you're familiar with the real machine and you think it should be slower I'm happy to add some mass back though. I prefer the smoother look myself. Link to comment Share on other sites More sharing options...
ClarkKent Posted November 7, 2016 Share Posted November 7, 2016 The wheel stops fast but not abrupt. There is always are very short slowing down before it stops. I think you should strike a balance - the old behavior just felt more natural. Make the slowing down shorter and I can live with it... Link to comment Share on other sites More sharing options...
DJRobX Posted November 7, 2016 Author Share Posted November 7, 2016 3 hours ago, arngrim said: ehmm the flashers are not working yet, and sol51 is not working anymore No they work now, and weren't before. : ) Before 51 was coming through as non-modulated due to another bug that was fixed. If you're doing this just to get the modulated levels in DOF, just enable UseModSol and leave the solcallbacks alone. DOF will get the modulated levels when UseVPMModSol=1, even if the table is not taking advantage of them. (DOF has no idea whether you're using SolCallback or SolModCallback). Looking at your script snippet, SetLamp needs a 0 or 1 to work. So if you pass it a modulated level, it won't work and the light won't light up. The table script would need to be updated to accept a 0-255 light level to fully implement it. I'll take a stab at that later on. Link to comment Share on other sites More sharing options...
DJRobX Posted November 7, 2016 Author Share Posted November 7, 2016 11 minutes ago, ClarkKent said: The wheel stops fast but not abrupt. There is always are very short slowing down before it stops. I think you should strike a balance - the old behavior just felt more natural. Make the slowing down shorter and I can live with it... Sold. That's a much higher quality video than the ones I was looking at. I prefer the slower movements also, and the more fine-grained movements make the ROM less likely to misread the position also. Link to comment Share on other sites More sharing options...
ClarkKent Posted November 7, 2016 Share Posted November 7, 2016 Great! I'm happy to test the next version! Link to comment Share on other sites More sharing options...
DJRobX Posted November 8, 2016 Author Share Posted November 8, 2016 Ok CK, try this build and tell me what you think. Also, here is an updated NGG script for the ModSol/ROM controlled flasher intensity (apply to original Bodydump version only) http://pastebin.com/XsdyAXP4 vpm110716b.zip Link to comment Share on other sites More sharing options...
OzBlackKnight Posted November 9, 2016 Share Posted November 9, 2016 On 11/8/2016 at 11:52 AM, DJRobX said: Great work so far DJRobX. Unfortunately, I think you are doing too good a job of perfecting the emulation. :-) Let me explain. Using the just posted VPinMAME.dll, Indiana Jones (Stern 2008) rom ij4_210 now prevents the game from playing with the message "This machine will not operate in this country....". If I delete the nvram and cfg files, and switch back to the VPinMAME.dll posted on the 30th October, it works. Switching to the latest .dll again and the error message reappears. From what I have read, Stern somehow checks whether the electricity supply is 50Hz (BAD) or 60Hz (GOOD). Being an Aussie mine is 50Hz. Can anything be done about this? No big problem if not as I haven't seen any issues with other Stern games as yet. Thanks again. Link to comment Share on other sites More sharing options...
DJRobX Posted November 9, 2016 Author Share Posted November 9, 2016 Heh, It's not your country. IJ is just extraordinarily timing sensitive. If I look at the code the wrong way it breaks. I'm not sure what broke it this time as I haven't changed timings, but I will check it out. Link to comment Share on other sites More sharing options...
DJRobX Posted November 9, 2016 Author Share Posted November 9, 2016 OK, give this a try. Although it shouldn't, it appears that the change to improve flipper latency makes a very tiny difference to timing. I just fudged a number up a little bit to compensate and it seems fine now. Thanks for reporting. vpm110816.zip Link to comment Share on other sites More sharing options...
Thalamus Posted November 9, 2016 Share Posted November 9, 2016 Simply amazed at the work you guys do. Thank you so much !!!! Link to comment Share on other sites More sharing options...
OzBlackKnight Posted November 10, 2016 Share Posted November 10, 2016 21 hours ago, DJRobX said: OK, give this a try. Although it shouldn't, it appears that the change to improve flipper latency makes a very tiny difference to timing. I just fudged a number up a little bit to compensate and it seems fine now. Thanks for reporting. vpm110816.zip Good news is it stops the "not operate in this country " message appearing. :-) Bad news is that something else is now wrong with the timing such that it doesn't ever seem to fire all 4 balls into the ark properly so you can start a game. :-( Link to comment Share on other sites More sharing options...
DJRobX Posted November 10, 2016 Author Share Posted November 10, 2016 2 hours ago, OzBlackKnight said: Good news is it stops the "not operate in this country " message appearing. :-) Bad news is that something else is now wrong with the timing such that it doesn't ever seem to fire all 4 balls into the ark properly so you can start a game. :-( Hah, HATE this rom and CSI. They're both huge pains. Link to comment Share on other sites More sharing options...
benlogan Posted November 10, 2016 Share Posted November 10, 2016 Love that TrueFullScreen DMD is properly displayed with your build, DJRobX. Thanks for your continued work, here. We're lucky to have you in our community. Link to comment Share on other sites More sharing options...
toxie Posted November 10, 2016 Share Posted November 10, 2016 Seems like the newly inserted throttle_speed_part() in cpuexec.c leads to some stuttering on some machines. Could you please look into that. I'll be on vacation soon. C ya guys!! Link to comment Share on other sites More sharing options...
Ginsonic Posted November 10, 2016 Share Posted November 10, 2016 Happy holidays Toxie and thanks for all your great work ! BTW: a big global THANK YOU to all of you, You bring so much fun into our lifes ! Link to comment Share on other sites More sharing options...
DJRobX Posted November 10, 2016 Author Share Posted November 10, 2016 1 hour ago, toxie said: Seems like the newly inserted throttle_speed_part() in cpuexec.c leads to some stuttering on some machines. Could you please look into that. I'll be on vacation soon. C ya guys!! More detail would be helpful. Link to comment Share on other sites More sharing options...
toxie Posted November 10, 2016 Share Posted November 10, 2016 On the other forum in the VP10.2 thread is some more info, but basically some machines like SFII, Kingpin, T2, etcetc now feature stuttering audio. So its related to the newly inserted delays. Unfortunately i do not have more time right now to investigate further. Link to comment Share on other sites More sharing options...
DJRobX Posted November 10, 2016 Author Share Posted November 10, 2016 1 hour ago, toxie said: On the other forum in the VP10.2 thread is some more info, but basically some machines like SFII, Kingpin, T2, etcetc now feature stuttering audio. So its related to the newly inserted delays. Unfortunately i do not have more time right now to investigate further. OK, I can look at those games. I noticed when looking at SFII the last time that it inherently divides the VBLANK into 60 chunks! So probably can change it to time-align fewer times in those cases, so the last chunk has more breathing room. Link to comment Share on other sites More sharing options...
toxie Posted November 10, 2016 Share Posted November 10, 2016 Cool.. Could also be that my previously re-designed sleep routine in there causes some sideeffects with these increased amount of delays? It calls Sleep and/or SwitchToThread, depending on the amount of time. Link to comment Share on other sites More sharing options...
DJRobX Posted November 11, 2016 Author Share Posted November 11, 2016 Yeah there's something overall wrong with the way the time sync works. The worst is the warbling audio you get on a multi-core processor with WPC games (which might have been what you were trying to address, I noticed it's somewhat better than it used to be). I'd eventually like to figure out a way to sync to the sound card's buffer rate instead, so the sound is always perfect, and just let the rest sync up to that. That's usually the strategy I've taken to fix bad sound in emulators, and the results have always been excellent. Of course, VPM is much more complicated than the average emulated game system. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.