Drawing 3000 tiles results in 2 fps in debug, 25 fps release

[Clash]

Is RenderImage supposed to be a forever lasting variable like RenderWindow?

Neither of them is. They are supposed to be destroyed (manually or automatically) as soon as they aren't used anymore.

Edit: So, using dynamic memory (which I do not like) to avoid the destructors

Not calling destructors is not really a solution, since it leads to memory/resource leaks. If the destructor really crashes if you are using the class correctly, then it is likely to be a bug in SFML.

Do you have a minimal code reproducing this problem?

Why can't I add RenderImage to a container?
This is how I'm doing it right now

When I say groupedTile I refer to the RenderImage, that is simply a group of tiles. startingX is the id, for example, for a 512x512 block, we copy from tile 0 (startingX), 0 (startingY) to 32 (endingX),32 (endingY)

Code: [Select]

void Map::getGroupedTiles(int startingX, int endingX, int startingY, int endingY)
{
    sf::RenderImage *renderImage = new sf::RenderImage();
    if (!renderImage->Create(TILES_HORIZONTAL_RENDERIMAGE*TILE_WIDTH, TILES_VERTICAL_RENDERIMAGE*TILE_HEIGHT))
    {
        return; // failed
    }

    sf::Image *tileset = gImageManager.getResource("world.png");
    for (int y=startingY; y<endingY; y++)
    {
        for (int x=startingX; x<endingX; x++)
        {
            sf::Sprite sprite;
            sprite.SetImage(*tileset);
            sprite.SetPosition((x-startingX)*TILE_WIDTH, (y-startingY)*TILE_HEIGHT);
            sprite.SetSubRect(tilesRects[mapTiles[y][x]]);
            renderImage->Draw(sprite);
        }
    }

    renderImage->Display();
    sf::Sprite sprite;
    sprite.SetImage(renderImage->GetImage());
    sprite.SetPosition(startingX*TILE_WIDTH, startingY*TILE_HEIGHT);
    map.push_back(sprite);
}
If you switch from dynamic to "normal" memory, the program will crash as soon as it leaves the function.
I suppose I'm doing this the wrong way?

[Nexus]

Why can't I add RenderImage to a container?

Because STL containers require copy semantics and sf::RenderImage is noncopyable. But you can store it in Boost's pointer containers, for example.

If you switch from dynamic to "normal" memory, the program will crash as soon as it leaves the function.

Try to extract that piece of code so that everything specific to your project is omitted, and we are left with a main() function and plain SFML. If you can't reproduce the error in a minimal complete example, you are probably doing something wrong in your own code. You can also try to find out with the debugger what exactly raises the error.

[Clash]

Why can't I add RenderImage to a container?

Because STL containers require copy semantics and sf::RenderImage is noncopyable. But you can store it in Boost's pointer containers, for example.

If you switch from dynamic to "normal" memory, the program will crash as soon as it leaves the function.

Try to extract that piece of code so that everything specific to your project is omitted, and we are left with a main() function and plain SFML. If you can't reproduce the error in a minimal complete example, you are probably doing something wrong in your own code. You can also try to find out with the debugger what exactly raises the error.

Why is RenderImage NonCopyable and Image is copyable?
When am I allowed to destroy a RenderImage?
Thanks

Edit: I'm now using STL but saving the pointers instead, this way I can delete then when needed... however I wish there was something more elegant.

[Nexus]

No need to quote the full post if it is just above and if you don't refer to it in your answer.

Why is RenderImage NonCopyable and Image is copyable?

sf::RenderImage is noncopyable for the same reasons as sf::RenderWindow: The semantics of a copy are not meaningful (in which use cases should you copy the render state?). sf::Image is copyable because it contains mainly an array of pixels and an OpenGL texture.

When am I allowed to destroy a RenderImage?

You can destroy the sf::RenderImage like every other RAII object. I still think there is a bug in your code.

Edit: I'm now using STL but saving the pointers instead, this way I can delete then when needed... however I wish there was something more elegant.

I told you there is something more elegant, namely Boost.PointerContainers. But do you even need more than one sf::RenderImage at the same time?

[Clash]

I didn't want to use Boost. As previously discussed, there is a max size for RenderImage, so a map may be larger than a RenderImage, that's why I might need more than one.
Correct me if I'm wrong, but RenderImage also contains a pixel array and an OpenGL texture. I'm sure it contains a pixel array though.

[Groogy]

He was using it incorrectly as he only had it locally in a function ^^

What you can do is just save away the image(which is copyable)

[danman]

Clash : no, RenderImage has only a FBO (frame buffer object) managed by openGL .