SFML community forums
Help => Graphics => Topic started by: bananu7 on December 01, 2011, 05:24:08 pm
-
I am using sf::Image as a texture class. However, my implementation of resource manager makes calls to Bind() very unefficient.
I wanted to remember the texture number in some of my drawing calls, but got an unpassable problem - private.
I am not using sf::Image directly; I created my own wrapper class.
However, I wasn't able to access this field because I can't get access to it.
I used following code as a workaround, I'd however be very happy to see some of the private variables changed to protected or be given accessors in new API.
#define private protected
#include <SFML/Graphics/Image.hpp>
#define private private
//EDIT : this code, surprisingly, didn't work. I just edited the Image.hpp file and changed this.
-
It's not private just to bother people. It's private to ensure a clean and consistent design.
Why do you need to access this member?
-
Because I need to use it repeteadly in main loop. When I don't have access to it, I need to repeatedly dereference my resource pointer and then call bind. Also, my resource manager is pretty bad-designed right now, so getting resource pointer takes a little bit too much time.
-
Why don't you store your resource pointer?
Or directly repair your design, so that no hacks in SFML are necessary? :P
-
Well, i guess, maybe that problem is the sign that the redesign I've been planning for month can now commence ;p
-
I've found another example in which this accessor could be helpful:
glBindMultiTextureEXT()
It's direct access function (new in OpenGL 3.x I believe) which is considered to be much safer and cleaner than usual glActiveTexture/glBindTexture pair.
Of course, it requires the explicit texture number, hence the need for accessor.
-
Why would you bind a sf::Image with this function, and not an OpenGL texture?
-
I use sf::Image to load image to memory. Additional benefit is that it automatically creates the openGL texture identifier, so I was using it - I mean, I gonna create it anyway, so why not?
But then, I needed to access this texture identifier. So I am using now glBindMultiTextureEXT with the texture identifier extracted from sf::Image. (with the hacked code i mentioned earlier).
One of the drawbacks is that I had to force pixel update through Bind().
I think that Bind could actually get a parameter describing what texture unit I want to bind my texture to.
Or do you think that I should not use sf::Image as texture container and use it only for loading purposes?
-
Or do you think that I should not use sf::Image as texture container and use it only for loading purposes?
Definitely.
sf::Image is not a generic purpose texture wrapper, it's just the image class of the SFML graphics module, and it's only designed to work with the other classes of this module.