Breakout: Improving Paddle Physics

Now that our paddle is setting the velocity of our ball in response to the collision, having our ball's bouncing logic also trigger as a result of that collision may cause some conflicting interactions.

We can prevent our Ball from reacting to Paddle collisions, but continue to react to other collisions, by returning early if it detects the Other entity is the paddle:

1// ...
2#include "Paddle.h"
3
4void Ball::HandleCollision(Entity& Other) {
5  if (dynamic_cast<Paddle*>(&Other)) {
6    return;
7  }
8  // ...
9}

With these changes, we can now exhibit some control over the ball's movement by bouncing it off different parts of our paddle:

In our current implementation, we can possibly create a situation where the ball collides with our paddle multiple times in quick succession. This is more likely to happen if the ball hits the side of the paddle, whilst the paddle is also moving towards the ball.

This is a relatively common problem in physics systems, and we can address it by disabling a collider for a brief moment after it hits something.

The ability to "disable" a component is quite useful in general, so let's add this capability to the base Component class in our Engine/ECS directory.

Adding isEnabled to Component

To support this feature, we'll add a private isEnabled value, defaulted to true, alongside getters and setters:

1// ...
2
3class Component {
4 public:
5  // ...
6
7  void SetIsEnabled(bool Enabled) {
8    isEnabled = Enabled;
9  }
10  
11  bool GetIsEnabled() const {
12    return isEnabled;
13  }
14
15private:
16  // ...
17  bool isEnabled{true};
18};

Disabling Collision Components

Classes that derive from Component can now decide how they should act when they have been disabled. We'll implement this for the CollisionComponent in this section and for some more components later in the project.

The most important effect of a collision component being disabled is that it should no longer result in HandleCollision() calls being made.

This logic is currently implemented in our Scene.cpp file, so let's update it:

1// ...
2
3void Scene::CheckCollisions() {
4  for (size_t i{0}; i < Entities.size(); ++i) {
5    CollisionComponent* ColA{
6      Entities[i]
7        ->GetComponent<CollisionComponent>()};
8    if (!ColA) {
9    if (!(ColA && ColA->GetIsEnabled())) {
10      continue;
11    }
12
13    for (size_t j{i+1}; j < Entities.size(); ++j) {
14      CollisionComponent* ColB{
15        Entities[j]
16          ->GetComponent<CollisionComponent>()};
17      if (!ColB) {
18      if (!(ColB && ColB->GetIsEnabled())) {
19        continue;
20      }
21
22      if (ColA->IsCollidingWith(*ColB)) {
23        Entities[i]->HandleCollision(
24          *Entities[j]);
25        Entities[j]->HandleCollision(
26          *Entities[i]);
27      }
28    }
29  }
30}
31
32// ...

Updating some behaviors in the CollisionComponent class may also be warranted, but it's less obvious what should happen there. For example, if the component stops ticking, that means its position stops updating, and functions like GetCenter() will report the wrong value.

We could update a function like IsCollidingWith() to always return false if the component is disabled, but that may also be unintuitive.

However, it does seem safe to at least update DrawDebugHelpers() to represent the component being disabled. Previously, it was always rendered in yellow. Let's update it to render in orange when it is disabled:

1// ...
2
3void CollisionComponent::DrawDebugHelpers(
4  SDL_Surface* Surface
5) {
6  SDL_Color Yellow{255, 255, 0, 255}; 
7  SDL_Color Orange{255, 165, 0, 255}; 
8  auto [r, g, b, a]{ 
9    GetIsEnabled() ? Yellow : Orange 
10  }; 
11  Uint32 Color{SDL_MapRGB(Surface->format, r, g, b)}; 
12  
Remaining Code (Unchanged)|Show
34}
35
36// ...

Back in our Paddle class, we can now simply call this function when we want to disable or enable collisions. Let's disable them when a collision happens, and we'll work on enabling them again a few moments later in the next section:

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  void HandleCollision(Entity& Other) override {
8    // ...
9    Collision->SetIsEnabled(false);
10  }
11  
12  // ...
13};

We should now see our paddle's collider rendering in orange after a collision:

To enable collisions after a brief pause, let's use the SDL_Timer techniques we covered earlier in the course.

We'll start by ensuring SDL's timer functionality is included in our SDL_Init() call:

1// ...
2
3int main(int argc, char** argv) {
4  SDL_Init(SDL_INIT_VIDEO);
5  SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER);
6  
7  // ...
8}

To set a timer, we pass three arguments to SDL_AddTimer():

1. The interval, in milliseconds
2. A function pointer that we want to invoke at the end of the timer
3. A pointer to some data we want to pass to the callback function. This argument is a void pointer (void*) so we can pass a pointer to anything, or a nullptr if we don't need any additional data.

Let's set a timer to enable our collisions after 500 milliseconds. We'll implement this behavior in a function called Paddle::EnableCollision, and we'll pass a pointer to ourselves (this) as the final argument.

We'll need the timer ID returned by this function later, so let's save it as a member variable:

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  void HandleCollision(Entity& Other) override {
8    // ...
9    Collision->SetIsEnabled(false);
10
11    TimerID = SDL_AddTimer(
12      500, &Paddle::EnableCollision, this
13    );
14  }
15
16private:
17  // ...
18  SDL_TimerID TimerID{0};
19
20  static Uint32 EnableCollision(
21    Uint32 Interval, void* Entity
22  ) {
23    Paddle* Target{static_cast<Paddle*>(Entity)};
24    // Memory issue here - see next section
25    if (Target && Target->Collision) {
26      Target->Collision->SetIsEnabled(true);
27    }
28
29    return 0;
30  }
31};

The callback we pass to SDL_AddTimer() must be a plain function pointer that returns a Uint32 and accepts Uint32 and void* arguments.

• The return value allows us to repeat the timer by passing the next interval, which will cause the function to be invoked again after that many milliseconds. We can pass 0 if we don't need the timer to repeat, which is what we want in this case.
• The Uint32 parameter is provided with the current interval, which is 500 in our example. We don't need this value so we'll just ignore it.
• The void* parameter is the pointer we passed to SDL_AddTimer(), so it is the pointer to our Paddle instance.

The function passed to SDL_AddTimer() must be a plain function pointer, not a member function pointer. However, we can use a static member function:

1// ...
2
3class Paddle : public Entity {
4  // ...
5private:
6  // ...
7
8  static Uint32 EnableCollision(
9    Uint32 Interval, void* Entity
10  ) {
11    return 0;
12  }
13};

To enable our collider from this function, we need to cast the void pointer to a Paddle*, and then call SetIsEnabled() on its collision component.

Note that the following code isn't memory-safe. We'll explain why and fix it in the next section:

1// ...
2
3class Paddle : public Entity {
4  // ...
5private:
6  // ...
7
8  static Uint32 EnableCollision(
9    Uint32 Interval, void* Entity
10  ) {
11    Paddle* Target{static_cast<Paddle*>(Entity)};
12    // Memory issue here - see next section
13    if (Target && Target->Collision) {
14      Target->Collision->SetIsEnabled(true);
15    }
16
17    return 0;
18  }
19};

With these changes, our paddle's collider should now renable 500 milliseconds after the collision:

Fixing Timer Issues

When working with asynchronous code such as timers, we should be more mindful of things that can go wrong. Whilst synchronous code typically only needs to worry about the state of the program right now, asynchronous code needs to consider what might happen between us setting up the timer, and that callback being invoked in the future.

For example, what if HandleCollision() is called a second time, whilst our timer is still running? Our callback is still going to be called on its original schedule, meaning collisions will be reenabled again sooner than we intended:

This second collision is not currently possible in our program - HandleCollision() is only called by Scene, and Scene will not call it if the collision component is disabled.

However, we can still be safe and ensure Paddle() is internally consistent. HandleCollision() is a public function, so we should be prepared for external code to call it at any time. To handle this situation more gracefully, when HandleCollision() is called, we can cancel the existing timer, if there is one

In code, it might look like this:

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  void HandleCollision(Entity& Other) override {
8    // ...
9    Collision->SetIsEnabled(false);
10
11    if (TimerID != 0) {
12      SDL_RemoveTimer(TimerID);
13    }
14
15    TimerID = SDL_AddTimer(
16      500, &Paddle::EnableCollision, this
17    );
18  }
19
20  ~Paddle() {
21    if (TimerID) {
22      SDL_RemoveTimer(TimerID);
23    }
24  }
25
26  // ...
27};

Memory-Safe Timers

The second thing we should be mindful of is the state of our program at the time the callback is invoked. What state could our paddle be in? Does the paddle even still exist?

Currently, our paddle remains alive for the duration of our program, but we'll be changing that soon. If the paddle is deleted between the timer starting and the callback being invoked, the void* the callback receives will be a dangling pointer.

To address this, we should also remove our timer when the paddle is destroyed:

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  ~Paddle() {
8    if (TimerID) {
9      SDL_RemoveTimer(TimerID);
10    }
11  }
12
13  // ...
14};

Rule of Three

Now that we've intervened in the object destruction process, the rule of three should prompt us to consider whether we need to intervene in the copying process, too. Will our paddle objects be compatible with the default copy behavior?

Unfortunately, they won't, as copies will have the same TimerID as the original object. This means that paddle objects risk calling SDL_RemoveTimer() for timers that they did not create, and aren't responsible for managing.

In our case, we don't need to fix this, because we don't need paddles to be copyable. So instead, let's make that explicit by deleting the copy constructor and copy assignment operators:

1// ...
2
3class Paddle : public Entity {
4public:
5  // ...
6
7  Paddle& operator=(const Paddle& Other) = delete;
8  Paddle(const Paddle& Other) = delete;
9
10  // ...
11};

Complete versions of the files we created in this lesson are below:

In this lesson, we significantly improved our game's physics and interactivity. We implemented logic that allows the paddle to control the ball's direction, turning simple bounces into skillful shots.

We also built a robust system for handling rapid collisions by temporarily disabling the paddle's collider using an SDL timer, and we discussed the memory safety considerations that come with asynchronous code.

Key takeaways from this lesson include:

• Gameplay depth can be added by implementing nuanced collision responses.
• Calculating the relative position of two colliders is key to determining how they should interact.
• A generic isEnabled flag on components is a flexible way to manage their state.
• SDL timers are useful for creating delayed actions, like re-enabling a component.
• When using timers or other asynchronous callbacks, it's crucial to manage resource lifetimes and prevent dangling pointers, often by following the Rule of Three/Five.