Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::Texture implemented in SFML 2  (Read 20911 times)

0 Members and 1 Guest are viewing this topic.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
sf::Texture implemented in SFML 2
« Reply #15 on: August 18, 2011, 10:47:27 pm »
Quote from: "Laurent"
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?
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Haikarainen

  • Guest
Re: sf::Texture implemented in SFML 2
« Reply #16 on: August 19, 2011, 07:33:56 am »
Quote from: "Laurent"
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
sf::Texture implemented in SFML 2
« Reply #17 on: August 19, 2011, 11:10:53 am »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Texture implemented in SFML 2
« Reply #18 on: August 19, 2011, 11:21:19 am »
Quote
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();
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
sf::Texture implemented in SFML 2
« Reply #19 on: August 19, 2011, 12:08:54 pm »
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.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Haikarainen

  • Guest
sf::Texture implemented in SFML 2
« Reply #20 on: August 19, 2011, 03:36:11 pm »
Is there ANY possibility to get pixel information from a texture?

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
sf::Texture implemented in SFML 2
« Reply #21 on: August 19, 2011, 04:35:42 pm »
Quote from: "Haikarainen"
Is there ANY possibility to get pixel information from a texture?


Yeah by converting it to a image.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

bastien

  • Full Member
  • ***
  • Posts: 231
    • View Profile
    • http://bastien-leonard.alwaysdata.net
sf::Texture implemented in SFML 2
« Reply #22 on: August 19, 2011, 05:19:58 pm »
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?
Check out pysfml-cython, an up to date Python 2/3 binding for SFML 2: https://github.com/bastienleonard/pysfml-cython

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Texture implemented in SFML 2
« Reply #23 on: August 19, 2011, 05:35:22 pm »
Quote
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.
Laurent Gomila - SFML developer

bastien

  • Full Member
  • ***
  • Posts: 231
    • View Profile
    • http://bastien-leonard.alwaysdata.net
sf::Texture implemented in SFML 2
« Reply #24 on: August 19, 2011, 06:47:15 pm »
I just saw that you renamed Image::LoadFromPixels() to Create(). Why?
Check out pysfml-cython, an up to date Python 2/3 binding for SFML 2: https://github.com/bastienleonard/pysfml-cython

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Texture implemented in SFML 2
« Reply #25 on: August 19, 2011, 06:55:02 pm »
"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:
Laurent Gomila - SFML developer

prchakal

  • Full Member
  • ***
  • Posts: 142
    • View Profile
sf::Texture implemented in SFML 2
« Reply #26 on: August 19, 2011, 11:41:28 pm »
Hi,

How to get pixels now?

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

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
sf::Texture implemented in SFML 2
« Reply #27 on: August 20, 2011, 02:53:23 am »
Quote from: "prchakal"
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
sf::Texture implemented in SFML 2
« Reply #28 on: August 21, 2011, 02:21:26 pm »
Think this part in the documentation is wrong: http://sfml-dev.org/documentation/2.0/classsf_1_1Image.php#a95667a08de2ec1b06fae4a9784eea669

Quote
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 :P
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sf::Texture implemented in SFML 2
« Reply #29 on: August 21, 2011, 09:13:55 pm »
Quote
Think this part in the documentation is wrong

Yup, it's fixed now.

Quote
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.
Laurent Gomila - SFML developer