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

Author Topic: sf::Sprite in 2  (Read 2152 times)

0 Members and 1 Guest are viewing this topic.

Tresky

  • Newbie
  • *
  • Posts: 44
    • View Profile
    • Email
sf::Sprite in 2
« on: July 02, 2012, 07:44:09 pm »
I can't seem to figure out how the SF::Sprite class changed from 1.6 to 2.0. I had a line of code that had a Sprite being made with an image in the parameters. The constructor has changed to contain a texture now and I'm not sure how to use that. Do all my images need to change to textures? Are they equivalent?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11033
    • View Profile
    • development blog
    • Email
Re: sf::Sprite in 2
« Reply #1 on: July 02, 2012, 08:02:42 pm »
Do all my images need to change to textures? Are they equivalent?
Yes and no.

In SFML 2 the sf::Image got split up into sf::Texture and sf::Image, where sf::Texture has taken over all the functions for drawing and sf::Image exists mostly just to set pixels on your own.
So yes you probably have to replace all sf::Image with sf::Texture, unless you have some SetPixel(...) calls.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Tresky

  • Newbie
  • *
  • Posts: 44
    • View Profile
    • Email
Re: sf::Sprite in 2
« Reply #2 on: July 02, 2012, 09:35:12 pm »
Okay so basically what you're saying is that the image class is normal except it can't load from file? It has to be set pixel by pixel and texture is the opposite?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11033
    • View Profile
    • development blog
    • Email
Re: sf::Sprite in 2
« Reply #3 on: July 02, 2012, 10:20:04 pm »
Okay so basically what you're saying is that the image class is normal except it can't load from file? It has to be set pixel by pixel and texture is the opposite?
No :)

I've not much knowledge of how it's actually implemented but what I know of, is that sf::Texture is now a real texture that lives completly on the GPU and thus is extremly fast to draw, where as the sf::Image (I guess on that) lives in the RAM and thus has to be converted to a texture to be drawn. (Note: you can not draw a sf::Image on its own.)

So unless you need to manipulate single pixel use sf::Texture.
Btw the documentation states:

sf::Image
Quote from: Laurent
Class for loading, manipulating and saving images.

sf::Image is an abstraction to manipulate images as bidimensional arrays of pixels.

The class provides functions to load, read, write and save pixels, as well as many other useful functions.

sf::Texture
Quote from: Laurent
Image living on the graphics card that can be used for drawing.

sf::Texture stores pixels that can be drawn, with a sprite for example.

A texture lives in the graphics card memory, therefore it is very fast to draw a texture to a render target, or copy a render target to a texture (the graphics card can access both directly).

Being stored in the graphics card memory has some drawbacks. A texture cannot be manipulated as freely as a sf::Image, you need to prepare the pixels first and then upload them to the texture in a single operation (see Texture::update).

sf::Texture makes it easy to convert from/to sf::Image, but keep in mind that these calls require transfers between the graphics card and the central memory, therefore they are slow operations.

A texture can be loaded from an image, but also directly from a file/memory/stream. The necessary shortcuts are defined so that you don't need an image first for the most common cases. However, if you want to perform some modifications on the pixels before creating the final texture, you can load your file to a sf::Image, do whatever you need with the pixels, and then call Texture::loadFromImage.

Since they live in the graphics card memory, the pixels of a texture cannot be accessed without a slow copy first. And they cannot be accessed individually. Therefore, if you need to read the texture's pixels (like for pixel-perfect collisions), it is recommended to store the collision information separately, for example in an array of booleans.

Like sf::Image, sf::Texture can handle a unique internal representation of pixels, which is RGBA 32 bits. This means that a pixel must be composed of 8 bits red, green, blue and alpha channels -- just like a sf::Color.
« Last Edit: July 02, 2012, 10:23:57 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Tresky

  • Newbie
  • *
  • Posts: 44
    • View Profile
    • Email
Re: sf::Sprite in 2
« Reply #4 on: July 03, 2012, 03:29:49 pm »
Oh!!! Nice. That is a really cool modification that Laurent made. It will help make my programs run faster. Thanks for the awesome information, buddy. If I could upvote your posts, I would.

 

anything