Texture won't display when loaded from within a class?

[mastodona7x]

Hello all, 

Total noobie here but Im trying to create a simple game. I want to create a bomb object and everything is fine if I set the bomb up from within the main() loop, but if I try to make a bomb class then create a new bomb from this class, the texture no longer loads, I just get a white square instead. Can anyone help see why please?
Also can I pass a sf::IntRect() over the the class instead of having to pass over 4 individual ints? I tried changing the bomb class to get sf::IntRect textureRect and passing sf::IntRect(0,0,32,32) in the call but I just could not get it to work, so I am not sure if this is possible?

Main worry is the lack of texture anyway, like I say if I have the bomb created in main it shows the png bomb just fine, any suggestions most appreciated thanks. 

Code so far:

call top create new bomb instance in main()

Bomb bomb(0,0,32,32,0,0,64,64,160,160); // would rather pass some IntRects so neaten this up!
 

In bomb class (bomb.h):

public:
  Bomb(int texureRectX, int textureRectY, int textureRectSizeX, int textureRectSizeY, int collisionRectX, int collisionRectY, int collisionRectSizeX, int collisionRectSizeY, int posX, int posY )
  {
         this->setTextureRect(sf::IntRect(0,0,32,32));
         this->setRelativeCollider(sf::IntRect(0,0,64,64));
         this->setPosition(160, 160);
         sf::Texture bombChar;
         bombChar.loadFromFile("images/bomb.png");
         this->setTexture(bombChar);
  };
 

[Hiura]

I guess your "Bomb" class is a Sprite, isn't it? Then the doc says the following interesting thing :

sf::Sprite::setTexture

Change the source texture of the sprite.

The texture argument refers to a texture that must exist as long as the sprite uses it. Indeed, the sprite doesn't store its own copy of the texture, but rather keeps a pointer to the one that you passed to this function. If the source texture is destroyed and the sprite tries to use it, the behaviour is undefined. If resetRect is true, the TextureRect property of the sprite is automatically adjusted to the size of the new texture. If it is false, the texture rect is left unchanged.

(Your bombChar is destroyed at the end of the ctor.)

[mastodona7x]

Hi I see (i think), yes it is a spritem, and thank you very much for replying...so I have to make the bomb and then apply the texture in main I suppose? or make the texture in main then pass it to the class, I think it means that should work??
Thanks again!!

[Hiura]

That might work indeed however this is not a good object oriented design. I'll probably go with something like :

class Bomb /* no inheritance */
{
    sf::Sprite mySprite;
    sf::Texture myTexture;
public:
    Bomb(some param)
    {
        myTexture.loadFromFile(...);
        mySprite.setTexture(myTexture);
        :
        :
 

If you are not very familiar with "encapsulation" and similar concept then I recommend reading some book about object oriented design. A very important topic beside encapsulation is also "Inheritance vs. Aggregation". You can find an interesting discussion here.

[mastodona7x]

Thanks again for the reply, I cannot get it working quite, it's not white now it seems to just be invisible! I know it is there as after a few seconds it is set to destroy some blocks around it...which still works... I sort of need inheritance as it shares a gameObj class which handles collisions and stuff like that, my code looks like this now, but its just invisble. I did start reading c++ books and tutorials but I tend to learn better by just jumping in the deep end and playing around with things I find (and by asking for help when I get stuck  ) Its a bit if a mess right now as I play around with stuff but I just need to iron out a few things and then I can get it tidied up...so any idea why its invisible?

class Bomb : public gameObj {
private:
    sf::Sprite mySprite;
    sf::Texture myTexture;
public:
        Bomb(int texureRectX, int textureRectY, int textureRectSizeX, int textureRectSizeY, int collisionRectX, int collisionRectY, int collisionRectSizeX, int collisionRectSizeY, int posX, int posY )
  {
         myTexture.loadFromFile("images/bomb.png");
         mySprite.setTexture(myTexture);
         this->setTextureRect(sf::IntRect(0,0,32,32));
         this->setRelativeCollider(sf::IntRect(collisionRectX,collisionRectY,collisionRectSizeX,collisionRectSizeY));
         mySprite.setPosition(160, 160);
  };
  ~Bomb()
          {
                  cout<<"Destroyed!";
  };
};
 

in Main:

Bomb bomb(0,0,32,32,-1,-1,34,34,160,160); // -1 and 34 so collision rect overlaps/collides with blocks next to bomb

and later in main a "window.draw(bomb)";

[eXpl0it3r]

Is gameObj inherited from sf::Drawable? Otherwise your code shouldn't have compiled. Also what are you doing with in the .draw function of the gameObj? I mean the gameObj certaintly can't know of mySprites to draw it...

[Hiura]

gameObj inherits from sf::Drawable, right ? So you need to implement draw in your class Bomb.

BTW, don't forget to check the return value of loadFromFile. 

[mastodona7x]

Thanks guys, actually gameObj inherits from sf::sprite...it's just used for the collisions really (some code I borrowed from someone else!). I'm really confused lol 
I do normally have the if(!loadfromfile) exit_result type stuff to check for the result, but would that make a difference here or is that just for good practice?

gameObj is just like this, and it all compiles with no errors...just doesn't display the bomb though it's certainly there...

class gameObj : public sf::Sprite {
private:
  sf::FloatRect colliderResult;
  sf::IntRect relativeCollider;
  sf::FloatRect getCollider();

public:
  gameObj();

  bool isCollidingWith( gameObj object );
  void setRelativeCollider( sf::IntRect collider );
  void collide( gameObj collidingObject );
 
  bool operator< (const gameObj &other ) const {
    return getPosition().y < other.getPosition().y;
  }
 
  void update();
 
  int objectId;
  bool isDestructable;
 
};
 

[Hiura]

I do normally have the if(!loadfromfile) exit_result type stuff to check for the result, but would that make a difference here or is that just for good practice?

For good practice mainly. It's always a good practice to detect unexpected behavior as soon as possible.

actually gameObj inherits from sf::sprite...

Arg!

[mastodona7x]

I hear inheriting from sf::sprite is not a good idea! But it sort of all works now anyway, thanks for the help guys