sf::Texture flexibility

[Robert42]

My Game with 3D Graphic needs mipmapping and tilable textures and so. Theese are special usages of Textures, and I think adding a sf::Texture::SetMipmapped(bool) and sf::Texture::SetTilable(bool)
is not a very good design.

My ideas how to solve this:
1) Create my own Texture class for my game or a wrapper class:
  - redundant Code
  - much work
  - my will probably get incompatible to nice SFML classes like RenderTexture
  + best control
  + no change in the SFML Library
 
2) add a virtual OnInitialize Function to sf::Textre in SFML 2.0
  + adding such special purpose effects becomes easy
  - Textures you have not created by yourself (like the internal one in RenderTexture) won't have theese effects
  - sf::Texture class has to be changed
  => not clean
 
3) add a callback OnInitialize to sf::Texture (in std::funtion<...> or even something like sigc::signal<...> style)
  + adding such special purpose effects becomes easy
  + special effects
  - sf::Texture class has to be changed
  - I can miss some textures
  => better than 2) but still not very clean
 
4) use Strategy-Design-Pattern for sf::Texture class this way:
 
         (where Smooth has the same effect as sf::Texture with SetSmooth(true) and Blocky with SetSmooth(false))
  + adding such special purpose effects becomes very and flexible easy
  + clean evn the Texture::SetSmooth(true/false) idea gets a little cleaner
  - sf::Texture class has to be changed
  - big Design-Change
  - large number of objects
  - bindings for non OOP Languages will be nearly impossible
  - far away to SFMLs usually clean Design
  => for me it looks the best way (flexible and clean)
 
5) just call sf::Texture::Bind() of the Texture and call my glTex... Stuff afterwards
 - no way to find out whether a Texture has called glGenTextures internally in between - I have to take care of everything and can miss some changes of sf::Texture
 - not very clean
 + most easy to way implement your Tetxure Parameter without altering SFML
 
6) add a public method in sf::Texture to find out whether the internal Textur has changed and combine with 5)
 - absolutle not clean :shock:
 
 
 
 
 
Looks like there's no perfect solution.
 
What do you think? Do we need a change in sf::Texture? why? why not? Other ideas?

I didn't post this to the Feature Request Forum, because I want to discuss the different ideas with you folks.

[Laurent]

My answer will be simple and fast

5) is usually the way to go because it doesn't involve modifying anything in SFML. But of course this doesn't mean that I'm not open to features proposals or discussions about sf::Texture.

Texture::SetTileable will probably be implemented in SFML 2, it will make sense in the new drawing API.

However Texture::SetMimapped will never be added, for the simple reason that i's a 3D-only feature.

My conclusion is that you're trying to use a class made for 2D in your 3D graphics engine. It cannot work. Even if sf::Texture is very close to what you need, you will always run into this kind of problems if you don't write your own class.

sf::Texture is not meant to be used in 3D, nor to be extended (SFML is not a framework), so I have no reason to implement one of your ideas.

This is probably not the answer that you expected, sorry

[Robert42]

My conclusion is that you're trying to use a class made for 2D in your 3D graphics engine. It cannot work. Even if sf::Texture is very close to what you need, you will always run into this kind of problems if you don't write your own class.

Ok, thanks. I'll do that. Much work, but it's worth it.