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

Started by
5 comments, last by Alberth 8 years, 6 months ago

(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

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).

Semicolon after getPosition().x ? smile.png

Blimey! Now I feel stupid wacko.png

It was in your pastebin link.

It was in your pastebin link.

Yeah I double-checked that, just in case and you're right. What an amazingly stupid bug... *facepalm*

Inverse law of bugfixing, the harder it is to find the more trivial the bug :)

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.

This topic is closed to new replies.

Advertisement