Messages

1

Graphics / Trouble managing resources (probably a scoping issue?)

« on: January 27, 2012, 05:17:10 pm »

I got around to building it on Windows now (finally), and the exact same codebase that gives me trouble on Linux runs just fine on Windows. I have played around with the issue, and it looks like I hit this bug that is already reported at https://github.com/SFML/SFML/issues/160 , except that it also crashes my window. Initializing a main window before loading the resources fixes the problem for me.

2

Graphics / Trouble managing resources (probably a scoping issue?)

« on: January 06, 2012, 06:25:10 pm »

That's what I was thinking. I'm trying to look further into the problem (if it works on Windows, I'll know where to start looking at least), but I wouldn't rule out the chance that there's some problem in my code yet.

3

Graphics / Trouble managing resources (probably a scoping issue?)

« on: January 05, 2012, 03:40:05 am »

Thanks for the reply
I've tried out your approach with both raw and smart pointers, but without success. I store pointers in the ResourceManager's map now and return these.
Again, they seem to point to valid Textures right before calling Display() on the main window, but again the window just closes after two frames.
Copying the Texture the pointer points to over to a member of the DisplayManager class and using this for the Sprite fixes this.

After debugging around a bit, I found out that the thing that actually closes the program is the call to glXSwapBuffers() during the second frame in src/Window/Linux/GlxContext.cpp of SFML. After that, gdb tells me that the process exited with return code 1. Just for the fun of it I'll try compiling the thing on Windows tomorrow and see if that changes anything.

4

Graphics / Trouble managing resources (probably a scoping issue?)

« on: January 04, 2012, 05:56:45 pm »

I have managed to work around this issue by creating a copy of the sf::Texture as a member in my DisplayManager class and then setting this copy as the Sprite's texture, but for obvious reasons I'm not really happy with that, and I also don't really know why this works, but the other version doesn't.

5

Graphics / Trouble managing resources (probably a scoping issue?)

« on: December 31, 2011, 01:02:02 pm »

Hi everybody,
I have some trouble managing resources, which is probably less of a SFML question but rather a general C++ question.
I have written a resource manager which returns a const pointer to a const sf::Texture.

Code: [Select]


class ResourceManager {
public:
    const sf::Texture *getResource(std::string resourceName) const;
private:
    std::map<std::string, sf::Texture> resourceMap;
};

This is all working fine and well. Then I have another class which manages drawing the actual display, which has a blit() function, which is supposed to get a Texture from the ResourceManager and draw it using a Sprite.

Code: [Select]


class DisplayManager {
public:
    void drawDisplay(); // calls Clear() at the beginning and Display() at the end
private:
    sf::Sprite drawSprite;
    void drawMainMenu();
    void drawOptionsMenu(); // etc, etc...
    void blit(int screenX, int screenY, float scaleX, float scaleY, std::string resourceName);
};

My main() function calls drawDisplay() every frame, which queries the game state and then decides what to draw (main menu, or options menu, etc). It also runs Clear() at the beginning and Display() at the end.
In my example, it decides to call drawMainMenu(), which then calls

Code: [Select]

blit(0, 0, 1, 1, "MainmenuBackground");
to draw the background of the main menu. The blit() function uses the member Sprite drawSprite everytime it's called and overwrites its configuration. It basically looks like this:

Code: [Select]


void DisplayManager::blit(int screenX, int screenY, float scaleX, float scaleY, std::string resourceName) {
    const sf::Texture* const renderTexture = resourceManager.getResource(resourceName);
    drawSprite.SetTexture(*renderTexture);
    drawSprite.SetPosition((float) screenX, (float) screenY);
    // omitted the scaling code, which is currently commented out anyway
    mainWindow.Draw(drawSprite);
};

The code is compiling cleanly, and is also working in some way. I'm getting the resource from the ResourceManager. I can also set it as the sprite's Texture via SetTexture.
Even more, I can access the texture I set in blit() in the drawScreen() function right before the Display() call, can for example use drawSprite.GetTexture()->GetWidth() and GetHeight() with correct results.
But nonetheless, the application only runs for two frames (it's 2 frames every time), where the first frame is actually showing a "raw" RenderWindow (I can see the contents of the window behind it, using SFML on Linux), and the second frame at least applies the Clear() and draws the contents of the window black.
Then the application just closes (no crash).

Through trial and error I found out that if I comment out the mainWindow.Draw(drawSprite) call in blit(), the application runs just fine (only clearing the screen).

I'm probably misunderstanding how the memory management works in this case, but I just can't understand why it's not displaying anything and just closing the application. Manually drawing primitive shapes in the drawDisplay() function works just fine. Also, if I manually create a sf::Texture and sf::Sprite in the drawDisplay() function before the mainWindow.Display(), it can be displayed.

Thanks in advance, and a happy new year everybody. May SFML continue to be a great library in 2012

PS: I'm using a current git checkout of SFML 2.0 on Fedora 16, 64 bit.

6

Window / Initializing RenderWindow as class member

« on: August 23, 2011, 10:52:06 pm »

You can simplify your code a lot by using the initializer list.

Tthat did simplify it a lot indeed. I tried to construct with an initializer list before, but because I created a new instance of sf::RenderWindow to initialize mainWindow instead of just passing the arguments, I ran into problems. I didn't know you can just pass arguments in initializer lists.
I also saved myself saving the width and height now, thanks

7

Window / Initializing RenderWindow as class member

« on: August 23, 2011, 08:18:03 pm »

Yes, declaring another variable with the same name creates a local variable which has nothing to do with your class member.

You can't "construct again" the window object, that's why the Create function exists...

Alright, that works perfectly. Thanks very much for the help!
Next time I'll scan the API documentation a bit more carefully

8

Window / Initializing RenderWindow as class member

« on: August 23, 2011, 07:36:26 pm »

Hi everybody,
I am using a RenderWindow as a class member in a class called DisplayManager. I want to initialize the RenderWindow with parameters from DisplayManager's constructor.
So I basically have this code:

DisplayManager.hpp

Code: [Select]


class DisplayManager {
public:
    DisplayManager(int screenWidth, int screenHeight);
private:
    void initDisplay();
    sf::RenderWindow mainWindow;
    int screenWidth, screenHeight;
};

DisplayManager.cpp

Code: [Select]


DisplayManager::DisplayManager(int screenWidth, int screenHeight) {
    screenWidth = screenWidth;
    screenHeight = screenHeight;
    initDisplay();
}
void DisplayManager::initDisplay() {
    // now this is where it becomes tricky
    // normally I would write
    // mainWindow = sf::RenderWindow(sf::VideoMode(screenWidth, screenHeight, 32), "FooBar"));
    // however, this doesn't work, because RenderWindows overload the assignment operator to make sure they're not being copied, as far as I understand
    // this is what I write instead
    sf::RenderWindow mainWindow(sf::VideoMode(screenWidth, screenHeight, 32), "FooBar"));
    // however, this seems to be a local variable, as the RenderWindow gets destructed as soon as I leave the initDisplay() function
}


My question is now, how do I initialize a RenderWindow member with parameters from the constructor? Maybe I'm missing something really obvious, but I can't seem to route around the copying check RenderWindow performs.
I'm not really familiar with the behaviour of C++ yet, so I don't really know whether the

Code: [Select]

sf::RenderWindow mainWindow(sf::VideoMode(screenWidth, screenHeight, 32), "FooBar"));
 is expected to create a local variable or not, or whether I'm missing some obvious C++ feature that does what I want (initializer lists give me the NonCopyable error as well).

I am using a git checkout of SFML2 by the way (commit b9b38887884fa9ad0b87e648dc16e27cad84d609) on Fedora 15 with g++ 4.6.0

Thanks for any help in advance