Physics engine discussion

vikingerik

Active member
Nov 6, 2013
1,205
0
This started in the SPA Kickstarter thread but deserves a separate discussion.

This is taken/extracted from the TFnHouse.Rez file, PC/Steam revision 1.41.7, which was right after the change was made to make possible ~8 previously-impossible shots, and I think this is the change to Physics 3.0 but I'm not sure :( :

Code:
        //1(length) 2(angle speed down) 3(elasticity when flipper static) 4 (elasticity when dropping) 5(bottom speed mult) 6(number of trnsfer pts)
        Physics, UpperLeft, 350, 26, 0.5, 0.25, 0.3, 10,

                TransferPoint2, 0.13,  24,   110, 200,  0,  0,   220, 250,
                TransferPoint2, 0.20,  26,   220, 270,  0,  0,   250, 320,
                TransferPoint2, 0.24,  28,   290, 270,  0,  0,   250, 320,
                TransferPoint2, 0.35,  32,   340, 270,  0,  0,   280, 320,
                TransferPoint2, 0.55,  36,   360, 320,  0,  0,   295, 360,
                TransferPoint2, 0.77,  42,   370, 350,  0,  0,   320, 390,
                TransferPoint2, 0.86,  45,   335, 320,  0,  0,   285, 360,
                TransferPoint2, 0.92,  50,   285, 270,  0,  0,   245, 310,
                TransferPoint2, 0.98,  60,   220, 200,  0,  0,   200, 250,
                TransferPoint2, 1.00,  70,   140, 150,  0,  0,   140, 200,

Holy crap, I had no idea there's physics data human-readable in the game files. That's a gold mine of information, if we can figure out how to make use of it.

And also kinda disappointing, that TPA's physics "engine" is even more predestined and railroady than we already thought, if the possible trajectories from a flipper really are predefined that way.

I've also noticed that can't-miss feeling, and most particularly on Medieval Madness and CFTBL as we've mentioned. The big tell on CFTBL is that the same railroad that hits the left snackbar targets then flies up the ramp occurs exactly the same way coming from either a previous ramp shot or a snackbar eject. There's no way that should be true as emergent behavior, the ramp-rolling ball can't possibly behave exactly the same as the ejected one. Yet somewhere either in the feed or on the flipper itself, those converge to the same railroad.


However, the change in general table quality has increased in I believe a major way which may make it seem like 2.0/3.0 is a bigger change than it actually is.

This is very true. Aside from MM and CFTBL specifically, we were getting this sort of improvement at least as early as Twilight Zone. That shows quite a variety of behavior that feels emergent in trajectories up (and, importantly, nearly-up) its ramps and into the lock lane and camera.

Here's my hypothesis now. Somewhere in those parameters, perhaps elasticity, there's a weighting between the predefined trajectories versus including or ignoring the incoming ball velocity. It can be weighted either for all-predefinition like on MM and CFTBL, nearly so like on Funhouse and Monster Bash which also yield that "can't-miss" feeling, or weighted more towards emergent behavior like on TZ. Later tables that feel stiff and poorly tuned like HRC and Junkyard rely too much on predefinition. It can even be weighted per-flipper where Road Show's main flippers feel emergent but the blast-hole flipper feels easy and predestined, or even per-*shot* (per "transfer point" on the flipper) where Dracula's ramp feels unmissable while the mystery scoop needs an exact railroad from a catch. Want to see if you can corroborate any of that from the game data?

And people are conflating a higher weight on emergent behavior found in the later tables with "Physics 3.0". Or Farsight may even have intended that association.
 
Last edited:

vikingerik

Active member
Nov 6, 2013
1,205
0
A lot of it is down to the enforced 60Hz cycle. If you increase the speed of the cycle, you can get more "transfer points" on the flipper.

I don't know if the first sentence is true... it only is if they're using all the transfer points that they currently have with 60 Hz, and I don't think they are. But I do have some confusion about these things.

They're not using all the transfer points. There are many railroads that occur far too frequently for even me to be hitting a 1/60 timing window that consistently. CFTBL's ramp is the obvious one. STTNG also has a lot of these, most notably the shot from the left popper that almost-but-not-quite reaches the lock hole, and there's also one too-frequent railroad that occurs on a miss to the mission start hole. These shots are defined by transfer points that must be more than 1/60 second wide (based on how often everyone experiences them) and therefore must apply the railroad ignoring the ball's incoming position and velocity.

Ripley's makes what happened really obvious. Consider the temple ramp shot that always found the C lane. Then that was tweaked so that more possibilities could happen on that shot -- without changing any other flipper behavior or railroads. This had to have been subdividing one transfer point that was wider than 1/60 second into more.

But some shots and railroads do depend on and occur because of the 60 Hz resolution. I think Twilight Zone has two. One is the shot from the left flipper that hits the post between the right ramp and lock lane, then bounces into the piano. The other is the upper-right flipper shot from a lock release that bounces off the held upper-left flipper and into the piano. I can get each of these to happen sometimes but not consistently, maybe 25% accurate. Farsight would not have tuned rebound shots like that. Those really are emergent behavior that occur not because of the transfer points but because of the 60 Hz cycle.

One more example is on Ripley's, with the eject from the continent scoop. The upper-right flipper can shoot the ball at the closest post so that it rebounds up the right orbit (useful for Antarctica Penguin jackpots.) I can also hit this about 25% accurate, and it railroads the same way whenever I do. So I think this is also a 1/60 untuned emergent timing window.

Finally, consider Funhouse's pre-tuning shot from the upper flipper off the T target into the trap door. The explanation for this is obvious now. There must have been transfer points enabling that railroad to be wider than 1/60 second; the proof is that I (and everyone) can hit it much more accurately than those TZ and Ripley's rebound shots. Farsight tuned a rebound shot without realizing it was a rebound shot hitting the T.
 

invitro

New member
May 4, 2012
2,337
0
Holy crap, I had no idea there's physics data human-readable in the game files. That's a gold mine of information, if we can figure out how to make use of it.
Well, it's compressed/encoded, but I figured out how to find it and how to decode* it. There are tons of things like this in the .rez files. The above came from a file called PBTFunhouse.csv, and is for v1.41.7. It is 1507 lines long; I've deleted a bunch of lines that I think aren't of interest here, lines that are similar to lines above or below, and got down to 279 lines, which I've put below. (I've noted where I've deleted lines, except for blank lines.)

* The compression/encoding is a modified LZ77, if I have that right! -- https://en.wikipedia.org/wiki/LZ77_and_LZ78

I can grab and post more files, maybe put them in a git or something like that if I can figure out how to use it... suggestions welcome if that's useful. I'm interested in analyzing this data too, but maybe not today... :) :) I feel kind of lazy.

Code:
//Funhouse table
Table = PBTable:Funhouse
        Resources, RSID_TFUNHOUSE_START, RSID_TFUNHOUSE_END, RSID_TFUNHOUSE_MODELS,
        Dil, RSID_TFUNHOUSE_PLACEMENT, 0,
        Controls, FlipperLeft, 1, FlipperRight, 3, FlipperLeft2, 5, FlipperRight2, 7,
        FlipperSolenoids, FlipperLeft, 31, 32, FlipperRight, 29, 30, FlipperLeft2, -1, -1, FlipperRight2, -1, -1,
        Balls, 4, 3,  15, 1248.0, -2256.0, 1015.0, 75,0,0, 345,
//           Slow Gravity     Table Rotation   Fast Gravity       Max Speed for Slow Gravity
        Gravity, 0.0,0.0,-55.0,       -1.6,            0.0,0.0,-32,               75.0,
        HDR, MiddleGrayKey, 0.3369, BloomScale, 1.47, TightDeviation, .3309, BroadDeviation, 1.0, TightBrightness, 4.32, BroadBrightness, 1.03, StarScale, 1.5, AdaptLuminanceRate, 4.7, RenderStar, FALSE, GlareDefType, GLT_NATURAL, BrightnessThreshhold, 0.56, BrightPassOffset, 10.76, BlueShift, TRUE, End,
        HDR_ps3, MiddleGrayKey, 0.3369, BloomScale, 0.8, TightDeviation, 1.0, BroadDeviation, 1.0, TightBrightness, 4.32, BroadBrightness, 1.03, StarScale, 1.5, AdaptLuminanceRate, 160, RenderStar, FALSE, GlareDefType, GLT_NATURAL, BrightnessThreshhold, 0.56, BrightPassOffset, 10.76, BlueShift, TRUE, End,
        @PS3, SPU_FX, GScale0, 0.00, Source0, 0.57, Bright0, 1.00, Bright3, 0.00, ThresholdR, 0.00, ThresholdG, 0.00, ThresholdB, 0.03, TintR, 1.00, TintG, 1.00, TintB, 1.00, BaseR, 0.00, BaseG, 0.00, BaseB, 0.01, End,
        @PS4, SPU_FX, GScale0, 0.00, Source0, 0.7, Bright0, 1.0, SourceLow0, 1.15,  BrightLow0, 0.6, SourceHigh0, 0.3, BrightHigh0, 1.0, Bright3, 0.00, ThresholdR, 0.00, ThresholdG, 0.00, ThresholdB, 0.00, TintR, 1.00, TintG, 1.00, TintB, 1.00, BaseR, 0.00, BaseG, 0.00, BaseB, 0.00, End,

        LightsFile, Dev/Funhouse/LightSets.txt, RSID_TFUNHOUSE_LIGHTS
        Emulated,
        Dimensions, 10, 21,
        Display, LCD, RSID_TFUNHOUSE_HUD, 32,   41,21, 73,21, 105,21, 137,21, 169,21, 201,21, 233,21, 265,21, 297,21, 329,21, 361,21, 393,21, 425,21, 457,21, 489,21, 521,21, 41,92, 73,92, 105,92, 137,92, 169,92, 201,92, 233,92, 265,92, 297,92, 329,92, 361,92, 393,92, 425,92, 457,92, 489,92, 521,92,
        Friction, 0.003,
        CamerasFile, Dev/Funhouse/FunhouseCameras.csv, RSID_TFUNHOUSE_CAMERAS,
        DefaultPhysics, 0.4, 0, 10, 0,
        TiltSwitch, 14,
        //SkillShotTime, 3000,
        MipBias, -1.0,
        BallTrough, 3, 63, 74, 72,
        FlipperSteps, 6,
        KnockerSolenoid, 7,
        ReflectionAlpha, 250,
        VibrateEject, 0.2, 1.5, 120,
        DemoScore, 6154740,
        FreeCam, -1500, 1500, -3000, 2000, 2500, 5800, 90, 180,
        FloorLocations, -2958.64722, 2602.48389, 882.634338, 1271.50562,
        PlungeOnlyOnBall,
        BallRender, Main, EnvironmentBlend, 0.59, Reflection, BlendMode, Normal, End,
        BackglassCam, 309.60,-1813.90,4008.20, 90.00,0.00,358.79, 0.00,1.00,
        PlayfieldCam, 185.30,-1571.00,3988.19, 150.00,0.00,0.00, 0.00,1.00,
        OrthoCamera, 2937.00, 5026.00,
        // type,                num             dilname,                color,                          brightness
        LightingData, RSID_TFUNHOUSE_PLACEMENT, 1,
                LightFlasher,           18,             F19A,0,                 6.379, 2.087, 0.209,            0.419,          0.000180,
                LightLamp,              14,             L27A,0,                 4.250, 0.869, 0.500,            0.479,          0.000045,
[150 lines deleted]
                LightON,                -1,             OnHeadF,0,                      4.107, 3.786, 2.719,            0.689,          1.000000,
        EndLightingData
TableEnd = PBTable:Funhouse

////////////////////////////////////visibles
Table = PBObject:VisibleApron
        Object, PB_OBJECTTYPE_VISUAL, 2500,
        Pos, 0.0, 0.0, 0.0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        Models, 1, RSID_TFUNHOUSE_MODELS, 0,
        Lights, Def_Apron,
TableEnd = PBObject:VisibleApron

Table = PBObject:VisibleCabinet_Body
[117 lines deleted]
TableEnd = PBObject:VisibleCabinet_metal

////////////////////////////////////flippers
Table = PBObject:FlipperRight
        EnablePhysics, DownAccel, DeflectionMod, LiveCatch, End,
                          //min speed   vector range       min % up to activate
        LiveCatchPhysics, 95.0,         -0.35,            0.70,

                        //transfer of power based on how high up the flipper is from the bottom to top
        DeflectionModPhysics, .95, 1, 1, 1, 1, .99, .98, .97, .96, .95, .94,

        DownAccelPhysics, 0.7, -5, -12,

        UseSpecialRotation, True,

        Object, PB_OBJECTTYPE_FLIPPER, 2500,
        Switch, 11,
        DilPos, flipper B, 0,
        Models, 1, RSID_TFUNHOUSE_MODELS, 23,
        Lights, Def_Flippers,
        Collision, Mesh, 2, RSID_TFUNHOUSE_COLLISIONS, 3, RSID_TFUNHOUSE_COLLISIONS, 2,
        SwitchEOS, 4,
        EnvMapReflection, True,
        Vars, 2, -52.0, -78.0,

        //1(length) 2(angle speed down) 3(elasticity when flipper static) 4 (elasticity when dropping) 5(bottom speed mult) 6(number of trnsfer pts)
        Physics, Right, 370, -5, 0.52, 0.05, 0.55, 13,
                TransferPoint, 0.15,  -20,   175, 150,  0,  0,
                TransferPoint, 0.20,  -20,  190, 170,  0,  0,
                TransferPoint, 0.25,  -5,   220, 200,  0,  0,
                TransferPoint, 0.33,  -1,   350, 270,  0,  0,
                TransferPoint, 0.50,   1,   350, 300,  0,  0,
                TransferPoint, 0.58,   6,   350, 300,  0,  0,
                TransferPoint, 0.68,  12,   355, 320,  0,  0,
                TransferPoint, 0.76,  15,   350, 350,  0,  0,
                TransferPoint, 0.83,  19,   350, 320,  0,  0,
                TransferPoint, 0.86,  22,   245, 320,  0,  0,
                TransferPoint, 0.92,  35,   175, 270,  0,  0,
                TransferPoint, 0.95,  55,   100, 200,  0,  0,
                TransferPoint, 1.00,  60,    80, 150,  0,  0,
                Sound, Generic, GEN_SOUND_HIT_default
TableEnd = PBObject:FlipperRight

Table = PBObject:FlipperLeft
        EnablePhysics, DownAccel, DeflectionMod, LiveCatch, End,
                          //min speed   vector range       min % up to activate
        LiveCatchPhysics, 95.0,         0.35,              0.70,

                        //transfer of power based on how high up the flipper is from the bottom to top
        DeflectionModPhysics, .95, 1, 1, 1, 1, .99, .98, .97, .96, .95, .94,

        DownAccelPhysics, 0.7, 5, 12,

        UseSpecialRotation, True,

        Object, PB_OBJECTTYPE_FLIPPER, 2500,
        Switch, 12,
        DilPos, flipper A, 0,
        Models, 1, RSID_TFUNHOUSE_MODELS, 22,
        Lights, Def_Flippers,
        Collision, Mesh, 2, RSID_TFUNHOUSE_COLLISIONS, 1, RSID_TFUNHOUSE_COLLISIONS, 0,
        SwitchEOS, 2,
        EnvMapReflection, True,
        Vars, 2, 52.0, 78.0,

        //1(length) 2(angle speed down) 3(elasticity when flipper static) 4 (elasticity when dropping) 5(bottom speed mult) 6(number of trnsfer pts)
        Physics, Left, 370, 5, 0.52, 0.05, 0.55, 14,
                TransferPoint, 0.16, -20,   175, 150,  0,  0,
                TransferPoint, 0.20,  -20,  190, 170,  0,  0,
                TransferPoint, 0.20.5,-20,  240, 200,  0,  0,
                TransferPoint, 0.25,  -7,   280, 250,  0,  0,
                TransferPoint, 0.33,  -3,   350, 280,  0,  0,
                TransferPoint, 0.50,   1,   350, 300,  0,  0,
                TransferPoint, 0.58,   6,   350, 300,  0,  0,
                TransferPoint, 0.68,  12,   355, 320,  0,  0,
                TransferPoint, 0.76,  15,   350, 350,  0,  0,
                TransferPoint, 0.83,  19,   350, 320,  0,  0,
                TransferPoint, 0.86,  22,   245, 320,  0,  0,
                TransferPoint, 0.92,  35,   175, 270,  0,  0,
                TransferPoint, 0.95,  55,   100, 200,  0,  0,
                TransferPoint, 1.00,  60,    80, 150,  0,  0,
                Sound, Generic, GEN_SOUND_HIT_default
TableEnd = PBObject:FlipperLeft

Table = PBObject:FlipperUpperLeft
        Object, PB_OBJECTTYPE_FLIPPER, 2500,
        Switch, 12,
        DilPos, upper flipper L, 0,
        Models, 1, RSID_TFUNHOUSE_MODELS, 22,
        Lights, Def_Flippers,
        Collision, Mesh, 2, RSID_TFUNHOUSE_COLLISIONS, 1, RSID_TFUNHOUSE_COLLISIONS, 0,
        SwitchEOS, 2,
        EnvMapReflection, True,
        Vars, 2, 40.0, 78.0,

        UseAccurateLength
        UseSpecialRotation, True,

        //1(length) 2(angle speed down) 3(elasticity when flipper static) 4 (elasticity when dropping) 5(bottom speed mult) 6(number of trnsfer pts)
        Physics, UpperLeft, 350, 26, 0.5, 0.25, 0.3, 10,

                TransferPoint2, 0.13,  24,   110, 200,  0,  0,   220, 250,
                TransferPoint2, 0.20,  26,   220, 270,  0,  0,   250, 320,
                TransferPoint2, 0.24,  28,   290, 270,  0,  0,   250, 320,
                TransferPoint2, 0.35,  32,   340, 270,  0,  0,   280, 320,
                TransferPoint2, 0.55,  36,   360, 320,  0,  0,   295, 360,
                TransferPoint2, 0.77,  42,   370, 350,  0,  0,   320, 390,
                TransferPoint2, 0.86,  45,   335, 320,  0,  0,   285, 360,
                TransferPoint2, 0.92,  50,   285, 270,  0,  0,   245, 310,
                TransferPoint2, 0.98,  60,   220, 200,  0,  0,   200, 250,
                TransferPoint2, 1.00,  70,   140, 150,  0,  0,   140, 200,

//              TransferPoint, 0.12,  26,   155, 120,  0,  0,
//              TransferPoint, 0.15, 30,   250, 200,  0,  0,
//
//              TransferPoint, 0.25, 33.8,   345, 250,  0,  0,
//              TransferPoint, 0.35,  34,   345, 300,  0,  0,
//
//              TransferPoint, 0.355, 34,   345, 300,  0,  0,
//              TransferPoint, 0.40,  38,   345, 300,  0,  0,
//
//              TransferPoint, 0.405, 45,   345, 300,  0,  0,
//              TransferPoint, 0.65,  60,   345, 300,  0,  0,
//
//              TransferPoint, 0.655, 63,   275, 325,  0,  0,
//              TransferPoint, 0.90,  64,   135, 325,  0,  0,
//              TransferPoint, 1.00,  65,    80, 100,  0,  0,

                Sound, Generic, GEN_SOUND_HIT_default
TableEnd = PBObject:FlipperUpperLeft

Table = PBObject:VisibleLights
        Object, PB_OBJECTTYPE_LAMPSET, 2599,
        Pos, 0.0, 0.0, 0.0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        Models, 1, RSID_TFUNHOUSE_MODELS, 5,
        EnvMapReflection, True,
        Flags, zWrite, False, zTest, False, End,
        Lights, Def_LightCutouts,
        //cmd lampSet   lampNum  onOffset               offOffset               RSID                                                    Type (EmuLamp, EmuFlasher, Scripted)
        Lamp, 0,                6,                      1,                               0,                     RSID_TFUNHOUSE_LAMP_TEXTURES,         EmuLamp,
        Lamp, 0,                7,                      3,                               2,                     RSID_TFUNHOUSE_LAMP_TEXTURES,         EmuLamp,
        Lamp, 0,                0,                      5,                               4,                     RSID_TFUNHOUSE_LAMP_TEXTURES,         EmuLamp,
        Lamp, 0,                1,                      7,                               6,                     RSID_TFUNHOUSE_LAMP_TEXTURES,         EmuLamp,
[41 lines deleted]
        Lamp, 0,                46,                     115,                    114,            RSID_TFUNHOUSE_LAMP_TEXTURES,           EmuLamp,
        Lamp, 0,                47,                     117,                    116,            RSID_TFUNHOUSE_LAMP_TEXTURES,           EmuLamp,

        // hotdog flasher
        LampCombo, 0,   34,19,          155,180,                154,            RSID_TFUNHOUSE_LAMP_TEXTURES,           EmuCombo,
        // midnight flasher
        LampCombo, 0,   15,18,          29,181,                 28,                     RSID_TFUNHOUSE_LAMP_TEXTURES,           EmuCombo,
        // Dummy flasher
        Lamp, 0,                17,                     105,                    104,            RSID_TFUNHOUSE_LAMP_TEXTURES,           EmuFlasher,

TableEnd = PBObject:VisibleLights

Table = PBObject:VisibleBulbs
        Object, PB_OBJECTTYPE_LAMPSET, 2499,
[188 lines deleted]
        Physics, Elasticity,0.25, Friction,0.1, End,
        Switch, 64,
TableEnd = PBObject:TargetBlueB

Table = PBObject:TargetRed
        Object, PB_OBJECTTYPE_TARGET, 2500,
        DilPos, Target_Red,0
[306 lines deleted]
        LowModels, 1, RSID_TFUNHOUSE_REF_MODELS, 15,
        Vibrate, Solenoid, 0.2, 1.5, 40, End,
TableEnd = PBObject:PopBumper3

////////////////////////////////////////////gates
Table = PBObject:GateA
        Object, PB_OBJECTTYPE_GATE, 2500,
[347 lines deleted]
//      Vars, 8, 1237.0,0.0,1650.0,50, 1250,165,1415,60,
//TableEnd = PBObject:CameraTrigger

Table = PBObject:PlungerExit
        Object, PB_OBJECTTYPE_PLUNGER_EXIT, 1000,
        Pos, 0,0,0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        AffectPhysics, False,
        Vars, 9, 1368, -1006, 993,60,        1368, -1441, 974,60,               0
TableEnd = PBObject:PlungerExit

Table = PBObject:PlungerExitLeft
        Object, PB_OBJECTTYPE_PLUNGER_EXIT, 1000,
        Pos, 0,0,0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        AffectPhysics, False,
        Vars, 9, -1043, -992, 1018,60,          -1043, -2536, 974,60,           1
TableEnd = PBObject:PlungerExitLeft

// Environment
Table = PBObject:GenericEnvironment
        Object, PB_OBJECTTYPE_VISUAL, 150,
        Pos, 0.0, 0.0, 0.0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        EnvironmentModel, 0,
        Lights, Def_RubberPosts,
        EnvMapReflection, False,
TableEnd = PBObject:GenericEnvironment

Table = PBObject:GenericEnvironmentCeiling
        Object, PB_OBJECTTYPE_VISUAL, 150,
        Pos, 0.0, 0.0, 0.0,   1.0, 1.0, 1.0,   0.0, 0.0, 0.0,
        EnvironmentModel, 1,
        Lights, Def_generic_env,
        EnvMapReflection, True,
TableEnd = PBObject:GenericEnvironmentCeiling

// Target_Blue_B = 1
[57 lines deleted]
// Right_Eyelid = 1
// Chin = 1
 
Last edited:

Tann

New member
Apr 3, 2013
1,128
1
Wow, very instructive. As you said, it's even worse than what we supposed.

Thanks again.

What actually means "elasticity when flipper static" & "when dropping" in term of gameplay?
 
Last edited:

shadowjuggalo

New member
May 10, 2016
37
0
Well ill be damned, the trickery worked on me. I could of swore they fix the physics. it felt a lot better than when i first played. I was giving credit to farsight for doing a good job. i wonder what are the chances that bam will be able to change physics with xml.
 

Ben Logan

New member
Jun 2, 2015
505
0
Thanks so much for sharing the code-based evidence to confirm our suspicions regarding ramp vacuums and railroads. TPA is my favorite video game by far. And, with the announcement of SPA and Physics 4.0, this is our chance as consumers to strongly encourage Farsight away from TPA / SPA as video game toward TPA / SPA as genuine pinball simulation platform.

If Pro Pinball can pull off a physics algorithm that feels emergent / "ball is wild" with twenty year old code, a relatively larger company like Farsight (with tons of community support from Kickstarters, etc.) can create a physics set that rivals Pro Pinball's in terms of realism, if we respectfully push them in that direction.

I hear you, Shadowjuggalo: The "trickery" does work for a while. But once I started to really get into TPA, I felt like I was simply playing through a script. Once you make the realization that the ball is traveling predetermined ramp lanes and railroads, most of the satisfaction of "making a shot" disappears. Pinball is all about taming wildness. We need a wild ball!

I'm really thankful to Invitro and VikingEric for sharing their expertise. At some point, didn't someone suggest that the way to work around the 60hz refresh rate constraint is to decouple the visual experience of ball movement from actual simulated "real world" resolution (which would runs at infinitesimally smaller grain size), and to make a calculation about where the ball is supposed to go based on a re-coupling of these two data streams upon contact from flipper? Someone can explain this much better than me, obviously!
 

mmmagnetic

New member
May 29, 2012
601
0
I have had very little occasions where I could play real pinball, but the experience was definitely rather different from TPA, and the "wild ball" is a big part of that. On a real pinball, everything feels alive and energetic - and TPA absolutely feels scripted in two many places.

Thanks for posting this, very insightful!
 

Biff

New member
Sep 18, 2012
1,175
0
These days you don't have to build everything from scratch.
Most studios, smaller and bigger ones, use 3rd party game engines.
For example the Unreal Engine or Unity 3D.

See what one man has done in his spare time, by using the Unity 3D engine.
http://digitalpinballfans.com/showthread.php/11002-Elvis-Pinball-like-you-have-never-seen-it-before-have-a-look

This is another great Pinball simulator, it uses the Unreal Engine 4.
https://www.kickstarter.com/projects/1820215579/pinball-labs

A 3rd party engine could provide better physics and better optimization on multiple platforms.
I think the problem is, that Farsight is one of the few companies which doesn't want to pay royalty fees.
 

SilverBalls

Active member
Apr 12, 2012
1,233
3
These days you don't have to build everything from scratch.
Most studios, smaller and bigger ones, use 3rd party game engines.
For example the Unreal Engine or Unity 3D.

See what one man has done in his spare time, by using the Unity 3D engine.
http://digitalpinballfans.com/showthread.php/11002-Elvis-Pinball-like-you-have-never-seen-it-before-have-a-look

This is another great Pinball simulator, it uses the Unreal Engine 4.
https://www.kickstarter.com/projects/1820215579/pinball-labs

A 3rd party engine could provide better physics and better optimization on multiple platforms.
I think the problem is, that Farsight is one of the few companies which doesn't want to pay royalty fees.


Getting the physics right is not as easy feat. Muskuste was one individual who wrote the new VP10 physics - if I remember correctly he had a PHD or masters in maths and did an incredible job. Why on earth don't Farsight employ someone like him (or even him) - they approached that Pinmame fellow for the ROM emulation coding so do the same to get the physics rocking.

Another option is to licence the Pro Pinball algorithm. Imagine all those TPA tables with PP physics. Almost as good as sex that would be.
 

WhiteChocolate

New member
Apr 15, 2014
722
0
officially changing my sig today. ;)

p.s. reviewing those vids, neither of them much feature the ball-play physics - though some nice different takes on lighting style. i do like the lighting on the first link a lot!
 
Last edited:

Biff

New member
Sep 18, 2012
1,175
0
Getting the physics right is not as easy feat. Muskuste was one individual who wrote the new VP10 physics - if I remember correctly he had a PHD or masters in maths and did an incredible job. Why on earth don't Farsight employ someone like him (or even him) - they approached that Pinmame fellow for the ROM emulation coding so do the same to get the physics rocking.

Another option is to licence the Pro Pinball algorithm. Imagine all those TPA tables with PP physics. Almost as good as sex that would be.


Not saying that it's easy, but these engines provide better techniques / approaches to get physics "right" / better.
 
Last edited:

vikingerik

Active member
Nov 6, 2013
1,205
0
What actually means "elasticity when flipper static" & "when dropping" in term of gameplay?

We don't know, we can only guess.


If Pro Pinball can pull off a physics algorithm that feels emergent / "ball is wild" with twenty year old code, a relatively larger company like Farsight (with tons of community support from Kickstarters, etc.) can create a physics set that rivals Pro Pinball's in terms of realism, if we respectfully push them in that direction.

Thing is, I don't think Farsight is interested. They have no need to cater to an audience that cares about ball-is-wild physics. That's preaching to the choir. We're the addicts that are going to keep buying it if had the physics engine of Pong.

Farsight's median customer is the casual gamer who wants to pull pinball godhood out of their pocket. The super-wide transfer points and railroads are all positive for them. That's who they're serving, not us, and rightfully so as a business. These gamers don't care about wild physics to tease out the skill differentials between me and Tarek and Fuuta and Miwurdz. They care about pressing the right buttons to check off all their wizard goals, even if their skill level wouldn't earn that on a real table in a hundred years. Farsight occasionally throws us a bone like scattering the shot into the Ripley's temple, but it's never going to warrant the effort to build or port a proper emergent physics engine. Visual and Pro Pinballs got to where they are as labors of love, not of business.


I'm really thankful to Invitro and VikingEric for sharing their expertise. At some point, didn't someone suggest that the way to work around the 60hz refresh rate constraint is to decouple the visual experience of ball movement from actual simulated "real world" resolution (which would runs at infinitesimally smaller grain size), and to make a calculation about where the ball is supposed to go based on a re-coupling of these two data streams upon contact from flipper? Someone can explain this much better than me, obviously!

That was me, except now we're realizing that the 60hz refresh rate isn't the limiting factor. The transfer points are deliberately already wider than 1/60 second. I'm sure of this now, based on how some railroads occur more frequently than others. I always suspected that TPA's input resolution was coarser than 60 Hz, but never suspected it was so crude as to be deliberately coded into the flippers that way.
 
Last edited:

Jeff Strong

Moderator
Staff member
Feb 19, 2012
8,144
2
I've often wished Farsight would've tried to license Pro Pinball's physics engine early on. Seems like it would've been a win/win for both studios.
 

WhiteChocolate

New member
Apr 15, 2014
722
0
That was me, except now we're realizing that the 60hz refresh rate isn't the limiting factor. The transfer points are deliberately already wider than 1/60 second. I'm sure of this now, based on how some railroads occur more frequently than others. I always suspected that TPA's input resolution was coarser than 60 Hz, but never suspected it was so crude as to be deliberately coded into the flippers that way.

i'd been thinking about the 1/60 "rule", if there is a "there" there... that might explain why a crude schlub like me can make some shots almost every time over and over; if i do a "hold/flip" then i often get it about on the dot every time, even without feeling like i'm catching a train (though it seems of course it must be there in the first place). get that micro-dot timing down, and you will hit the same shot most every time - i suppose this is something most pros expect off of playing real tables!

in scared stiff, if i hit the left "snake" loop, i often find my right fing almost involuntarily doing a "test-flip" in-between as the ball makes its way down around the loop; seems like my brain and fing are trying to keep a timing thing going on - if i don't do that, then my chances of hitting the left-snake ramp again off the right flipper are way reduced (since it's coming down too fast to do a catch). some similar things on different tables; i "flip" even without a ball right there to flip off, just trying to keep some timing-thing going in my head as the ball comes round back to me. timing is everything... it -is- nice to feel a bit of symmetry between handhelds and console in that regard, though there's always an intrinsic diff kinda going on. but some of that rr-ing (especially that catapult trap in MM; i often see the ball literally move out of place to get caught into it) is rather jarring! would be nice if that kinda stuff got smoothed out...
 

Biff

New member
Sep 18, 2012
1,175
0
p.s. reviewing those vids, neither of them much feature the ball-play physics


Unreal Engine 3 and 4 are in use for countless tripple A games, also simulators and computer science programs.
These 4 Farsight programmers (one "engine guy") could never write anything that is as sophisticated as the unreal engine.
https://www.unrealengine.com/education

needless to say, Unity 3D is also very powerful.
 
Last edited:

soundwave106

New member
Nov 6, 2013
290
0
At some point, didn't someone suggest that the way to work around the 60hz refresh rate constraint is to decouple the visual experience of ball movement from actual simulated "real world" resolution (which would runs at infinitesimally smaller grain size), and to make a calculation about where the ball is supposed to go based on a re-coupling of these two data streams upon contact from flipper? Someone can explain this much better than me, obviously!

Be careful with this. I looked for the Visual Pinball source for any signs of interpolation of any sort, and couldn't find any. I don't know the default VP10 refresh rate (which determines frame calcs) and I went really quickly through a heck of a lot of source, so I could've missed it. But VP10 might be doing a fantastic job without needing any sort of in-between calcs whatsoever.

At the moment, at any rate, I personally don't think the 60Hz rate has anything to do with it. It's all about what is described as "railroading". There's some shot adjustments / helpers going on in the engine, that much is obvious. There is a definite goal / scope is to attract casual players, of course, so unless Farsight decides a "expert mode" without these helpers is worth it, ya gets what ya get.
 

Ben Logan

New member
Jun 2, 2015
505
0
We don't know, we can only guess.

Thing is, I don't think Farsight is interested. They have no need to cater to an audience that cares about ball-is-wild physics. That's preaching to the choir. We're the addicts that are going to keep buying it if had the physics engine of Pong.

Farsight's median customer is the casual gamer who wants to pull pinball godhood out of their pocket. The super-wide transfer points and railroads are all positive for them. That's who they're serving, not us, and rightfully so as a business. These gamers don't care about wild physics to tease out the skill differentials between me and Tarek and Fuuta and Miwurdz. They care about pressing the right buttons to check off all their wizard goals, even if their skill level wouldn't earn that on a real table in a hundred years. Farsight occasionally throws us a bone like scattering the shot into the Ripley's temple, but it's never going to warrant the effort to build or port a proper emergent physics engine. Visual and Pro Pinballs got to where they are as labors of love, not of business.

You may be right, Vikingerik. The optimist in me, however, is holding out for Pro Pinball or better physics in this next iteration. People are playing more real pinball since TPA's launch. The general public seems increasingly fascinated with anything real and mechanical as opposed to digital (e.g. vinyl!). Barcades with real pins are cropping up everywhere. My guess (hope) is that with SPA we're going to witness a shift in values: one that prioritizes realistic emulation over quick-gratification that comes with railroads and vacuums, in accordance with the public's interest in realia.

Jeff Strong -- Yes! I'd love to see SPA employ Pro Pinball licensed physics. Zaccaria (Magic Pixel / Ask Homework) has amazing physics too. Both feel appropriately wild, yet responsive to player effort to learn "where on the flipper" shots can consistently be made.

Soundwave106 -- brilliant idea with Expert Mode. Let the casual player enjoy the illusion of quick "pinball wizardry." Pinheads like us (if I may use the term) can pay a few bucks extra to unlock emergent "ball is wild" physics. Blahcade podcast even recommended tuneable physics (slope, friction, etc.). Zaccaria ME lets you tune physics on iOS and will support this feature on the Steam release.

Come on, Farsight. For the love of the game!
 
Last edited:

Snorzel

New member
Apr 25, 2014
1,353
0
The 2 biggest gripes I have with the current state of TPA physics are the seemingly impossible shots on some tables from a stoped ball, and the lack of spin. Incorporating spin would help tons with perception of randomness IMO

Great topic, this thread is a very interesting read.

Big +1 for "expert mode", I want a simulator to practice for the real deal!
 

Ben Logan

New member
Jun 2, 2015
505
0
Agreed: Many shots are way too easy (vacuum suck / railroad return to flipper), other shots are seemingly "unavailable" from cradle position. We need vastly increased resolution of flipper/ball contact points upon flip.

Re: Ball Spin. I play VP10 daily and love the community. I don't gripe about physics over there out of respect for the volunteer nature of the scene. That said, many of us feel the ball spin, while an essential part of realism, is just way too much in VP10. The ball takes lots of strange lateral archs and curveballs that only happen occasionally at really high speeds on newer real Sterns in my experience. I dial down gravity and table friction to compensate, but this introduces new undesirable effects like floatiness if it's overdone. Tough to get a balance!

I'd love to see ball spin incorporated in SPA / TPA, but at a lesser degree of intensity than the VP10 model.

Snorzel - What do you think of ball spin on Zacc?
 

vikingerik

Active member
Nov 6, 2013
1,205
0
The 2 biggest gripes I have with the current state of TPA physics are the seemingly impossible shots on some tables from a stoped ball

These were fixed a few months ago, at least on PC. All the impossible shots we brought up here were made possible. And I see now exactly how that happened, by adding/subdividing those flipper transfer points. It's noticeable that even these fixed shots are still difficult, and that's because they still have a tight timing window since there's only so much range available to carve out from preexisting transfer points.

Big +1 for "expert mode", I want a simulator to practice for the real deal!

You have to go play Pro Pinball for that, you won't find it in TPA or Zen.

Pro Pinball makes me better on real machines. TPA makes me worse.
 

Members online

Members online

Top