text in texture

[croux]

Hi,

i am trying to make inventory in my game. I decided to make it as one big sf::Texture which is just updated when the item is added into it. But i have problem with writing item amount under items icon. I noticed that this is possible with redner Texture. But i need to do it with sf::Texture.

So the question is: it is possible to write text into texture ?

Thanks.

[Stauricus]

directly to a Texture no, but you can use a render texture to that.
1) draw your big Texture to a RenderTexture;
2) draw your text to the same RenderTexture;
3) update your big texture with

big_texture = render_texture.getTexture()

[Ixrec]

You really shouldn't be updating textures.  You should have one or more static textures containing images of every possible inventory item, then every frame you draw specific items to specific parts of the screen with sprites set to use the right parts of that texture.  Then just draw pieces of text around them for additional information like amounts.  What made you decide to do this by updating a texture?

It sounds like you're trying to save the previous frame and change only what you need to change each frame, rather than clear it and redraw everything each frame.  People often think they need to do the former for performance reasons, but they don't, and trying to do it that way makes their code far more complicated and buggy than it needs to be.

By the way, the most common uses of a RenderTexture are post-processing effects (eg, blurring the entire screen) and producing a static image at runtime (eg, if your user can customize his character's appearance, that appearance isn't changing every frame, so you can render it once and then reuse the result).  I don't think either applies to a player's inventory.

[Stauricus]

I think that a single sf::Texture is better than lots of sf::Texts when the words won't change very often. after all, you'll make less draw calls.
and you keep clearing the screen and re-drawing it every frame. but you just use a single sprite, instead of lots of texts. i think it's a good approach, and the code won't really be more complicated and buggy.

[Ixrec]

It would be valid to draw a bunch of sf::Texts to one sf::RenderTexture and reuse that, you're correct there.  But updating an sf::Texture every time the inventory changes is what OP is doing, which is why I'm focusing on that.  And the OP's description only mentioned one piece of text so that optimization doesn't apply yet (and it probably wouldn't make much of a difference unless you had a LOT of sf::Texts).

If we're worried about minimizing draw() calls, the inventory should obviously be one vertex array using a sprite sheet of all possible inventory items.  But that's a very minor issue compared to the conceptual flaw that causes one to update an sf::Texture instead of redrawing sf::Sprites, namely the thought that one should try to preserve the previous frame and edit it to make the next frame, rather than clearing and redrawing everything.  That preserve and edit logic is what will end up being complicated and buggy (and probably less efficient on modern hardware) compared to the far simpler clear and redraw everything.

[croux]

Well it was just an idea. I can also draw sf::Text after drawing one big inventory sf::Texture and the result ll be ok. And also i heard that its much better to use 1 big tex then 10 smaller for performance. But talking about performance its joke, since this is only small indie game. Anyway thanks for info

[Ixrec]

I don't think the number of textures by itself makes much of a difference.  Putting several things into one texture is usually about minimizing the number of times the graphics card has to switch textures, not about minimizing the number of textures in VRAM (it's the same amount of data either way).  Of course, that gets us back to vertex arrays; I assume multiple draw calls is similar to multiple texture switches.

So yeah, just draw an sf::Text separately.  Until performance becomes a problem, the simpler answer makes for better code.


Come to think of it I never directly answered your original question. The answer is no it isn't possible, because that's not how sf::Texture is meant to be used.

[croux]

Well i think it is general-known that less textures means faster performance, bcs it minimizes the state changes on the GPU.

[Stauricus]

[...]update an sf::Texture instead of redrawing sf::Sprites, namely the thought that one should try to preserve the previous frame and edit it to make the next frame, rather than clearing and redrawing everything.  That preserve and edit logic is what will end up being complicated and buggy (and probably less efficient on modern hardware) compared to the far simpler clear and redraw everything.

i don't know if it's what croux was trying to do, but my concept would be to completely clear and redraw all the sprites, yes - but to the renderTexture, and only when something changed. if you don't completely clear it, when you change text you'll have something like this:

i still think it's a  good approach, but i agree it won't make much difference in most cases.
out of curiosity, i use this concept in my little outline function (found somewhere in this forum), where i draw 360 copies of the same text around the original one.

instead of drawing all of these every frame, i draw everything to a single render texture, extract the texture from it, and use a single sprite. in this case i really noticed a difference.

[croux]

The concept is, in the cases where inventory is not changed i can just draw one sf::Texture instead of drawing 20 small textures.

Thanks again guys, i ll use render texture or i ll just draw it all one by one directly to window.

[Hapax]

The concept is...just draw one sf::Texture instead of drawing 20 small textures.
...
i ll use render texture

I would think that a render texture would be better than constantly altering a texture but, as Ixrec touched on, if you want to only make one draw call for the entire inventory, rather than one for each item, you should take a look at using vertex arrays. This tile map example should be a decent starting point.