Why cant sprite take a pointer to the location of the image?

[nisse pisse]

I want to have a class where i stora all my images like this

Code: [Select]

#ifndef GAMESTATE_H_INCLUDED
#define GAMESTATE_H_INCLUDED

#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

#include <string>
using namespace std;
class Model;

class Gamestate{
  private :
    Model* model;
    sf::Image *image[255];
    sf::Music bgm[1];
    sf::SoundBuffer sfx[255];




    public :
    Gamestate(Model* model);
    void DrawGamestate(sf::RenderWindow* App,int layer);
    void UpdateGamestate();
    void HandleEvent( sf::Event* event);

    void LoadImage(string address, int position);
    void LoadSfx(string address,int position);
    void LoadMusic(string address,int position);
    sf::Image *GetImage(int position);

};
#endif // GAMESTATE_H_INCLUDED

Code: [Select]

#include "Gamestate.h"

#include "Model.h"

Gamestate::Gamestate(Model* model){
    this->model = model;
    this->LoadImage("testbg.png",0);
}
void Gamestate::DrawGamestate(sf::RenderWindow* App, int layer){
    }

void Gamestate::UpdateGamestate(){
}
void Gamestate::HandleEvent(sf::Event *event){
}


void Gamestate::LoadImage(string address, int position){
    image[position]->LoadFromFile(address);

}

void Gamestate::LoadSfx(string address,int position){
    sfx[position].LoadFromFile(address);

}

void Gamestate::LoadMusic(string address,int position){
    bgm[position].OpenFromFile(address);

}
sf::Image *Gamestate::GetImage(int position){
    return image[position];
}

I want to be able to load it like this
sf::Sprite bg1(hej->GetGamestate()->GetImage(0));

But its not possible -> D:\Program\Projects\test\Game.cpp|48|error: no matching function for call to 'sf::Sprite::Sprite(sf::Image*)'|

It doesnt take pointers... So its not possible to store my images in another class and get them from another?


[/code]

[Laurent]

Code: [Select]

sf::Sprite bg1(*hej->GetGamestate()->GetImage(0));

Or better, make Gamestate::GetImage return a reference directly, since it assumes that the image is always valid.

[nisse pisse]

Well then the sprite gets 100% white

[Disch]

Then something is wrong with your image.

Did it load correctly?

EDIT:

Wait a minute.. where are you allocating your Images?  You can't just have pointers that don't point to anything.  Where are you assigning these pointers?

[nisse pisse]

Well,what exactly do you mean by return a reference directly.  I interpreted it as to remove the pointer, but that seem to be wrong :/


i added  image[position] = new Image(); aswell
 

}

[Disch]

Why are you using pointers at all?

Why not just have objects?

Code: [Select]


class Gamestate{
   // ...
    sf::Image image[255];  // just have objects


Code: [Select]


sf::Image& Gamestate::GetImage(int position){  // return a reference
    return image[position];
}


[nisse pisse]

Right it works, but only with the sf::Image&

may is ask what the & does?As i know it gives the adress to an object, and therefore should work as a pointer, but obviously not...

[Laurent]

In front of an object it is the address-of operator, but in a type it means "reference". So sf::Image& is a "reference to a sf::Image", which means that you return the original object instead of a temporary copy.

Maybe you should study C++ a little more before writing games with SFML

[Disch]

Maybe you should study C++ a little more before writing games with SFML

Nuts to that.

You're going to learn things as you go no matter what kind of programs you start making.  So people should start making what they want to make instead of wasting time making programs they don't care about.

I think SFML is "easy enough" to where beginners can use it reasonably.

[Laurent]

Well, I wanted to focus on "study C++" more than on "writing games". Nobody can write proper C++ without knowing what a reference is. Reading a book or a tutorial is the only thing to do in this case.

[Nexus]

I think SFML is "easy enough" to where beginners can use it reasonably.

I don't think so. It uses advanced C++ concepts like classes, templates, operator overloading, polymorphism (to count some). Handling all this isn't easy for a beginner. The issue is, you don't learn that things by doing, you have to lookup them in a book (a good book is very important in my opinion, since online tutorials often don't explain the backgrounds and leave knowledge gaps).

Indeed, several game programmers share your opinion, and this isn't even a problem per se. I know that it's not very funny to program in the console, but if you learn C++ with an advanced library like SFML, you have to be really motivated and ambitous. The problem is, many people are neither of them, and their developping attitude is "it's good as long as it works". That's why there are not few games, that look nice in the first term, but are quite badly programmed (memory leaks, bad performance, undefined behaviour...)

Of course it's everyone's own decision. It's just that I have made the same mistake some years ago with SDL, and I have really regretted it. I developped a 2D jump'n'run without knowing about crucial language and stdlib features like exceptions, templates, runtime polymorphism, the STL, memory management. However, the game became slower and slower over time, and had some ugly other bugs. Therefore I restarted the project completely, as soon as I knew C++ a lot better. It can be discouraging to realize that a whole project is based on messy, not extensible and buggy code, and that every further progress is questionable.

[nisse pisse]

Well im gonna take a c++ course this fall, but i have written games in java and know of classes, inheritance, polymorphism etc

[Laurent]

Well im gonna take a c++ course this fall, but i have written games in java and know of classes, inheritance, polymorphism etc

He he, yep but the worst thing when switching from Java to C++ is getting used to the management of object lifetimes and memory. This is totally different in C++, and this is exactly what we're talking about in this topic

I don't think so. It uses advanced C++ concepts like classes, templates, operator overloading, polymorphism (to count some)

I globally agree with you, but I think that here you're talking about what the developers (namely me) must manipulate, not the users - at least in SFML.
Users will never see templates or polymorphic objects in SFML, and overloaded operators will just make things look more natural to them. Providing a simple C++ API is one of my goals in SFML, and I usually say that yes, SFML is good for (some kind of) beginners.

[Nexus]

My post was meant rather generally, don't worry.

Besides, there are some differences between C++ and Java that aren't obvious at all. You should avoid copying too many concepts 1:1 from Java, since the paradigms in C++ are completely different (for example, pure OOP programming isn't as important as in Java, or you often use value semantics and RAII).

[Nexus]

He he, yep but the worst thing when switching from Java to C++ is getting used to the management of object lifetimes and memory. This is totally different in C++, and this is exactly what we're talking about in this topic

You know what they are, but that doesn't necessarily mean you understand how they work in the semantics of C++.

Exactly!
(Edit: I see pdusen removed his post... I hope it's not dramatic if I leave the quote )

I globally agree with you, but I think that here you're talking about what the developers (namely me) must manipulate, not the users - at least in SFML.
Users will never see templates or polymorphic objects in SFML, and overloaded operators will just make things look more natural to them. Providing a simple C++ API is one of my goals in SFML, and I usually say that yes, SFML is good for (some kind of) beginners.

You're right, that some concepts aren't crucial to work with SFML. However, they can be of great advantage (when one derives from sf::Drawable or sf::Thread, or in case one wants to use sf::Vector2<T> for other T's). Anyway, those are rather advanced topics compared to the simple classes forming a big part of SFML.