The Door Class and Level Collision

So don’t be afraid there the last post was about this and it was not the working copy which I will now tell you about.

Yes the Door and level collision is fixed and now I will tell you how I with some help did it!.

First of the Level collision:

So after gaining help from a brilliant friend we used the debug tool to look over every part of the code that involved the collision between the player and the map.

What we interestingly found out was that the reason the collision did not work was because we used the sprites sf::sprite->getGlobalBounds(). For you who do not know what this is. It’s a rectangle that follows the sprites every rotation and rotates with the sprite.

The problem with this are 2 things

1: The update of the sprite and the rotation don’t really occur at a 100% same time. Some nano seconds or something between.
2: My collision function. So I made a simple collision check since the pixel perfect code was WAAAAAY over my head. The collision now works so that if you are walking into a collision you return to the previous position.

When those two are combined you get it so that the sprite can wiggle into the collision area and then when it moves back it moves into the collision area and that’s when the you get stuck and everything goes wrong.

The door class in LevelManager:

How the door class work in combination of the LevelManager.

First we use the doors Structs and Enum to read in the maps and give the Tile a sprite and a flag as I have done with the others.

If you look closely at the flag you clearly notice that I have a DOOR_LEFT and right things in the enum IGNORE THAT! It was a failed a tempt and bad thinking and should never be mentioned in a conversation! Caprice?!
‘c’ ‘126’ ‘123’ ‘(flag number) 7′
after that I added strings, those are used for the direction the door opens.
”left”, ”right” , ”up” and ”down”
the last thing that was added to the text document are the two int’s at the end. They are there to tell what map is to be loaded at the end.
1 1
So after this is done we check the square that is called DOOR_EXIT and see what it contains. In the first case it’s a left door and the next map is 2 0
We then create a door class at that point and send in the coordinates that the tile has, the way the door will open and the next map coordinates.

as this is done we also have created a sf::vector m_doorCol;

In this we save the collision box for the doors. It’s done this way for reasons.

Door Class

The door class inherits the public variables from the sprite class.

Why? because the only thing that the door will do is to create the doors and then make the doors move. Also before we changed it the doors would open if you pressed the ”e” button. That has been removed for better play functions.

Now for the other things that we need to consider is that the position of the sprite will now not change outside of the door class. The reason is because of the first option.

That means that when we update how the doors should move we need to return that position and then set it into the sprite. So this is kinda loopy but it works… well kinda buggy but yeah so I’m still trying to fix that sue me if you want but first time doing this to a class with a sprite class. It’s kinda interesting but it’s annoying as hell right now since the doors at first flew all over the map. Well they did move… or they like now refuse to move even a inch! Stupid doors.

Well there is nothing else to this class. The collsion manager handles the collision between the door and the player and then set the level->update() to see if the level will change or not.

That is the door class.

Or is it here is a pic!

What does this mean! Well I am here to tell you!

The doors are currently moving to the sides.! do you see it? do you? please do. What you don’t see right now are the following. The collision box is split in two. For each door. But I’m to lazy to change the picture and you know. It will work for my explanation.

So when the doors have moved (they can do that!) the collision box is still set to the point so even if the doors move the collision will occur and the map will change. Ain’t that nifty!

Well I guess I can tell you how the doors open now hmm 😀

You deserved it you read this far!

So the doors uses a simple solution for opening.
In the door class we have a bool called m_active!
wow really? Yes
and that sets to active when the player are around 200 units away from the door so the doors m_active becomes true when it’s close to the door.
Simple and easy solution *caught* not to mention that I did this a stupid way to before a friend pointed this out to me. But that is beside the point! So that is how the door class works.

That is all for this week happy coding |& drawing for your future games!