I'm really kind of new to c++ and quite bad at it but I'm making a space invaders game for my university project. I'm having trouble with the alien movement system and how to get the aliens to spawn in a line (once they get to a side of the screen they move down and then across).
Firstly here is the code I'm using to move the alien movement
if (currentSpritePos.x < 975 || currentSpritePos.x > 0)
{
this->AlienVelocity.x = this->AlienVelocity.x*-1;
}
if (currentSpritePos.x == 0)
{
cout << "Im at the wall wooo and going to move down";
//AlievVelocity.x*+1;
setSpritePos({ 0, 75 });
}
I can get the aliens to go left and move down but for some reason they aren't moving right, I commented the line out "AlienVelocity.x*+1", I thought that would have just made them go right since "-1" made them go left...
To get the aliens to spawn in a line I've made an array and set so only 2 aliens to spawn just for testing purposes.
for (int aly = 0; aly < 2; aly++) // Change the 35 to number of desired aliens
{
theAliens.push_back(new cAliens);
theAliens[aly]->setSpritePos({ (100, 50) + 200 });
theAliens[aly]->setSpriteTranslation({ 0, 0 });
theAliens[aly]->setTexture(theTextureManager->getTexture("alien"));
theAliens[aly]->setSpriteDimensions(theTextureManager->getTexture("ship")->getTWidth(), theTextureManager->getTexture("alien")->getTHeight());
}
On the 2nd line in side the for statement I put "+200+ because I thought that would just put the next alien +200 points but obviously not. I'm not sure on how to fix this as well...
if (currentSpritePos.x < 975 || currentSpritePos.x > 0)
{
this->AlienVelocity.x = this->AlienVelocity.x*-1;
}
This code says that whenever the aliens are between 0 and 975 to reverse the velocity. I believe this is the exact opposite of what you want. This means they should just go back and forth and never move across the screen. Swap the compare signs.
For moving down, take the current y position and add the row length to it, This should be done when the velocity is reversed - in the same if statement.
Start with those changes and see if you can figure out the rest.
Related
So, I had a test going on to see how collision operates in SFML. I have made this snippet of code:
if (floor.getGlobalBounds().intersects(SuperMario.getGlobalBounds())) // Floor
{
SuperMario.setPosition(SuperMario.getPosition().x, floor.getPosition().y - SuperMario.getOrigin().y);
IsTouching = true;
}
As the code suggests, Mario will change his position when he touches the floor object and will teleport above the floor.
However, this has the following side-effect, illustrated by the pictures below.
Note that the "green box" is the floor object I mentioned earlier. Also, ignore the word "left" in picture 1, I mean "right".
Of course, this behaviour is intended (i.e. is not a bug), but it is unwanted.
So my question is: How can I eliminate this "side-effect"? I mean, how can I modify my code, so Mario will not teleport above the floor, when he touches its sides(making platforming work like a proper platforming)? I want Mario to be stopped by the box, not to be teleported.
UPDATE: So now, I have this:
for (unsigned int i = 0; i <= solidObjects.size() - 1; i++)
{
if (solidObjects[i].getGlobalBounds().intersects(SuperMario.getGlobalBounds()))
{
if (SuperMario.getPosition().x - solidObjects[i].getPosition().x < SuperMario.getPosition().y - solidObjects[i].getPosition().y)
{
SuperMario.setPosition(solidObjects[i].getPosition().x - SuperMario.getOrigin().x, SuperMario.getPosition().y);
IsTouching = false;
}
else if (SuperMario.getPosition().y - solidObjects[i].getPosition().y < SuperMario.getPosition().x - solidObjects[i].getPosition().x)
{
SuperMario.setPosition(SuperMario.getPosition().x, solidObjects[i].getPosition().y - SuperMario.getOrigin().y);
IsTouching = true;
}
else if (SuperMario.getPosition().x - solidObjects[i].getTextureRect().width < SuperMario.getPosition().y - solidObjects[i].getPosition().y)
{
SuperMario.setPosition(solidObjects[i].getTextureRect().width + SuperMario.getOrigin().x, SuperMario.getPosition().y);
IsTouching = false;
}
}
else
{
IsTouching = false;
}
}
However, there is one problem. When Mario touches the sides of the floor, he sticks on them meaning he is unable to move right.
If I am not clear enough, please specify what i should add or clarify more.
This feels really weird, because you'd typically define solid areas rather than those the player can walk inside. You'll want your player to jump after all, rather than having them glued to the ground.
The rest is pretty straightforward:
Iterate over all solid objects and determine whether the player and the solid rectangle overlap.
If they do, determine which distance is smaller (x or y). This lets you determine which axis to move the player.
Determine which direction the player leaves the solid area quicker, i.e. which direction to push the player.
Push the player in the calculated direction and repeat the checks.
Depending on your map complexity this can become rather complex, so you'll most likely want some sorting/spatialisation to reduce the number of comparisons (e.g. skip checking impossible/far away shapes).
I need to detect when a body is fully inside another body and which side it came in from.
I have balls that bounce around the screen, and can enter the space of other square bodies. I need to know when the ball is fully inside the box, and from which side it came in on. This is NOT just collision detection on a side of the box, as the ball needs to be fully inside the box before anything triggers. I'm using b2FixtureDef::filter::maskBits and b2FixtureDef::filter::categoryBits to allow balls and boxes to not collide with each other.
I'm new to box2d, but not to C++, so I may be missing some functions that could make this easier for me. I started writing the following code, which works when a ball passes the correct edge, but also when it passes other edges.
Is there a way to do this without copying the ball into another data structure that keeps track of where it first contacts the box?
NOTE: This code is an example. It may not actually compile or do exactly what I say it does.
void CBox::captureBalls(std::list<CBall> &balls)
{
std::list<CBall> capturedBalls;
std::list<CBall>::iterator ball = balls.begin();
while (ball != balls.end()) {
bool capture = false;
int ballMinX = ball->getX() - ball->getRadius();
int ballMaxX = ball->getX() + ball->getRadius();
int ballMinY = ball->getY() - ball->getRadius();
int ballMaxY = ball->getY() + ball->getRadius();
switch (this->captureSide) {
case Top:
if ((ballMinX >= this->x) &&
(ballMaxX < (this->x + this->width)) &&
//(ballMinY >= this->y) &&
(ballMaxY < (this->y + this->height)))
capture = true;
break;
case Right:
if (//(ballMinX >= this->x) &&
(ballMaxX < (this->x + this->width)) &&
(ballMinY >= this->y) &&
(ballMaxY < (this->y + this->height)))
capture = true;
break;
case Bottom:
if ((ballMinX >= this->x) &&
(ballMaxX < (this->x + this->width)) &&
(ballMinY >= this->y) /*&&
(ballMaxY < (this->y + this->height))*/)
capture = true;
break;
case Left:
if ((ballMinX >= this->x) &&
//(ballMaxX < (this->x + this->width)) &&
(ballMinY >= this->y) &&
(ballMaxY < (this->y + this->height)))
capture = true;
break;
}
if (capture) {
capturedBalls.push_back(ball);
balls.erase(ball++);
}
else {
++ball;
}
}
}
To detect when a ball is fully inside the box, you could use a sensor fixture inside the box, that is smaller than the box by the diameter of the ball. In the diagram below the black rectangle is the box and the red dashed rectangle is the sensor. (If the balls all have different diameters this would not work.)
As to "which side it came in", I think you need to define what you mean by that, before anyone could help. I mean, look at the possible cases you are dealing with. The blue ball is the most straight-forward in that it approaches on one side in a constant direction. When you detect that it touches the sensor, you could use the direction of travel as suggested by sp2danny, to do a raycast from outside the box to the current position of the ball, and the side it entered is pretty obvious. But this would not work for the green or pink balls. For the pink ball in particular, what side would you consider it entered from?
Now I am assuming that the balls are free to enter the boxes from any angle. But if they had a solid obstruction at their corners, it might be clearer to define which side they came in. You could use four sensors around the exterior, and detect when a ball finishes touching these.
However, it would not be bullet-proof because in rare cases a ball could go from touching one side sensor to another in one time step, without touching nothing in between (green ball). For really fast balls, they could also potentially go from touching one side sensor, to completely inside without ever touching the sensor for the side they "came in" (pink ball). On the plus side though, this would handle the case when you have many different sizes of ball.
Ok... now that I've written up a whole post saying how it can't be done easily, I had a good idea, although it would only work when all balls are the same size. You could use two sensors inside the box, one inset by the radius of the balls, and one inset by the diameter of the balls. When the ball first touches the outer of these sensors, it means the center of the ball has crossed from being outside, to inside the box (but the ball as a whole may not be fully inside). At this point, take a raycast between the previous and current positions, and note which side it intersected. Continue on until the ball also touches the inner sensor, then you know it is fully inside, and you have already noted which side it originally came in from. If the ball stops touching the outer sensor at any point, reset to the starting state.
Note that it is still possible for a ball to first touch the box from one side, then move so that the first time its center is inside the box is from a different side (orange ball). But I am assuming you would not count a mere touch as "came in".
I have some collision detection working when my player hits an object. But this only works when my players x & y co-ordinates hit my marker (which is the centre of my character).
Would making a method returning a vector of all of the coordinates that the players texture cover work and what is the best way to implement this?
This is being done in c++ creating a top down game
There are many ways to do it, most simply is probably(depending on you use of classes etc).
This is the simplest, but no where near the best, or infact very good at all. This way means changing your "marker" to the bottom left of the rectangle.
void collisions()
{
//check if the x-coord is between the furthest left and furthest right x coords
if(rect.Getx() > someObject.Getx() && rect.Getx() < someObject.Getx() + someObject.GetWidth())
{
rect.SetMoveSpeed(0);
}
if(rect.Gety() > someObject.Gety() && rect.Gety() < someObject.Gety() + someObject.GetHeight())
{
rect.setMoveSpeed(0);
}
}
You would then have to set the move speed to normal when it is not colliding. That could be done with an else after each if, setting the move speed again. This is a quick fix and is not recommended for use in a game you plan to distribute anywhere.
I am creating a space invaders game for my university assignment. I am breaking the parts down on paper, I thought a good place to start would be to move the sprites across the screen. The issue I have at the moment is this, when the sprite his the right hand side of the screen it would just carry on moving, so I added this code:
if (invadersSprite.getPosition().x > 650)
{
std::cout << "WIDTH_END" << std::endl;
}
I basically used this for debugging for future reference. The output popped up into the console so I knew I was onto something. So, I started moving on from the output to actually moving the sprites back to the left hand side of the screen. I am now having more issues then expected.
I declared some ints for up, left, right and down just for easability when it comes to reading the code.
int spriteWalkSpeed = 50;
int up=-spriteWalkSpeed, down=spriteWalkSpeed, left=-spriteWalkSpeed, right=spriteWalkSpeed;
I've tried using the SFML move commands and also setPosition, but none of them really work as I thought they should.
move:
The issue I have had with this one is it basically stops in the middle of the screen. It still animates the leg movement and such, but it doesn't move left or right.
if (invadersSprite.getPosition().x > 650)
{
invadersSprite.move(left, 00);
}
setPosition:
This is a little closer to what I am after, but still no cigar. The movement pauses for around a second and then pops up at the left hand side of the screen. What I need is to move back down the screen.
if (invadersSprite.getPosition().x > 650)
{
invadersSprite.setPosition(left, 00);
}
I haven't been using SFML for very long so I am a little puzzled by this.
EDIT
At the moment the sprite is moving to the right of the screen, as needed:
if(spriteTimer>delay)
{
invadersSprite.setTextureRect(area);
++count;
invadersSprite.move(right,0);
if(count==SPRITECOLS) //WE HAVE MOVED OFF THE RIGHT OF THE IMAGE
{
area.left=0; //reset texture rect at left
count=0; //reset count
}
else
{
area.left+=spaceWidth; //move texture rect right
}
spriteTimer=0; //we have made one move in the sprite tile - start timing for the next move
}
Your current logic will only move the sprite left once if the x-coord is greater than 650 - but that's not exactly what you want. What you want is for the sprite to continuously move left after reaching the edge.
To do this you'll need to keep track of a current velocity for your sprite. For example, when your sprite starts, it will be moving right:
xVelocity = right;
Then you can have 2 conditions that will switch direction (when hitting edges of screen):
if (invaderSprite.getPosition().x >= screenWidth) {
// hit the right side of screen
xVelocity = left;
} else if (invaderSprite.getPosition().x <= 0) {
// hit the left side of screen
xVelocity = right;
}
Now, on ever game tick, you simply move your sprite according to its current velocity:
invaderSprite.move(xVelocity, yVelocity);
There are some other things that will need to be fixed, like taking the width of the sprite into consideration, changing the y velocity, etc., but this is the main idea.
I am trying to create a 2D platformer (Mario-type) game and I am some having some issues with handling collisions properly. I am writing this game in C++, using SDL for input, image loading, font loading, etcetera. I am also using OpenGL via the FreeGLUT library in conjunction with SDL to display graphics.
My method of collision detection is AABB (Axis-Aligned Bounding Box), which is really all I need to start with. What I need is an easy way to both detect which side the collision occurred on and handle the collisions properly. So, basically, if the player collides with the top of the platform, reposition him to the top; if there is a collision to the sides, reposition the player back to the side of the object; if there is a collision to the bottom, reposition the player under the platform.
I have tried many different ways of doing this, such as trying to find the penetration depth and repositioning the player backwards by the penetration depth. Sadly, nothing I've tried seems to work correctly. Player movement ends up being very glitchy and repositions the player when I don't want it to. Part of the reason is probably because I feel like this is something so simple but I'm over-thinking it.
If anyone thinks they can help, please take a look at the code below and help me try to improve on this if you can. I would like to refrain from using a library to handle this (as I want to learn on my own) or the something like the SAT (Separating Axis Theorem) if at all possible. Thank you in advance for your help!
void world1Level1CollisionDetection()
{
for(int i; i < blocks; i++)
{
if (de2dCheckCollision(ball,block[i],0.0f,0.0f)==true)
{
de2dObj ballPrev;
ballPrev.coords[0] = ball.coords[0];
ballPrev.coords[1] = ball.coords[1];
ballPrev.coords[2] = ball.coords[2];
ballPrev.coords[3] = ball.coords[3];
ballPrev.coords[0] -= ball.xspeed;
ballPrev.coords[1] -= ball.yspeed;
ballPrev.coords[2] -= ball.xspeed;
ballPrev.coords[3] -= ball.yspeed;
int up = 0;
int left = 0;
int right = 0;
int down = 0;
if (ballPrev.coords[0] < block[i].coords[0] && ballPrev.coords[2] < block[i].coords[0] && (((ball.coords[1] < block[i].coords[1]) || (ball.coords[3] < ball.coords[1])) || ((ball.coords[1] < block[i].coords[3]) || ball.coords[3] < block[i].coords[3])))
{
left = 1;
}
if (ballPrev.coords[0] > block[i].coords[2] && ballPrev.coords[2] > block[i].coords[2] && (((ball.coords[1] < block[i].coords[1]) || (ball.coords[3] < ball.coords[1])) || ((ball.coords[1] < block[i].coords[3]) || (ball.coords[3] < block[i].coords[3]))))
{
right = 1;
}
if(ballPrev.coords[1] < block[i].coords[1] && block[i].coords[1] < ballPrev.coords[3] && ballPrev.coords[3] < block[i].coords[3])
{
up = 1;
}
if(block[i].coords[1] < ballPrev.coords[1] && ballPrev.coords[1] < block[i].coords[3] && block[i].coords[3] < ballPrev.coords[3])
{
down = 1;
}
cout << left << ", " << right << ", " << up << ", " << down << ", " << endl;
if (left == 1)
{
ball.coords[0] = block[i].coords[0] - 18.0f;
ball.coords[2] = block[i].coords[0] - 2.0f;
}
else if (right == 1)
{
ball.coords[0] = block[i].coords[2] + 2.0f;
ball.coords[2] = block[i].coords[2] + 18.0f;
}
else if (down == 1)
{
ball.coords[1] = block[i].coords[3] + 4.0f;
ball.coords[3] = block[i].coords[3] + 20.0f;
}
else if (up == 1)
{
ball.yspeed = 0.0f;
ball.gravity = 0.0f;
ball.coords[1] = block[i].coords[1] - 17.0f;
ball.coords[3] = block[i].coords[1] - 1.0f;
}
}
if (de2dCheckCollision(ball,block[i],0.0f,0.0f)==false)
{
ball.gravity = -0.5f;
}
}
}
To explain what some of this code means:
The blocks variable is basically an integer that is storing the amount of blocks, or platforms. I am checking all of the blocks using a for loop, and the number that the loop is currently on is represented by integer i.
The coordinate system might seem a little weird, so that's worth explaining.
coords[0] represents the x position (left) of the object (where it starts on the x axis).
coords[1] represents the y position (top) of the object (where it starts on the y axis).
coords[2] represents the width of the object plus coords[0] (right).
coords[3] represents the height of the object plus coords[1] (bottom).
de2dCheckCollision performs an AABB collision detection.
Up is negative y and down is positive y, as it is in most games.
Hopefully I have provided enough information for someone to help me successfully. If there is something I left out that might be crucial, let me know and I'll provide the necessary information. Finally, for anyone who can help, providing code would be very helpful and much appreciated.
Thank you again for your help!
Edit 2: I have updated my code with a new algorithm that checks where the ball was previously before collision. Corner cases work on that single platform correctly now, and when I have a wall of objects, I can slide against it correctly now. The only remaining problem is that there is a small jittering effect that happens when I am on the ground, where the ball is constantly going up and down as if it is being pulled by gravity and then the ball falls back into the object again.
Edit: Here is a URL to an image trying to show the kinds of problems I am having:
http://img8.imageshack.us/img8/4603/collisionproblem.png
In case the explanation in the picture doesn't make too much sense, the ball cannot move left past the corner of an object unless I jump over it. However, the ball can move right, but it gets repositioned to the right of the object while moving, which is not needed. This creates a skipping movement essentially, where it appears as the the ball is skipping over half of the object or so when I move right. If this doesn't make sense, please ask me and I'll try to clarify more.
One problem with your code is that you only detect situations like this:
If the circle happens to be fully inside the block, you don't reposition at all. And that's a problem.
You're trying to think about your simulation as if it were continuous, but keep in mind it's discrete. In general, if you only look at the current state of the ball, you really cannot know which side it collided with. Look at these two possibilities:
The first solution that comes to mind is to look at the last position of the ball as well; more precisely, look at the delta vector. See if the delta vector intersects a wall. If it does, reposition in an axis-aligned direction towards the wall intersected by the delta vector.
Edit: When I said "delta vector", I forgot that you're moving a square and not a single point. So, if you just look at the delta vector of the top-left corner, that's not going to be enough because it may not detect that part of the ball entered a block. Instead, you can look at the delta vectors of all 4 corners.