440 replies to this topic

[darquayle]

Wow.... Fast response.. AND IT WORKED!.  This is one of my favorite tables and the last one for me to enable fast flips.  I now have 200 tables working with fast flippers.  The 33 remaining tables will hopefully some day join them...  Those are WPC-95, Whitestar, SAM systems so I may need to be patient.  .... Thank you nFozzy!!

[DJRobX]

And that dovetails nicely into a topic I'm looking for input on.  

 

I've determined a method to get FastFlips working on SAM.    It requires ROM-specific memory snooping.    Because of the potential "limited availability", the behavior that I think would work best is:

 

GameOn = 1: Fast flippers (flippers are currently active, bypass ROM on flipper press) enabled

GameOn = 0: Rom controlled flippers (flip only when normal solenoid pulses).

 

That would mean that if I don't currently know how to support FastFlips for the loaded ROM, I can just leave my "faked" GameOn solenoid off.  What's the best way to implement that with the current fast flip classes?     

Edited by DJRobX, 18 April 2018 - 08:47 PM.

[nFozzy]

It would need some modifications to the class. There's another issue with SAM, flipper solenoid numbers aren't consistent across games like they are for most other systems. No key handling in sam.vbs either atm.

 

Put this together quickly if you want to test it

https://pastebin.com/Lm3G2Eav

 

fake edit: the input is inverted compared to the way you did it .vpmFlipsSAM.RomControl = True for rom controlled flippers, vpmFlipsSAM.RomControl = False for FastFlips.

[DJRobX]

Thanks nFozzy! I will be using an unsed solenoid number that stays constant for this.

[Ben Logan]

Any implications here for possible VP lag reduction? Do we already have an option like this in video settings (max pre-rendered frames)?

https://arstechnica....ginal-consoles/

I will take this opportunity to thank you guys once again for fastflips. What an improvement!

[wrd1972]

Can I please get a procedure to DISABLE fast flips...temporarily. I am troubleshooting a weird flipper physic issue and I want to see if it may be causing it. Likely aint, but just wanna try.

[nFozzy]

Well the script I posted adds that functionality but you'd have to rig it up..

 

If you're after switching it in the debugger you could use these lines. SolLflipper / SolRflipper are the names of the left and right flipper subs in this case. Otherwise setting usesolenoids = 1 then restarting the table will do it.

 

'Disable fastflips
solcallback(sllflipper)="SolLFlipper"
solcallback(slrflipper)="SolRFlipper"
vpmflips.tiltsol False

'Fastflips
solcallback(slLflipper)=Empty
solcallback(slrflipper)=Empty
vpmflips.tiltsol True
vpmflips.debugon = False 'true for always-on flippers
'misc
vpmnudge.solgameon True 'enables or disables slings/bumpers

[toxie]

Any implications here for possible VP lag reduction? Do we already have an option like this in video settings (max pre-rendered frames)?

https://arstechnica....ginal-consoles/

 

Nope.

 

From my (rough) understanding it does not display one frame, to display immediately the next one (as soon as a button is pressed), and then shows that one twice so that one does not get too much noticable stutter.

 

For our scenario this would get pretty complicated, as emulation and VPX are running async from each other.

[DJRobX]

 

Nope. From my (rough) understanding it does not display one frame, to display immediately the next one (as soon as a button is pressed), and then shows that one twice so that one does not get too much noticable stutter. For our scenario this would get pretty complicated, as emulation and VPX are running async from each other.

iball

 

We could do the same thing very easily actually - just skip throttling for a frame or two after a successful flip.    Yeah, there's some possibility of it being disruptive to VPM (missing switch hits in multiball), but if we're only talking about fast forwarding 1 or 2 frames, it's not that different from what happens when your system drops frames and it has to catch up.     It would make animations of other things unsmooth, but I'm sure Retroarch suffers greatly with this also.   I can imagine the scrolling in their Sonic example would be positively awful if it juddered every time you hit the jump button.   I can't play emulators without vsync on because I can't stand rough scrolling.  

In other news, I finally got around to adding the Fast Flips solenoid to SAM.   Working on using nFozzy's script above to "pilot" it in Tron.

[Thalamus]

Fastflip for SAM sounds awesome. Could I please ask you Rob to look at mechanical tilt problem as well ?

[DJRobX]

Test successful, script works well.   Tron with fast flippers is nice!    

Next task:  Get it into sam.vbs to make it easier to change other existing tables.   It won't be quite as easy as UseSolenoids=2, but just a few lines to configure in table init should do it for most.    

Fastflip for SAM sounds awesome. Could I please ask you Rob to look at mechanical tilt problem as well ?

 

What problem is that?   The only tilt issue I was aware of is some tables were crashing when TiltObj isn't defined but fast flips are enabled.    Toxie updated the 10.5 nudge scripts to resolve this. 

[Thalamus]

Well. On SAM a clear tilt gets only warnings. So it is like there is a timeout that is very long between the first hit of the mech tilt til the next one. So, you get warned instead of a tilt. Or to put it another way. I can try as much as I like to tilt a game. I have to shake the cab for a ridiculously long time before it reads it as excessive and actually gives me the tilt.

 

I hope I'm not the only one experiencing it ???

[DJRobX]

FYI, I've posted the details on how to enable FastFlips for SAM and an updated SAM.VBS file over on the other site (where you can find the VPM build).  

[Stumblor]

Thanks nFozzy for the fantastic work with this. Been getting it setup on a host of tables and the change is remarkable. 

Would love to see a solution to the WPC 95 and Capcom tables. Quite new to VP, but I've been a developer for 15+ years (C# mostly) so will help any way I can - sounds as though looking into the individual table rom memory through VPM debugging sounds like the right route?

 

d.

Edited by Stumblor, 01 July 2018 - 08:12 AM.

[DJRobX]

Would love to see a solution to the WPC 95 and Capcom tables. Quite new to VP, but I've been a developer for 15+ years (C# mostly) so will help any way I can 

 

 

NFozzy used a faking technique on Scared Stiff that's pretty effective.

 

If you want to help with locating and adding fake solenoids to VPM, I documented the specific details about how I locate the memory locations in sam.c in the VPM sources.   But the process looks like this:

1) Using cheatengine to identify a memory location that changes when the table turns the flippers on and off.    VPM has its own debugger, but CheatEngine is the best tool I've seen for this.

2) Once you've identified #1 use Visual Studio to set a breakpoint on that memory location.  It'll be in the VM's memory write handler.  This will let you get the virtual machine's memory address. 

3) Add a fake solenoid to the machine.   This is the easiest part for me since I'm very familiar with the code.  

 

Once I worked out a reliable method to get #1, steps #2 and #3 were relatively easy for subsequent SAM tables.    So even with no programming experience, if someone can go through the process with CheatEngine and figure out the correct process to ferret out the memory location, it would be a huge help for me to add support to the ROM in question. 

Note that the memory locations in VPM move around.  So the goal is to figure out the *process* to identify the memory location, the address by itself isn't too helpful.   In SAM, you start the table, search for memory locations with "1".   Go into service menu (which disables flips), scan for memory locations that changed to 0, exit service menu, search for 1 again.    This whittles it down to a few locations.   Then you can force change them in the service menu.  When you get the right one you can turn the flips on and off from CheatEngine.  Keep in mind the value may not be 0 or 1.    In GB it was 0 or 2.   If it's some bit flag rather than a byte flag it could be anything.  

Edited by DJRobX, 01 July 2018 - 04:26 PM.

[Stumblor]

 

NFozzy used a faking technique on Scared Stiff that's pretty effective.

 

Was that the one I saw mentioned earlier, used on Congo as well, using polling?

 

 

NFozzy used a faking technique on Scared Stiff that's pretty effective.

 

If you want to help with locating and adding fake solenoids to VPM, I documented the specific details about how I locate the memory locations in sam.c in the VPM sources.   But the process looks like this:

1) Using cheatengine to identify a memory location that changes when the table turns the flippers on and off.    VPM has its own debugger, but CheatEngine is the best tool I've seen for this.

2) Once you've identified #1 use Visual Studio to set a breakpoint on that memory location.  It'll be in the VM's memory write handler.  This will let you get the virtual machine's memory address. 

3) Add a fake solenoid to the machine.   This is the easiest part for me since I'm very familiar with the code.  

 

Once I worked out a reliable method to get #1, steps #2 and #3 were relatively easy for subsequent SAM tables.    So even with no programming experience, if someone can go through the process with CheatEngine and figure out the correct process to ferret out the memory location, it would be a huge help for me to add support to the ROM in question. 

Note that the memory locations in VPM move around.  So the goal is to figure out the *process* to identify the memory location, the address by itself isn't too helpful.   In SAM, you start the table, search for memory locations with "1".   Go into service menu (which disables flips), scan for memory locations that changed to 0, exit service menu, search for 1 again.    This whittles it down to a few locations.   Then you can force change them in the service menu.  When you get the right one you can turn the flips on and off from CheatEngine.  Keep in mind the value may not be 0 or 1.    In GB it was 0 or 2.   If it's some bit flag rather than a byte flag it could be anything.   

 

 

 

Great information - thanks for taking the time to lay it all out. I'll get cracking familiarising myself with CheatEngine but will probably come back with more questions regarding the memory debugging, as it all sounds pretty dark arts! 

[Stumblor]

@DJRobX - Just a few questions if you don't mind. Taken from your sam.c comments:

 

--

// Enter service menu once again.  Use cheat engine to poke "1" into 0 values until you find the one

// that lets solenoid 15 (left flipper) fire when you hit the left shift key (usually its near the last one). 

--

 

Bit confused here. Changing the values is easy enough, but what indicator in VPM/Service Menu do I use in order to work out whether i've enabled the flipper again?

 

You mention above being able to ' force change them in the service menu.'  How is that done, using the service menu flipper tests?

 

 

thanks!

[DJRobX]

Those instructions are SAM specific.   Solenoid 15 is the left flipper solenoid that will fire when the flippers are active and you press the left switch.  If you are testing with a table loaded (VPX+VPM) you can just see the flipper flipping to know if it's activated or not.   If you are using the PinMame32 "simulator" you will just see "15" fire on the solenoid list (diagnostic output) under the DMD.  

The whole deal with SAM is that the flippers are active when the table is playing, but entering the service menu deactivates them.   So it's the quickest way to get the machine to turn them on and off for investigation.   Other machines (WPC) may work differently so the actual method to confirm you found the right address might be different.

 

Once I think I've located the right value, I can manipulate the value with CheatEngine.   In the case of SAM, changing this to 1 while in the service menu causes the flippers to start working while navigating through the service menu.    Other systems may work differently but at the very least, when the game is playing, if you manipulate the value to 0 the flippers would probably die during play.  

[DJRobX]

I found the fast flip memory address for AFM.   This one I found by tilting and watching for values that go from 0->1 and 1->0 when the ball drains.    More excitingly, it shuts off correctly when I get video mode awarded.  
 

[Ben Logan]

So cool. Nice find, DJRob. Between you and G5K we’re looking at one of the greatest (and there have been so many greats) in the box pinball sims to date.