sf::Texture implemented in SFML 2

[Groogy]

In my opinion, CopyToImage is a single-shot operation, I can't think of a use case that would require updating the same image again and again from a texture.

Well I totally agree with this but I can't help feeling that for rbSFML this will be really bad and slow cause it means that it will create a copy from the return value of the CopyToImage function and then a copy again from that object to a heap-based object so it can be used in the bindings. Or am I missing something I can do here to remove that second copy?

Still sure it should not be part of the normal frame iteration of a game but this means that this is double as slow just because. I'm not obsessed with optimizing code(Haven't tried optimizing rbSFML at all, will do that when sfml2 is done) but it nags me back in my head when it can be avoided.

The code will be something like:

Code: [Select]


static VALUE Texture_CopyToImage( VALUE self )
{
    // Code code code
    VALUE newImage = // Allocate a new Ruby image.
    sf::Image *imagePtr = NULL;
    Data_Get_Struct( newImage, sf::Image, imagePtr );
    *imagePtr = selfPtr->CopyToImage();
    return newImage;
}

But I guess if I can manage to do something like this the second copy won't be made?

Code: [Select]


sf::Image *newImage = new sf::Image( texture->CopyToImage() );

Or does it not matter?

[Haikarainen]

The only drawback of this modification is that you can't retrieve pixels from a texture, and thus from a sprite, anymore. For pixel-perfect collision detection you must now store the collision data yourself (which allows more optimizations, by the way).

Why was this needed? This breaks ALOT of stuff for me :/ also my project has been on ice in waiting for SFML2 Release, and now this? WHY? youre breaking my heart......



...

[Nexus]

Because of such changes, it is usually recommandable to couple graphics (sf::Image/sf::Texture) and game logics (collision) not too tightly. I know this is difficult for pixel-perfect collision, but now you need an abstraction layer anyway – unless you want to waste a lot of memory with sf::Image.

[Laurent]

Well I totally agree with this but I can't help feeling that for rbSFML this will be really bad and slow cause it means that it will create a copy from the return value of the CopyToImage function and then a copy again from that object to a heap-based object so it can be used in the bindings. Or am I missing something I can do here to remove that second copy?

How is this different from the direct use in C++?

Code: [Select]

sf::Image image;
image = texture.CopyToImage();

[Groogy]

I don't know. Probably is. Just that I have to do it in more steps that fools me. Also I'm writing everything from my phone so hard to see the big picture. Coding like this is difficult but fun.

[Haikarainen]

Is there ANY possibility to get pixel information from a texture?

[Groogy]

Is there ANY possibility to get pixel information from a texture?

Yeah by converting it to a image.

[bastien]

This may be a stupid question, but does create() recreate the texture if it was already created? Is it the right way to change the texture's dimensions?

[Laurent]

Is it the right way to change the texture's dimensions?

Yes, but then its contents will be uninitialized, you'll have to update it with valid pixels.

[bastien]

I just saw that you renamed Image::LoadFromPixels() to Create(). Why?

[Laurent]

"Create" functions are more basic than "Load" functions, and they can't fail (they return void). This is my logic, I don't know if it makes sense or not :lol:

[prchakal]

Hi,

How to get pixels now?

Before this mod we can use GetPixel from sprite, and now?

[Nexus]

How to get pixels now?

Before this mod we can use GetPixel from sprite, and now?

Wasn't that anwered by Groogy?

You can use sf::Texture::CopyToImage() to get the corresponding pixel container sf::Image.

[Groogy]

Think this part in the documentation is wrong: http://sfml-dev.org/documentation/2.0/classsf_1_1Image.php#a95667a08de2ec1b06fae4a9784eea669

Load the image from a custom stream.

The supported image formats are bmp, png, tga, jpg, gif, psd, hdr and pic. Some format options are not supported, like progressive jpeg. The maximum size for an image depends on the graphics driver and can be retrieve with the GetMaximumSize function. If this function fails, the image is left unchanged.

Image isn't bound by the maximum size of the graphics driver right?

ALSO! I freakin hate you for the array of Update methods.... Ruby doesn't let you have the same method name with different argument lists in an easy way so I have to fake it using variable argument lists. 2 or 3 different are hard and worrying but this is just insane! Note: This is not a request for you to change it or else I will have done all this work for nothing

[Laurent]

Think this part in the documentation is wrong

Yup, it's fixed now.

ALSO! I freakin hate you for the array of Update methods.... Ruby doesn't let you have the same method name with different argument lists in an easy way so I have to fake it using variable argument lists

Well, do it the way you prefer, you're not forced to use the same name for all the overloads. CSFML uses three functions: UpdateFromPixels, UpdateFromImage and UpdateFromWindow.