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::ImageClass 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::TextureImage 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.
