Examples:

1. ScrollAndZoom:
• Left-Thumb-Stick to scroll around the world
• Right-Thumb-Stick-X to zoom in/out (what is the reference position)? Can you change the reference?

 

2. Zoom with respect to world center:
• Controls are identical to above
• Math: simple!
  • user changes: WorldWidth
  • SetWorldCoordinate(Org, WorldWidth)
  • Notice how we use the AspectRatio to compute new height!!
  • We need to compute Org such that WorldCenter does not change
  • Org needs to be move by half of new worldsize change

 

3. The Camera Class:
• A fake class!! (because we cannot instantiate more than one of these!). A simple wrapper over XNACS1Base.World.
• A/B Button: to zoom in/out, notice:
  • GamePad.Buttons.A, returns the current state of Button-A
  • In this example, we poll the current state of a button and perform operation accordingly
  • Make sure you understand the difference between this "state polling" and "event testing" of: GamePad.ButtonAPressed()
• Left Thumb Stick:  to move the camera, notice, as the soccer balls gets to the boundary of the camera view, you can't move the camera anymore! (More about this later)
• Right Thumb Stick: to move the soccer ball. Notice as the soccer ball gets to the boundary, it "pushes" the application window. Here, the logic in our code makes sure the camera view always sees the soccer ball. (Camera Safe Zone).
• Function: MoveCamera() - trivial offset of WorldCoordinate origin.
• Function: ZoomBy() - changes the width of the camera view, exactly the same functionality as previous example, just we hide this in a class.
• Function/Attribute: SafeZonePercentage/KeepPointInSafeZone()
  • "Safe Zone" is something I kind of invented, this is the area where you want important positions to stay within. E.g., if your hero moves beyond "Safe Zone", you will update your camera to "chase after it".
  • By default, I define my "Safe Zone" as 90% of the world size. Whatever works for you.
  • KeepPointInSafeZone(): computes input position, makes sure the position is within 90% of camera view.
  • The reason why we cannot "move" our camera to outside of the soccer ball with LeftThumbStick is because KeepPointInSafeZone() stops us!
     
4. Roll a ball and scroll the world:
• Left Thumb-Stick-X: to zoom with-respect-to center
• Right Thumb-Stick: to change ball velocity
• Small and Large ball rotates at different rate that obey the speed (same speed, different rotation rate!)
• RollingBall: class. notice:
  • FrontDirection is tied to RotateAngle, and it is UNUSABLE!!
  • Update: angular displacement theta =  Speed/R, and remember to convert to degree for RotateAngle
• Notice: Easy to use with abstraction ... the camera class.
   
5. Simple fake physics:
   • Left Thumb-Stick: Set initial velocity
   • Right Thumb-Stick X: to change "fake" friction
   • Right Thumb-Stick Y: to change "fake" collision elasticity
   • A-Button: To shoot the soccer ball with the velocity defined by LeftThumbStick
   • Press-A to observe:
     • Gravitation pull effect: continuously decrease y-velocity by a constant (deceleration).
     • Complex condition for the ball to stop motion!
     • onTheFloorHeight: slightly higher than the ball radius
     • Notice: the ball is the "RollingBall" from above, where rotation is controlled by VelocityX only (instead of Speed)
   • Friction:
     • apply only when ball is in contact with the floor (<onTheFloorHeight). 
     • Scale the current velocity by "frictional force": here we say, the faster you travel, the more friction you encounter. May be true? may not be true. Whatever. Looks cool.
   • Elasticity:
     • How much "energy" (speed) is lost at a collision.
     • Again, we scale: you lost a "proportion" of your energy/speed.
     • How accurate? Well, it looks cool.
   • Question: How come with elasticity of one, the soccer ball's y-velocity will go to zero? Great question!!
      
6. Fake physics with class:
   • Identical to the above except: FakeCollisionPhysics class. Disgustingly simple!?
     • onTheFloorHeight: define as a function of the radius (5%)
     • If circle penetrated the floor, fix the velocity (to avoid jumping out of control when Elasticity is 1)
     • Only process the circle if it HasNonZeroVelocity().
   • FakeGravity: a global singleton class.
   • Ball.Update():
     • Do not test with WorldBound.Floor anymore (FakePhysics takes care of this).
        
7. MP2 style Simple Colliding Planks:
   • SolidPlank class. Knows how to collide with circles.
   • Button-B: re-builds the planks.
   • Very simple (from MP2), no problem?!
      
8. Planks with fake physics:
   • SolidBlockWithPhysics: Integrate FakeCollisionPhysics.Update() into SolidBlock.Update
     • "Push out" is the same
     • Include check for zero velocity (in the N direction and T direction)
     • And re-compute circle velocity accordingly
   • Button-B: to randomly create the 5 planks
   • Button-X: to select a plank to change elasticity and friction.
   • Left/Right Triggers: to rotate the current selected plank
   • Problems:
     • Collide from the bottom "sticks": when Elasticity is very small
       • SolidBlockWithPhysics.Update() does not push the circle "far out enough"
       • In subsequent Update(), collided(circle) returns true
       • velocity_N is scaled to almost zero and set to zero!
         
     • If ball moving right-ward, collide with right-side of block, ball may bounce "backwards towards the left-side".
       • This can happen on all 4 sides of the block
       • should check collision side and current velocity direction
     • Resting position sometimes "above" the actual block

      

9. Gravity and Parabolic Freefalll: ignore if you want. This is to show, math and physics actually works. But too tedious for us to care.
   • Right-Thumb-Stick: to change the initial projectile velocity
   • A-Button: to initial the projectile motion
   • To compute gravitational pull, in each update we must:
     1. Update position by Velocity
     2. Update Velocity by Acceleration (VelocityY by gravity)
   • Notice the order of operation is important because the library always travels the primitives before calling the UpdateWorld() function:
     • Red projectile trace: shows velocity is changed before position computation
     • Green projectile trace: shows position is updated before velocity is updated (what the library implements).
   • Notice the computeTargetPosition() function:
     • Our unit is in "Number of Updates"
     • Takes the center of an update (by adding 0.5 to the tmToHitYMax)
     • add 0.5f when computing the initial y-displacement because position is changed before the UpdateWorld() function call.
   • Remember first day of class?
     • I said we don't care about the order of the updates? Well, I lied!
     • We don't care unless we care about any kind of "real math/physics"!!
     • Do we care about math and physics?
     • Is the Red-Path more correct or the Green-path? Do you care?
     • Answer: whichever one looks better! So: the same! So, we don't care about "real physics", not in this case/class.

      

10. Collision and Conversation of Energy:
• A-Button: to shoot the hero towards the target
• B-Button: randomize the target
• Right-thumb-X: controls the hero radius
• Right-thumb-Y: controls the hero speed
• The CircleWithMass class:
  • Use area as mass (PI*R*R)
  • When collide with another circle with Mass, resolves velocity correctly in preserving kinetic energy and normal-direction momentum.
• ClassExample::ComputeHeroVDirection(): use hero Speed and Target velocity to compute a hero velocity such that hero will collide with target somewhere in the future. Here is the math, code, and detailed explanation of the implementation.