Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Non-const access to RenderTexture's texture?  (Read 3103 times)

0 Members and 1 Guest are viewing this topic.

Ancurio

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Non-const access to RenderTexture's texture?
« on: December 26, 2012, 06:21:23 pm »
Hi!
I'm not really sure if there is a deeper meaning behind RenderTexture's getTexture() call only returning const
references, but it is something that I keep having to work around.
Because almost all textures I use must support being rendered to,
they're RenderTextures by default. This however makes things like
initializing from image files, where I have to create a throw-away texture,
unnecessarily wasteful, and some things, like setting repeat mode,
apparently impossible (?).

Is there a technical reason why the internal texture cannot be manipulated
like a usual texture?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Non-const access to RenderTexture's texture?
« Reply #1 on: December 26, 2012, 06:40:48 pm »
A RenderTexture is not a texture, it creates a texture as a result of draw calls. You cannot play with the internal texture; you're not even supposed to know that there's one, it could perfectly be created only when you call getTexture().

If you want to modify the texture that RenderTexture gives you, you must copy it to your own Texture instance.

I don't know why all your textures have to be a render-target, but this is not how the RenderTexture class is meant to be used. Maybe you could explain us what you do with textures?
Laurent Gomila - SFML developer

Ancurio

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Non-const access to RenderTexture's texture?
« Reply #2 on: December 26, 2012, 08:27:24 pm »
A RenderTexture is not a texture, it creates a texture as a result of draw calls. You cannot play with the internal texture; you're not even supposed to know that there's one, it could perfectly be created only when you call getTexture().

Okay, good, so my assumption was correct, there is a technical reason the texture reference is const only.
It's not really a show stopper or anything. I just thought I could be a little bit more efficient.

I don't know why all your textures have to be a render-target, but this is not how the RenderTexture class is meant to be used. Maybe you could explain us what you do with textures?

Well, I need to implement this interface. At first I was going to use sf::Image for it, but for a couple reasons (ie. stretched blitting, text rendering, hue shifting) it is more efficient to do everything directly on the GPU.

Edit: Oh, almost forgot. Is there a way to render the results of a RenderTexture in repeat mode,
without creating a copy of the internal texture everytime?
« Last Edit: December 26, 2012, 08:33:23 pm by Ancurio »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Non-const access to RenderTexture's texture?
« Reply #3 on: December 26, 2012, 09:17:52 pm »
Quote
Well, I need to implement this interface. At first I was going to use sf::Image for it, but for a couple reasons (ie. stretched blitting, text rendering, hue shifting) it is more efficient to do everything directly on the GPU.
Ok, I see.

Quote
Is there a way to render the results of a RenderTexture in repeat mode,
without creating a copy of the internal texture everytime?
It's a bug, it should be added like setSmooth/isSmooth. If you need it you can const_cast what getTexture() returns and modify the internal texture directly. But remember that it's ugly, it's only a temporary workaround until it is properly fixed :P
Laurent Gomila - SFML developer

Ancurio

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Non-const access to RenderTexture's texture?
« Reply #4 on: December 26, 2012, 09:54:04 pm »
It's a bug, it should be added like setSmooth/isSmooth. If you need it you can const_cast what getTexture() returns and modify the internal texture directly. But remember that it's ugly, it's only a temporary workaround until it is properly fixed :P

Ah, okay, cool thanks ^^ I'll do that.