Scale sf::Texture

[Orfby]

I see that sf::Sprite has sf::Sprite::setScale() and sf::Sprite::scale() functions, and I feel it would be better if I could scale my master texture, instead of the thousands of sprites that use that texture. I considered loading the image file into a texture, setting the sprite and scaling it, then putting the sprite into an image, then putting it into the original texture (which is way too long and doesn't even work). I'm not implying I want a sf:Texture::setScale() function, just that I want to know how I can achieve this (maybe even an algorithm that scales a pixel array)

[Hapax]

Setting the scale for each sprite seems a reasonable thing to do. It's only changing a single float (per sprite).

If you want a function to set the scale of all sprites at the same time, you could write a simple one (loop through each sprite and changes its scale).

It may be useful to remember to think of texture as the image data and the sprite as the way to draw that texture. Then, when you talk of 'changing the scale of the texture', it becomes 'resizing an image' whereas 'changing the scale of a sprite' becomes 'draw that texture at a different size'

[eXpl0it3r]

As Hapax said the texture is just the image data, that is the single pixels with the four RGBA components.
Scaling said texture would involve manipulating the pixel data.

If you want the texture to be always scaled, you're better off changing the image file in an image editor.

[Mario]

If you want to scale everything, just use a different sf::View for your window. If your window is 640x480 and your view is 320x240, you'll essentially scale everything by 2.

[Orfby]

The reason I want to resize the texture and I can't do it in an image editor is because I have a system where all tiles are displayed as 256x256px tiles, but all assets made by me are 16x16px. This is to save space but allow modders to create textures/texture packs that require a higher resolution. The only other game I can think of that also uses this system is Minecraft, because it uses 8x8 textures but modders can create resource packs that have resolutions upwards of 512x512px! (This also the reason I can't change the view, because the different textures will be different sizes)

[Nexus]

You could do that with sf::RenderTexture, but it will only require you additional loading time if you want to scale every texture. And it doesn't really give you an advantage.

I don't see why scaling sprites is a problem... You can take the original texture size into account, so a 16x16 texture is scaled by factor 16, but a 128x128 texture only by 2.

[Orfby]

Scaling sprites is only a problem after reloading textures and I have to scale all the sprites in the game, which is around 320,000 sprites. This is why I said that I don't need an update to the whole SFML library, because the feature only makes my life a little easier.

[Nexus]

Do you really need 320k sprites at the same time? Instead of keeping memory allocated for all of those, you might want to create sprites when you need them. Keep in mind that sf::Sprite is just a way of representing game objects graphically; you should never use them to store game logic (like entity positions). That exactly makes design changes like these easier to perform.

About updating on texture reload, that can be done with a simple Observer pattern.

There's another reason why I wouldn't scale all textures to 256x256: You waste a massive amount of video memory and make processing slower. As these upscaled textures don't contain more information than the original ones, there's no point in using more memory to store them.

[Hapax]

If these are all tiles that use a single texture (or at least multiple per texture), could you not use a vertex array instead of multiple sprites? This would reduce the number of actual calls (320k sprites = 320k draw calls!) and, more importantly (for you, it seems) allow you to scale these tiles at once, allowing the texture coords of each vertex in conjuction with their positions to scale them.

[Orfby]

I will try to change the system so there are a lot fewer sprites, but to what Hapax said:

(320k sprites = 320k draw calls!)

Since when do I need to draw all of the tiles? On a 1600x900 screen with no view zooming I only really need to draw 22 tiles as long as I can work out if the tile is in the area.

[Hapax]

Since when do I need to draw all of the tiles?

You didn't say that you weren't displaying all of those sprites.

I only really need to draw 22 tiles

You can do that with twenty-two sprites, not 320,000 thousand sprites or, indeed, a single vertex array per texture.

This goes back to what Nexus said earlier about keeping logic outside of sprites and using the sprites (or whichever method you choose) to display the final representation of that inner logic.
Sprites are not entities; they are visual representations of entities.