Messages

1

SFML projects / Re: FlexWorld

« on: August 27, 2012, 01:52:40 pm »

The reason why I'm asking is that I've been reading about physics engines and their development lately, and I've found that there are some really good free libraries (at least feature-wise) with very liberal licenses available. Of couse I'm making my own at the moment, but it's out of curiousity, I wouldn't really even need it for anything at the moment.

Thanks for the input. This project seems interesting, I hope it works out.

2

SFML projects / Re: FlexWorld

« on: August 25, 2012, 04:18:14 pm »

Is there a specific reason why you're not using a ready-made physics engine for the physics?

3

Graphics / Collision detection problem

« on: July 15, 2011, 03:42:11 pm »

Are the objects circles? At least the crate is probably a square or a rectangle.

About the code, you don't need to create a circle object, you can just calculate it directly:

Code: [Select]


bool Collision::HasCollided(sf::Sprite& sprite1, sf::Sprite& sprite2)
{
   // this function checks if the two inputted sprites have
   // collided using circle collision detection

   if(sprite1.GetSize().x > sprite1.GetSize().y)                
   {
      r1 = sprite1.GetSize().x/2;
   }
   else
   {
      r1 = sprite1.GetSize().y/2;
   }

   if(sprite2.GetSize().x > sprite2.GetSize().y)                  
   {
      r2 = sprite2.GetSize().x/2;
   }
   else
   {
      r2 = sprite2.GetSize().y/2;
   }

   distX = sprite2.GetPosition().x - sprite1.GetPosition().x;
   distY = sprite2.GetPosition().y - sprite1.GetPosition().y;

   distance = sqrt((distX*distX)+(distY*distY));
   sumOfRadii = r1 + r2;

   if(distance <= sumOfRadii)                                  
   {
      return true;
   }
   else
   {
      return false;
   }
}

Make sure that your objects are circles (unless you can live with the inaccuracy), and that the actual images are squares not rectangles if possible, otherwise the detection will be off.

4

General / Collision Optimization

« on: June 17, 2011, 01:54:16 am »

The code will probably run faster if you implement it yourself (assuming you won't mess up ). On the other hand, if you implement it yourself, you have to prevent tunneling yourself (if it is an issue), you have to figure out how to respond to the collision etc. I would do it myself if I was you, unless I needed to simulate physics.

5

General discussions / A new logo for SFML

« on: June 12, 2011, 04:12:39 pm »

Cpl.Bator, that looks awesome.

6

General / Re: Collision Detection Function Doing Weird Things

« on: June 12, 2011, 03:00:39 pm »

First, you should know the difference between collision detection and collision response. Collision detection means detecting if a collision has happened (and often finding out the exact collision point). Collision response, on the other hand, means reacting to the collision that has been detected. Your function is actually very close to being correct, it only returns true if the sprites are not colliding and false if they are colliding. You need to swap the returning values:

Code: [Select]


bool coll(sf::Sprite& s1, sf::Sprite& s2)
// Collision Function
{
float left1, left2, right1, right2, top1, top2, bot1, bot2;
//Floats for our bounding boxes
left1= s1.GetPosition().x;
left2=s2.GetPosition().x;
right1=s1.GetPosition().x +s1.GetSize().x;
right2=s2.GetPosition().x +s2.GetSize().x;
top1=s1.GetPosition().y;
top2=s2.GetPosition().y;
bot1=s1.GetPosition().y+s1.GetScale().y;
bot2=s2.GetPosition().y+s2.GetScale().y;
//All of the Bounding Boxes' floats now have values!
if(bot1>top2)
{
return false;
}
else if(top1<bot2)
{
return false;
}
else if(right1>left2)
{
return false;
}
else if(right2>left1)
{
return false;
}
//return false if no sides intersect

else
{
return true;
}
//return true if the sides of the Rectangles intersect
}

That will also fix the movement bug. The movement bug exists because that function returns true when the sprites are not colliding, so it's returning it almost all the time. In the main function you have this piece of code:

Code: [Select]


if(coll(pc,w2) || coll(pc,w1))
{
    speed= -12;
} else {
    speed= 10;
}
  //If the Player Collides with one of the Walls, he will be stopped
}

That won't cause the player to stop when he hits the wall, it will cause him to move to the other direction (if you press w, it will move backwards etc.) So the player will move in the opposite directions when he's not colliding with the walls and move normally when he is colliding. Fixing the return values is the first step forward. The second step is fixing the reaction to the collision.

If you only wanted the player to stop, you could do this:

Code: [Select]


if(coll(pc,w2) || coll(pc,w1))
{
    speed= 0;
} else {
    speed= 10;
}
  //If the Player Collides with one of the Walls, he will be stopped
}

However, that is not a good solution since the player can't move at all when he collides with the wall. He will be stuck there forever. The solution is to move the player every time he hits the wall so that afterwards he won't be inside the wall anymore. For this you need to figure out which side of the wall the player collides and move the player accordingly. For example, if the player hits the wall from the left, you would move him to (wall.x - player.GetWidth()/2, player.y).

7

General discussions / A new logo for SFML

« on: June 07, 2011, 12:10:04 pm »

I think the Bassman's first looks too much like the SDL logo. Other than that it looks pretty cool. The second one is too cartoonish.

David's logo looks a lot like the original. It's not a bad thing really, work on the icons a bit and it will look great.

I really like Cpl.Bator's second logo, it would be my choice.

8

General / Re: Trying to keep sprite from moving off of the screen.

« on: May 21, 2011, 11:23:21 am »

EDIT: I've figured out why it doesn't work with using a simple cout to print it's coordinates. I'm curious to why it's the opposite of what I thought. As in why when you go up the y coordinate goes down and vice versa. Is there some mathematics or subject that will help me better understand this? I don't want a simple problem like this holding me back anymore , as I have bigger fish to fry in the future. Or is this simply how the library is?

There's nothing fancy to it, really. It's just that the origin is at the upper left corner and the y-axis is flipped. That's the way it is for almost all libraries and programming languages. I guess it's for practical reasons. Anyway, there's no fancy math behind it or anything like that. Just get used to it and you'll be fine.

9

Graphics / Help with game and sprite movement

« on: May 21, 2011, 11:16:45 am »

You could do like Hagel suggested but there is a problem: what if the character can move faster than one pixel per frame? It might go over the grid.

I actually made an example of that kind of movement for a programming language called Coolbasic just a while ago. What I did was that I had two variables for storing coordinates for the waypoint where the character is heading and when the player wants to move, the waypoint is set accordingly. For example, if the player wanted to move right, the waypoint's coordinates would be (x+TileWidth, y) and then the character would start moving towards the waypoint. When the distance to the waypoint (Pythagora's theorem) is below certain limit, the character's coordinates are set to be the waypoint's coordinates. I also had a variable that stored the direction where the player is headed so that the right sprite would be drawn.

10

Graphics / Re: Help with game and sprite movement

« on: May 18, 2011, 07:46:39 pm »

I usually use dynamic 2D-arrays for the tilemaps. If I want to store some extra information, I just add an extra dimension. Here's an example of a map and how it could look like in memory:

Code: [Select]


The map:

####
#00#
####

How it's stored:

1 1 1 1
1 0 0 1
1 1 1 1


I'm not sure how you want the character to move so I can't give you tip on that one. Do you want it to hop from one tile to another, or do you want it to move "freely" from the center of the tile to the center of the next tile?

11

General / I need help with this game i am trying to make.

« on: May 10, 2011, 11:15:01 am »

How are you moving the ball? Are you using the ballAngle-variable anywhere else?

Anyway, the problem with the bouncing is that it does exactly what you tell it to do. You aren't actually calculating the angle in which it should bounce off the bat, you are just using whatever is in ballAngle as the angle.

Code: [Select]


// Check collision between Bat and ball

if (Collision(PlayerBat, Ball))
{
    // Calculate the correct angle here (ballAngle = ...)
    Ball.Move(cos((ballAngle/180)*PI) * ballSpeed, sin((ballAngle/180)*PI) * ballSpeed);  // Move the ball
}

How to calculate the correct angle is a whole different story. First you need to decide how you want the ball to bounce off the bat. Do you want it to be realistic (mirror reflection), or do you want it to bounce straight back if the ball hits the center and bounce to the left if it hits to the left etc.?

In every case you have to figure out which side of the rectangle the ball hits (you might even need the exact spot).

Code: [Select]


// As an example, I show you how to find out if the ball hit the bat from above or below.
// I assume that the bat is drawn from the upper left corner. ballCenter simply means the center of the ball (I could've assumed that the ball is drawn
// from the upper left corner, too, but it would've made the code messier).

// Basically just test if the ball is inside the area limited by the left and right sides of the rectangle and then find out
// whether the ball is above or below the rectangle.
// (This won't work correctly if the ball moves so fast that center of the ball is inside the rectangle when this check is performed.)

if(ballCenter.x > bat.x && ballCenter.x < bat.x + bat.width && ballCenter.y < bat.y) {

    // The ball hit the bat from above

} else if(ballCenter.x > bat.x && ballCenter.x < bat.x + bat.width && ballCenter.y > bat.y + bat.height) {

    // The ball hit the bat from below

}

(I haven't tested the example but it should be correct)

The cleanest solution to implement the realistic bouncing is to use vectors. It can be done with trigonometry, too, but it's a bit messier since there are special cases to consider.

Here's your homework: make your game recognize which side of the rectangle the ball hits (and make somehow sure that it works). After that we'll focus on the actual bouncing. If you have trouble with it, don't hesitate to ask. It's completely possible that I have made a mistake somewhere.

12

General / I need help with this game i am trying to make.

« on: May 09, 2011, 11:04:01 am »

Can I ask how you would do collision with the bat if it is drawn from the centre?

Assuming that you are using bounding box detection, you would use exactly the same code for the detection and only change the coordinates a bit. Let's say that our box's center is at (x,y). Now the upper left corner is at (x-boxWidth/2, y-boxHeight/2), the right upper corner is at (x+boxWidth/2, y-boxHeight/2), the left lower corner is at (x-boxWidth/2, y+boxHeight/2) and the lower right corner is at (x+boxWidth/2, y+boxHeight/2). Now you can use the same code to detect the collision, you only need to change the coordinates (and you would probably only need the upper left corner).

Also whenever I use your method for bouncing the ball off the bat it always goes towards the bottom left corner, what am I doing wrong?

 - Simon

I'm not actually sure whose method you are referring to but it seems that you don't calculate the angle correctly. Seeing the relevant part of the code would be helpful, now I can only guess what's actually wrong.

13

General / How to use "Simple Collision Detection?"

« on: May 09, 2011, 10:17:02 am »

I've been a bit busy lately so sorry for the delayed answer.

The bouncing off the sides of the screen is done in the pong example for the two of the four edges. You basically only need to copy that part and figure out the formulas for the other two if you need those, too (the collision with the those edges is there but hitting those edges just ends the game, it doesn't bounce the ball of the wall). There is a way to do it with one function, without any special cases (=only one formula would be needed). The problem is that you would need to know vector math to be able to understand it. So I ask you, do you know anything about vector math?

Oh, and checking the collision with the edge of the screen is even easier than bounding box detection. You only need to check if the ball's coordinates are less than zero or over the screen width or height to determine that the ball is colliding with the edges.

I would probably use vectors for the gravity, too (unless you only want it to keep bouncing at the same spot). I would use a vector for the speed of the ball and another vector for the gravity that keeps pulling the ball to the ground.

14

Graphics / sf::Sprite Rotation causes Crash

« on: May 06, 2011, 03:45:51 pm »

Would you care to explain what's wrong with using new?

There's nothing wrong with using it as long as you remember to delete it (and never delete it too early) but using it is error prone.

15

General / How to use "Simple Collision Detection?"

« on: May 02, 2011, 08:04:10 pm »

That moves it only in one direction because you are telling it to move only to one direction. What you want to do is to figure out which side of the rectangle is actually hit and move the object accordingly. For example, if the object is coming straight down when it hits the object, you want to move the object up to keep it above the rectangle. You should be able to figure it out by comparing the coordinates, a bit like the collision detection is done. For example to find out if the object is coming from the top, you could do something like this

Code: [Select]


if(object.x() + object.size().x > object2.x() && object.x() < object2.x() + object2.size().x && object.y() > object2.y())


Btw. sprite.move(x, y) moves the sprite horizontally the amount of x and vertically the amount of y.