Debug Assertion when using 'Texture.update(sf::Window)'

[BiiXteR]

So, I'm trying to update my texture but when I do that my game triggers a assertion which tells me :

Assertion failed: x + window.getSize().x <= m_size.x, file (long path)\Texture.cpp

In my code, this line triggers the assertion :

gResourceMgr.GetTexture(textureName)->update(gGraphics.GetWindow());

GetTexture() is this :

sf::Texture* ResourceManager::GetTexture(std::string file)
{
        if (textures.find(file) != textures.end())
        {
                return textures.find(file)->second;
        }
        else
        {
                std::cout << "Failed to get file : " << file << " from resource manager." << std::endl;
                return nullptr;
        }
}

And the textures map looks like this :

std::map<std::string, sf::Texture*> textures;

The gGraphics.GetWindow() function simply returns a reference to the games RenderWindow.

Unsure what I'm doing wrong :/

[Laurent]

This assertion is triggered in Texture::Update(Window&). That, plus the fact that you mention gGraphics.GetWindow() without it being in your posted code, makes me think that you're not showing everything, especially the most important part.

[BiiXteR]

The GetWindow  function is this :

sf::RenderWindow& Graphics::GetWindow()
{
        return mWindow;
}

and mWindow is this :

sf::RenderWindow mWindow;

[Laurent]

But why did you mention it in your first post? And are you really really sure that the assertion is triggered by mSprite.setTexture?

[BiiXteR]

But why did you mention it in your first post? And are you really really sure that the assertion is triggered by mSprite.setTexture?

Not sure what you mean by "why did you mention it in your first post" ?
Yes, that is the line that triggers the assertion (according to visual studio at least), but I have no idea why.

Ediiiit :
No, incorrect line. Pasted the wrong line in the post ._. Sorry. Edited the original post with the correct line.

And now I understand what you meant, and that's the reason I mentioned it in my post

[Laurent]

You should have added the correct line in a new reply instead of editing your first post. Now the whole thread looks very confusing

Anyway. The assertion is clear: the size of the window is greater than the size of the texture. Now it should be pretty easy for you to figure out why.

[BiiXteR]

You should have added the correct line in a new reply instead of editing your first post. Now the whole thread looks very confusing

Anyway. The assertion is clear: the size of the window is greater than the size of the texture. Now it should be pretty easy for you to figure out why.

Shouldn't the size of the window be more than the texture?
If the window size is less wouldn't that result in a texture which covers the entire screen?

Or should the texture be bigger than the screen and then scaled down?

[Laurent]

There's no scaling, it's a raw copy from the source window to the target texture. So if the source is bigger than the destination, you are out of the memory range which results in undefined behaviour. That's what the assert checks.

[BiiXteR]

There's no scaling, it's a raw copy from the source window to the target texture. So if the source is bigger than the destination, you are out of the memory range which results in undefined behaviour. That's what the assert checks.

Oh yeah, ofc theres no scaling, was thinking of sprites. lol

By "source > distination" you mean "texture > window" ?
If yes, I know that the texture is much smaller than the window is.
(the texture is 32.x32 pixels, and the window is 1024x720)

[Laurent]

No. You update the texture from the window. So the source is the window and the destination is the texture. So you're doing something wrong with your 32x32 texture.

[BiiXteR]

No. You update the texture from the window. So the source is the window and the destination is the texture. So you're doing something wrong with your 32x32 texture.

Can't find out how to resize the texture so that it is the same size as my window since the texture resizes itself to the size of the loaded image.

[Laurent]

Why would you overwrite a loaded texture with the content of the window? Usually you create an empty texture of the required size, when you want to update it from a window.

You should explain what you're trying to achieve, that will probably be faster than trying to fix whatever you think you must do

[BiiXteR]

Why would you overwrite a loaded texture with the content of the window? Usually you create an empty texture of the required size, when you want to update it from a window.

You should explain what you're trying to achieve, that will probably be faster than trying to fix whatever you think you must do

I was having a problem where my game would run fine but not display a sprite.
After some playing around with it I found a update function which I assumed (for some reason) was used to update the texture when a image has been assigned to it.

Now on second thought, is that even what texture.update() should be used for...?

[Laurent]

Not at all... As already said, and probably well explained in the documentation, all the Texture::update functions upload new content to the texture. The Texture::update(Window&) overload uploads the contents of the window (ie. what you currently see) into the texture.

Don't try random stuff, just follow the doc and tutorials. And if you have problems, just ask.

[BiiXteR]

Not at all... As already said, and probably well explained in the documentation, all the Texture::update functions upload new content to the texture. The Texture::update(Window&) overload uploads the contents of the window (ie. what you currently see) into the texture.

Don't try random stuff, just follow the doc and tutorials. And if you have problems, just ask.

Honestly not sure how, but when I read the docs, using update() seemed like the perfect solution to my problem.

Fixed the issue I had before I even tried using update though, for some reason SFML didn't like to render my .bmp so I made a png instead and it started working.