SDL Collision Events

August 4th, 2009 by Tim Jones Leave a reply »

Finally! The next tutorial. This is the 2nd part to the SDL Collision tutorial. We’ll be looking at collision events, the part we left unfinished in the last tutorial. To refresh your memory, a collision event is an event that is stored in queue after a collision has taken place. Take our recent shooter contest for an example. When the player fires a bullet, the bullet flies through the air, and then hits the enemy. The moment the bullet and the enemy collide, an event is triggered and stored in the queue. After all movement has taken place, the queue is iterated through, and events can appropriately respond.

So lets get started. Open up your project from the last tutorial. We’re first going to make a few prelimary changes. Make a new file called CEntityCol.cpp. Inside that file, put the following:

#include "CEntity.h"

std::vector<CEntityCol> CEntityCol::EntityColList;

CEntityCol::CEntityCol() {
    this->EntityA = NULL;
    this->EntityB = NULL;
}
 

Now, get rid of that code from CEntity.cpp. I am basically moving the code to its own file so that everything is much neater. The second thing. Open up CEntity.h and change:

virtual void OnCollision(CEntity* Entity);
 

To this:

virtual bool OnCollision(CEntity* Entity);
 

Also, change the void to bool in CEntity.cpp, CPlayer.h, and CPlayer.cpp. Why the change? Well, you’ll see in a minute. ;)

We’re already storing the collision events in a queue, now we need to do something with them. Open up CApp_OnLoop.cpp. You’ll notice we already have a loop going for entities and we’re calling OnLoop. We’re basically going to do the same thing again, but after our first loop:

for(int i = 0;i < CEntity::EntityList.size();i++) {
    if(!CEntity::EntityList[i]) continue;

    CEntity::EntityList[i]->OnLoop();
}

//Collision Events
for(int i = 0;i < CEntityCol::EntityColList.size();i++) {
    CEntity* EntityA = CEntityCol::EntityColList[i].EntityA;
    CEntity* EntityB = CEntityCol::EntityColList[i].EntityB;

    if(EntityA == NULL || EntityB == NULL) continue;

    if(EntityA->OnCollision(EntityB)) {
        EntityB->OnCollision(EntityA);
    }
}

CEntityCol::EntityColList.clear();
 

Not much going on here. We’re first iterating through every event in the queue. We then grab the two entities involved (EntityA, and EntityB), and we make sure they are valid pointers. If so, we first tell EntityA that it has collided with EntityB by calling OnCollision. Now, this is where that void to bool change comes in. EntityA can choose to prevent EntityB from knowing it has collided with him. If you remember, only Entities that are moving check for collision. This would mean EntityA is definitly a moving entity, and EntityB may or may not be moving.

Here’s an example to explain why you wouldn’t want to waste time calling EntityB’s OnCollision. Say you fire a bullet, and it hits a rock entity. Now, lets say the rock has a flag stating it’s indestructable. Our rock doesn’t care its been hit. So, when the OnCollision is called for the bullet, the bullet can see the entity it has hit is indestructable. And because of that, it can create a little “bullet being destroyed” animation, and then we can ignore telling the rock about it.

This is about the extent of entity collisions. So, now that we have this base, lets do something semi-useful with it.

Open up CEntity.h and add this new function, and variable:

protected:
    bool    CanJump;

public:
    bool    Jump();
 

Then, open up CEntity.cpp, and add the Jump function. Also make CanJump = false in the constructor:

CEntity::CEntity() {
    CanJump = false;

    // … Other code …
}

bool CEntity::Jump() {
    if(CanJump == false) return false;

    SpeedY = -MaxSpeedY;

    return true;
}
 

Finally, go to the OnMove function. We’re going to figure out when our entity is allowed to jump. An entity is allowed to jump whenever it is touching the ground – or, in other words, whenever the entity is no longer moving on the positive Y-axis. So, at the top, we are first always going to reset CanJump to false:

CanJump = false;
 

Now, go down a bit, and modify the PosValid for the Y-axis to the following:

if(PosValid((int)(X), (int)(Y + NewY))) {
    Y += NewY;
}else{
    if(MoveY > 0) {
        CanJump = true;
    }

    SpeedY = 0;
}
 

Now, to run through everything we did. First, we have a flag that states if an entity can jump. When set to true, we are allowed to call the Jump function. This CanJump variable is always false, unless our feet are on the ground. Whenever we actually do want to jump, we simply set our SpeedY in the negative Y-axis direction (up). Remember, gravity is always pushing us down, but at a slow speed. So, if we have a SpeedY of -5, and a AccelY of 0.75, we’ll move up for a time, gravity will kick in, and then we will eventually be pushed back down. Thus, giving the effect of a real jump. The trick here is to get the Speed and Acceleration variables just right.

Also, as a side note, the reason we made Jump return true/false is simply for informational purposes. Meaning, when a key is pressed by the player to jump, they won’t always be allowed to jump. And, if you wanted, you could do something based upon what Jump() returns.

So a few more tweaks before we try this out. In the constructor of CEntity, change the MaxSpeedX and MaxSpeedY to 10. Then, open up CApp_OnEvent.cpp and add the following to OnKeyDown:

case SDLK_SPACE: {
    Player.Jump();
    break;
}
 

And one last thing. Open up CPlayer.cpp, and change the OnCollision function to this:

bool CPlayer::OnCollision(CEntity* Entity) {
    Jump();

    return true;
}
 

That’s it! Compile, run, and have fun with Yoshi jumping all over the place. You’ll notice the simple collision event we added is that when Yoshi 1 collides with Yoshi 2, it causes Yoshi 1 to jump. Kind of lame, but you should get the idea.

SDL Collision Events – Tutorial Files:
Win32: Zip, Rar

Share and Enjoy:
  • Digg
  • del.icio.us
  • DZone
  • MisterWong
  • Reddit
  • StumbleUpon
  • Technorati
  • Slashdot
  • LinkedIn
  • MySpace
  • Yahoo! Buzz

Did you like this tutorial/blog post? Feel free to donate to keep more comin', and have more contests.

Advertisement

26 comments

  1. Tim Jones says:

    Kyle,
    You’re welcome. Good luck!

    Timo,
    Nice name. There is really no different “types” of SDL, but there are different implementations of SDL. When it comes to the C/C++ implementation (which both this website and LazyFoo uses) there is no difference. The most obvious differences between our tutorial websites is that LazyFoo codes in C (procedural), and I code in C++ (OOP). Thus, when LazyFoo lays out some code everything uses structs, and separate functions, while I heavily focus on classes and objects. We both use SDL though, we both use SDL_Surface, SDL_Event, SDL_SetVideoMode, etc. – we simply structure the rest of our code differently. I hope this makes sense. I added you to my buddy list.

  2. Timo says:

    Hi Tim
    I was wondering if there are different types of sdl, cause i was learning in this page http://lazyfoo.net/SDL_tutorials/lesson07/index.php, and i did not recongnize anything that i learned. And just one last favour, if you could add me Timocin_333@hotmail.com i just have som minor questions if you could answer i promise i wont bother u much :)

  3. Kyle says:

    Hey Tim,

    Just wanted to say thanks for the awesome tutorials! My school isn’t offering a class on C++, but with some decent knowledge in C and Java and with your help with these lessons, I think I have a good handle on how to start developing with the language.

    Thanks a bundle man! Clean, clear and simple, your work is just extraordinary!

  4. Tim Jones says:

    Aniol,
    I’ve actually had quite a few requests for an isometric tutorial. So yes, I will do one in the future.

    Regarding Tile Types, you are encouraged to add your own types and to modify the OnMove/Collisions section according to types. For example, an ice type would cause an entity to slide after they stopped.

  5. Aniol says:

    Hey Tim,

    I need to know how to solve a little problem. Your tutorials don’t say nothing about the isometric screen. I mean, for example, the screen/surface you use is more likely for a game like Mario, but how about RTS, Adventure games like Zelda…
    I was wondering if you know how to programm an isometric screen, and if you could do a small tutorial about it… it would be really helpful.

    And another thing.. for now, we have learned to paint tiles but just 2 different tipes. I thought of adding some more tipes, you know, land, water, rock, ground…

    Well, thats all for now, I hope you’re all right

    I’ll look forward for your answer!

    Thanks!

  6. Tim Jones says:

    Aniol,
    Of course I’ll do more tutorials. Regarding Age of Empires, or more generally, an RTS, you have a basis started from these tutorials already. One thing you won’t need is gravity of course, and when entities collide they don’t need to stop (still report the event). You should look into pathfinding (like A* pathfinding [pronounced A-star]), and then figure out how to tell an entity, or unit, to move to X,Y and using pathfinding.

    Antoni,
    Thanks.

  7. Antoni says:

    Tim, with your tutorials in 5 days I have learned how to make my own games! Thanks and continue doing so good tutorials.

  8. Aniol says:

    Hey, I’m trying to programm an Age of Empires.. I just wanna know if you will do more tutorials. And if you had any idea of programming anything like an “Age”.

    And this site is really useful, I’m learning a lot! thanks!

  9. Tim Jones says:

    Badut,
    Thanks!

  10. Badut says:

    Hey Tim, only just skimmed through it but it looks like a great tute as always. Busy putting the finishing touches for the contest but I’ll go through this tute thoroughly soon ;)

Leave a Reply