Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Small problem with Sprites  (Read 3553 times)

0 Members and 1 Guest are viewing this topic.

Calmatory

  • Newbie
  • *
  • Posts: 16
    • View Profile
Small problem with Sprites
« on: October 18, 2009, 03:15:16 am »
Consider the following two chunks of code:
sprite.hpp:
Code: [Select]

/* sprite.h */
#ifndef SPRITE_H_
#define SPRITE_H_
#include <string>
#include <SFML/Graphics.hpp>
class CSprite {
    friend class CEngine;
private:
    sf::Image m_TempImage;
    sf::Sprite s_Hero[4];
    sf::Sprite s_Grass;
    sf::Sprite s_Gravel;
    sf::Sprite s_Sky;
public:
    CSprite();
    ~CSprite();
    bool LoadSprite(std::string filename, sf::Sprite &sprite);

};
#endif

and sprite.cpp:
Code: [Select]

/* sprite.cpp */
#include "include/sprite.hpp"

CSprite::CSprite() {
/* Constructor */
}

CSprite::~CSprite() {
/* Destructor */
}

    bool CSprite::LoadSprite(std::string filename, sf::Sprite &sprite) {
if(!m_TempImage.LoadFromFile(filename)) {
   return true;
} else {
sprite.SetImage(m_TempImage);
return false;
}
}


The files obviously try to handle sprite loading. The problem however is that when I call LoadSprite for example like this:
Code: [Select]

    Sprites.LoadSprite("gravel.png", Sprites.s_Gravel);
    Sprites.LoadSprite("grass.png", Sprites.s_Grass);
    Sprites.LoadSprite("sky.png", Sprites.s_Sky);


ONLY the last sprite seems to have the correct binded to it. All the previous sprites will have the LAST sprites image in them. Consider the following example:
Code: [Select]

    Sprites.s_Grass.SetPosition(0,0);
    m_App.Draw(Sprites.s_Grass);

    Sprites.s_Gravel.SetPosition(8,8);
    m_App.Draw(Sprites.s_Gravel);

    Sprites.s_Sky.SetPosition(16,16);
    m_App.Draw(Sprites.s_Sky);


Yields 3 Sprites.s_Sky sprites, instead of 3 different sprites.

If I change the order of LoadSprite functions, to load say s_Gravel as the last sprite, then ALL the loaded sprites will have the image of s_Gravel.

I suspect that I am doing something wrong with the m_TempImage in the LoadSprite function declaration. Though, I am not sure.

Any thoughts?
The amount of effort we put into something arbitrary we do in our everyday lives is proportional to the amount we gain from it. It's fascinating how this applies to everything in our lives. Your task is to try to enjoy and make the most out of it.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Small problem with Sprites
« Reply #1 on: October 18, 2009, 04:04:16 am »
'cause all sprite have the same sorite as reference so the laser load is "used" for all sprite. You need to use something else to store your sf::image, for example an image manager (see my wiki).
SFML / OS X developer

Calmatory

  • Newbie
  • *
  • Posts: 16
    • View Profile
Small problem with Sprites
« Reply #2 on: October 18, 2009, 04:19:30 am »
So every sf::Sprite object needs it's own sf::Image object?

That makes sense though, and the symptoms indicate to it.

Thank you. :)
The amount of effort we put into something arbitrary we do in our everyday lives is proportional to the amount we gain from it. It's fascinating how this applies to everything in our lives. Your task is to try to enjoy and make the most out of it.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Small problem with Sprites
« Reply #3 on: October 18, 2009, 12:48:39 pm »
Quote from: "Calmatory"
So every sf::Sprite object needs it's own sf::Image object?
That's it.
SFML / OS X developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Small problem with Sprites
« Reply #4 on: October 18, 2009, 05:11:17 pm »
Quote from: "Calmatory"
So every sf::Sprite object needs it's own sf::Image object?
To be more precise, every sf::Sprite object needs its own reference/pointer to an sf::Image object. The image itsself is stored independently from the sprite.

The separation of those two concepts allows more flexibility and is far more efficient than having a huge pixel-array for each sprite.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything