std::cout << sizeof(sf::RenderTexture) << std::endl;//488
std::cout << sizeof(sf::Texture) << std::endl;//32
My thought are that RenderTexture was supposed to be used as a drawing board and sf::Texture would be the paper that you actually draw on.Copying (moving) a RenderTexture to a Texture is not enough?Moving renderTexture to texture, is that possible? i tested, and failed to accomplish that.
Not sure I understand what you need/want that cannot already be done..
Would be nice to explain why you want such a feature.It looks like the "feature already exists" i just failed to see it.
what do you mean by 'swapping ownership'?I mean that i cannot extract the texture from sf::RenderWindow to sf::Texture.
and i think sf::Texture would be the drawing itself, not a paper where you draw.
Copying is posible and if SFML 3.0 adds a move constructor and move assignment operator then we'll be all set for movingYou can't move a const texture.
What does this do? :osf::RenderTexture renderTexture(texture);
Isn't it clear?It is not clear. It looks obvious, sure, but I wouldn't want to use it on an assumption.
Does the render texture make a copy of the texture or point to the actual one?I take from the discussion that it will simply point to the actual one, hence the equivalence to a .setTexture() method that is already part of some other classes. I can already see all the "white square RenderTexture" threads rolling in ::).
If people, for whatever reason, want to use a single RenderTexture to draw to multiple texture destinations every frame because they only need a single "drawer" RenderTexture, [...]Then let's find a relevant use case for this before deciding anything. You know the SFML philosophy, "don't do it if nobody needs it" ;)
I thought the philosophy was "don't do it if only one person needs it".It has slightly evolved since then :P
A possible scenario that someone may possibly want to do is a group of television screensI'd like answers without the words "possible", "may", "possibly", etc. Real use cases please.
If this rendertexture(texture) thing works, I guess that would do that.Such a thing doesn't exist, it was just an idea. And no, it wouldn't do that since the RenderTexture would be tied to a unique Texture instance.
It has slightly evolved since then :PGood to know :)
I'd like answers without the words "possible", "may", "possibly", etc. Real use cases please.This means that you are waiting for someone to require it for a project before considering implementing it. In which case, SFML will not be able to provide for the requirement of their project. The "possibly" stuff is a way of saying that these things could happen and is one example of something people may require. If someone said that they were going to do the thing that I just suggested as a possibility, does that make it a real use case?
the RenderTexture would be tied to a unique Texture instance.Tied? Does this mean that the texture cannot be used as a texture for anything else? :o
This means that you are waiting for someone to require it for a project before considering implementing it. In which case, SFML will not be able to provide for the requirement of their project. The "possibly" stuff is a way of saying that these things could happen and is one example of something people may require. If someone said that they were going to do the thing that I just suggested as a possibility, does that make it a real use case?Since this feature would be an optimization only, it won't block anyone. So yes, I'd really like to know if someone really needs this before doing it. If nobody cares, there's probably no point making the code more complicated.
Tied? Does this mean that the texture cannot be used as a texture for anything else?No. I just said that since you pass the texture to the constructor, you won't be able to change it afterwards. So you end up with 1 RenderTexture = 1 Texture, which is exactly what the current API does. No point.
If nobody cares, there's probably no point making the code more complicated.I didn't realise that it would, I'm sorry.
I just said...I wasn't trying to trick you or question whether you stated anything correctly or anything. I genuinely just wanted to know. Sorry if you understood it that way :(