Hello, I have a 20x20 pixel sprite and I was just learning about Rect::intersectsRect() .
The code bellow print if two sprites are colliding. The first CCLOG is as expected “Sprite are not intersection”, but what I don’t understand is why after moving spriteB to a posiition where they are interecting I still get the same CCLOG “Sprite are not intersection”, when they clearly are.
I am sure it is something basic that I am not seeing.
thanks
#include "HelloWorldScene.h"
#include <iostream>
USING_NS_CC;
Scene* HelloWorld::createScene()
{
return HelloWorld::create();
}
void checkSpritesRectanglesIntersections(Rect sprite1Box, Rect sprite2Box)
{
if (!sprite1Box.intersectsRect(sprite2Box))
CCLOG("Sprite are not intersection");
else
CCLOG("Sprite are intersection");
}
bool HelloWorld::init()
{
if ( !Scene::init() )
return false;
auto visibleSize = Director::getInstance()->getVisibleSize();
Vec2 origin = Director::getInstance()->getVisibleOrigin();
auto spriteA = Sprite::create("ball.png");
spriteA->setPosition(240, 100);
auto spriteB = Sprite::create("ball.png");
spriteB->setPosition(100, 50);
Rect spriteABox = spriteA->getBoundingBox();
Rect spriteBBox = spriteB->getBoundingBox();
checkSpritesRectanglesIntersections(spriteABox, spriteBBox);
spriteB->setPosition(235, 90);
checkSpritesRectanglesIntersections(spriteABox, spriteBBox);
this->addChild(spriteA);
this->addChild(spriteB);
return true;
}
The getBoundBox() method returns by value, not by reference or pointer, most likely because it is an expensive calculation that would only be used when the bounding box is required. There would be no reason to calculate it any other time, since it would eat up CPU cycles for no reason.
Also, even if it actually did return by reference, the way you’re using it would have still meant it’s holding a value rather than a reference. You would need to use Type& variableName = methodThatReturnsAReference(); in order to hold a reference in variableName .
I see,
So that’s not how you would detect a enemy receiving a shot, or the player jumping into a platform?
you always use the physic engine for sprites intersecting?
(I very new obviously to cocos2d-x, so my questions are very basic at this point)
The physics engine would probably make things much easier on you, so why not give it a go?
It’s best to dig into the code to see how things work. Look at the implementation of the getBoundingBox(). @justL already posted how to get it working.
It’s a little strange though that you call setPosition() and then instantly check if the sprites collide. The issue there is that the display hasn’t yet been updated to reflect the new position of the sprite.
Try to set the sprite position, and then wait till the next update loop to check the intersection. That way the displayed sprite would have moved to the new position, and you would only need to call the getBoundingBox() (per sprite) and checkSpritesRectanglesIntersections() once for each loop.
Yes thanks.
I guess that physics is what is use the most in game then. I ’ ve seen some tutorial where rule number one is gravity always on. But what if you are doing a classic shootem-up planes game?do you need the physics engine there or just schedule some sprites intersecting? My guess is that physics provide more options and is more optimized maybe? I don’t know, just thinking out loud.
Really it depends on the type of game you are making. If you could share more details and gameplay elements I could advise if a physics engine is suitable. A match 3 game wouldn’t really benefit from a physics engine much but something like Angry Birds would so it depends on the game type. Really it comes down to, is the users finger(s) the main interaction with objects or are objects interacting with each other and physically reacting as well.
sure.
I working a 2d scrolling space shooter at the momento. Basically a ship shooting lasers to other ships.
And after that I 2d platformer game like old supermario bros.
2d platformer seem to use physics for the player to move through the scene so I guess it make scene to constantly detect the collision of the playet with the floor. For the space shooter there is no contact with a floor. Only contact is of the bullet with the enemies, and the player with the enemies.
For the platformer definitely i would recommend a physics engine but for the space one its less crucial. However you could use it in the space game as a test bed as you would need less advanced features.
