sf::Image private member "myTexture"

[bananu7]

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.

Code: [Select]

#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.

[Laurent]

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?

[bananu7]

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.

[Nexus]

Why don't you store your resource pointer?

Or directly repair your design, so that no hacks in SFML are necessary?

[bananu7]

Well, i guess, maybe that problem is the sign that the redesign I've been planning for month can now commence ;p

[bananu7]

I've found another example in which this accessor could be helpful:

Code: [Select]

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.

[Laurent]

Why would you bind a sf::Image with this function, and not an OpenGL texture?

[bananu7]

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?

[Laurent]

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.