• Advertisement
Sign in to follow this  

!Collision while (.move() float < 1.0f) ?

This topic is 863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

(SOLVED! No further resolution needed.)

I got a bounding box collision set up for two rectangles that are created through SFML's sf::RectangleShape. The moving rectangle is set to .move() speed of 1.0f. Example (x-direction):

if (sf::Keyboard::isKeyPressed(sf::Keyboard::D)) {
p1.rect.move(1.0f, 0);
}

Collision works perfectly. My question is about that float value, specifically:
1.0f makes my rectangle move superfast to the point of being uncontrollabe. However, if I reduce the .move() to, say 0.04f, I get a much more managable speed BUT the collision stops working:

if (sf::Keyboard::isKeyPressed(sf::Keyboard::D)) {
p1.rect.move(0.04f, 0);
}

Why, exactly does the collision stop working and what can I do to fix it? I'm assuming that the program is trying to look for real values that don't exist per update, because the float is too small? Collision code:

void update() {
bottom = rect.getPosition().y + rect.getSize().y;
left = rect.getPosition().x;
right = rect.getPosition().x + rect.getSize().x;
top = rect.getPosition().y;
}
 
bool collision(Player p) {
 
if (right < p.left || left > p.right ||
top > p.bottom || bottom < p.top) {
return false;
}
return true;
}

Thanks for any input.
Here's the full program (note: code only, as I've setup SFML in a custom fashion according to another GameDev member's specifications, so you may not be able to run it).
http://pastebin.com/vnc5q1m3

Edited by Madolite

Share this post


Link to post
Share on other sites
Advertisement
right = rect.getPosition().x; + rect.getSize().x;

 

Semicolon after getPosition().x ? smile.png

(Check your warning-level if you don't get a warning about this from the compiler).

Edited by Erik Rufelt

Share this post


Link to post
Share on other sites
You can find bugs like this with a debugger by examining the values you compare, or by a "print" of the coordinates of both boxes in the collision test routine.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement